What is recommended dev setup for Mill?

[shishkin]

Trying to setup my development environment and a project using Mill as well as working on Mill's codebase itself has been a challenging task for me. I tried VS Code Metals and IntelliJ, and both had issues. I'm also completely lost now in whether I should have Mill generate build server files or just use the default from the IDE, and whether I should use Bloop or BSP.

What is the recommended dev setup for Mill that just works™?

[lefou]

From my personal point of view, the current best experience can be gained by generated IntelliJ IDEA project files. But I have to say that some of my project use more than just Scala and Java, where you on your own when using BSP. But others use already BSP. As you already have guessed, each variant has different issues so it's a good idea to report issues or comment on already reported issues. Especially if you want to use Metals (which is de facto the case when you don't use IntelliJ BSP), the bloop module is probably the better choice, but this is only a guess. Others can probably add more.

[lefou]

Yeah, whenever you make significant changes, e.g. new modules or changed API dependencies, you will want to regenerate. IntelliJ has no notion who generated the project files.

[shishkin]

Thanks! And what setup would be reasonably well suited for automatic build imports when tinkering on the build scripts?

[lefou]

If I understand you correctly, then you probably want to use one of the BSP setups. Both Bloop and Mill BSP detect changes to the build files which triggers a workspace reload, but in it's current state Mill BSP will have severe issues when the build files contain errors.

[shishkin]

Yes, I can confirm that using Metals with Bloop on the Mill codebase does work when done from a clean slate. I don't know what issues I had with this setup initially - probably transient.

On another note, this discussion in Metals enhancements made me more skeptical about Bloop. I like Mill because it's fast and simple and doesn't require a 2GB daemon process alongside it. And being lightweight and disposable is not a goal for Bloop. Then what is Mill's longer-term strategy for build server and IDE support? Is it own BSP implementation or contrib/bloop?

[lefou]

Definitely the built-in BSP. It has by design the highest potential. Also it uses all toolchains as they are meant to be used by Mill whereas Bloop tries to re-create everything. It can also to date support more/other languages than Bloop. But as I said, there are some issues that need to be fixed to be fully operational. E.g. if you just code and seldomly touch the build files, you might never see them. But there is also Metals Support, which need to get better (out of the box). Unfortunately also on Metals side, things can be improved. For example, Metals tend to require Debug Support (Debug Adapter Protocol) to run tests. This doesn't makes sense, but it was probably easier for them. But we currently haven't that implemented. We support tests but Metals is simply not using it.