You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From the maintainer Li Haoyi: I'm putting a 1000USD bounty on this issue, payable by bank transfer on a merged PR implementing this.
Mill 0.12.0 is moving towards using build.mill/package.mill files rather than build.sc. Basic IntelliJ support landed in JetBrains/intellij-scala#667, so the next thing to do is get them working in VSCode/Metals. .mill and .mill.scala files already mostly work in IntelliJ/BSP, so this ticket is to get the same support for .mill and .mill.scala files in VSCode/Metals/BSP as well.
Jumping to build.MyModule should bring you to build.mill
Jumping to build.MyModule should bring you to mill-scalalib_2.13-0.12.0-RC3-sources.jar/mill/scalalib/package.scala (or equivalent)
Inside foo/package.mill
Jumping to build.MyModule should bring you to build.mill
Jumping to build.bar.qux.mymodule should bring you to bar/qux/package.mill
Jumping to RootModule should bring you to mill-main_2.13-0.12.0-RC3-sources.jar/mill/package.scala (or equivalent)
Inside build.mill
Jumping to ScalaModule should bring you to mill-scalalib_2.13-0.12.0-RC3-sources.jar/mill/scalalib/ScalaModule.scala (or equivalent)
Everything should still work if the .mill files are renamed to .mill.scala
For the purposes of this ticket, treating .mill files as vanilla .scala files (with the appropriate classpath and sources) is sufficient. It's not 100% precise, but is good enough for 95% of scenarios, and we can sort out the last 5% in a followup. Notably, we do not want to treat them as .sc files, since things like ScalaCLI directives and other scripty things don't work
lihaoyi
changed the title
Support for .mill files in VSCode/Metals (1000USD Bounty)
Support for .mill and .mill.scala files in VSCode/Metals (1000USD Bounty)
Oct 4, 2024
From the maintainer Li Haoyi: I'm putting a 1000USD bounty on this issue, payable by bank transfer on a merged PR implementing this.
Mill 0.12.0 is moving towards using
build.mill
/package.mill
files rather thanbuild.sc
. Basic IntelliJ support landed in JetBrains/intellij-scala#667, so the next thing to do is get them working in VSCode/Metals..mill
and.mill.scala
files already mostly work in IntelliJ/BSP, so this ticket is to get the same support for.mill
and.mill.scala
files in VSCode/Metals/BSP as well.The acceptance criteria is as follows:
bar/qux/package.mill
build.MyModule
should bring you tobuild.mill
build.MyModule
should bring you tomill-scalalib_2.13-0.12.0-RC3-sources.jar/mill/scalalib/package.scala
(or equivalent)foo/package.mill
build.MyModule
should bring you tobuild.mill
build.bar.qux.mymodule
should bring you tobar/qux/package.mill
RootModule
should bring you tomill-main_2.13-0.12.0-RC3-sources.jar/mill/package.scala
(or equivalent)build.mill
ScalaModule
should bring you tomill-scalalib_2.13-0.12.0-RC3-sources.jar/mill/scalalib/ScalaModule.scala
(or equivalent).mill
files are renamed to.mill.scala
For the purposes of this ticket, treating
.mill
files as vanilla.scala
files (with the appropriate classpath and sources) is sufficient. It's not 100% precise, but is good enough for 95% of scenarios, and we can sort out the last 5% in a followup. Notably, we do not want to treat them as.sc
files, since things like ScalaCLI directives and other scripty things don't workPrior Art: scalameta/metals#6752
Dependencies
semanticDbData
fails on meta-build #3666The text was updated successfully, but these errors were encountered: