BSP: Improve IntelliJ/VSCode Project Experience

[lihaoyi]

1. https://github.com/com-lihaoyi/mill/pull/3426 cut over the default file extension from .sc to .mill or .mill.sc. We need to send PRs upstream to IntelliJ-Scala, VSCode-Metals, and https://github.com/github-linguist/linguist to tell them that the .mill and .mill.sc extension now belongs to Mill and should be treated as Scala code

   • WIP https://github.com/JetBrains/intellij-scala/pull/666 https://github.com/scalameta/metals/pull/6752 https://github.com/github-linguist/linguist/pull/7028, might just need to shepherd those changes in

2. IntelliJ sometimes forgets that a project is a Mill/Scala/BSP project and doesn't provide any easy way to remind it apart from running git clean -xdf and re-opening the folder. Forgetting sometimes is fine (e.g. if I rm the .idea folder), but I expect to be able to re-import it easily after

3. IDE rebuilding things sometimes happens concurrently with CLI rebuilding things, causing race conditions and crashes. e.g. @nafg has reported this in the discord. We should consider moving IDEs to a separate out/ folder (e.g. .bsp/out), which would cost us some duplicate work but at least it would avoid the raciness inherent in having both IDE and CLI share the same out/ folder

4. Some things can be improved in IntelliJ-Scala and VSCode-Metals: e.g. jumping to definition on build.foo.bar should bring you to the foo/bar/package.scala file with the header package build.foo.bar. Not sure why it doesn't already work (maybe because we're not in build/ folder?) but this seems like something that should be fixable

5. Some of the boilerplate introduced in https://github.com/com-lihaoyi/mill/pull/3426, e.g. the requirement for package declarations, comes from the desire to keep IDE support working despite the IDE not knowing about the synthetic code wrappers we introduce to wrap the build script files. If we could teach the various tools about these wrappers (e.g. through https://github.com/build-server-protocol/build-server-protocol/pull/673), such boilerplate becomes unnecessary and can be dropped

6. If https://github.com/com-lihaoyi/mill/issues/3451 lands, we can probably support Kotlin without https://github.com/com-lihaoyi/mill/issues/2598 by just hardcoding support for mill.kotlinlib.* inside of mill.bsp

7. Currently loading IntelliJ on the com-lihaoyi/mill repo takes a while. VSCode takes a while too. Some of that comes from compiling everything necessary to build assemblies which we pass to forkEnv, but maybe some of that can happen in parallel (this might happen for free in 0.12.0?) or some of it could happen asynchronously after the main project sources/deps/etc. has already loaded. We should measure that timing and see what can be done to improve it, whether via patches to the IntelliJ-Scala/Metals plugins or via changes or workarounds in Mill itself. Or maybe we can do forkEnv on demand only when someone asks for something to be run

• This may already have improved since https://github.com/com-lihaoyi/mill/pull/3457

[lihaoyi]

@alexarchambault will be picking this up in September

[lefou]

Is this about BSP or GenIdea?

[lihaoyi]

I was imagining BSP, since it's the "default" for someone opening a Mill project with IntelliJ, and any improvements there would hopefully apply to VSCode as well

[lefou]

Oh, I haven't realized, that IntelliJ is detecting Mill projects now, just like vscode-metals. Although, I think, the IDE should ask or at least inform the user about generating a BSP connection, and about the choices the user has (e.g. which BSP server to use).

[lihaoyi]

Yeah once you open up a Mill project, I get this popup telling me it's loading it via BSP

[lefou]

I think the key to better BSP support in Mill is a BSP test suite, which we currently lack.

[lihaoyi]

Updated the PR description with what major improvements that can be made to the IntelliJ/VSCode/BSP setup.

[nafg]

To be clear, I'm not 100% certain my issues are from using multiple Mill instances, although I very often do so it's a good hypothesis.

Also, while having a separate folder is an option (e.g. Bleep does this), to my (ignorant of internals) mind, it seems like it would be more elegant if all the clients are using the same server anyway, to just have the server manage tasks more intelligently somehow.

[lihaoyi]

Going to close this since at least BSP-Intellij seems to work great now. The VSCode side probably needs to love but that can be tracked separately