Overhaul build file management with new build.mill/package.mill format #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 Add .mill extension to Scala language support JetBrains/intellij-scala#666 Basic support for new .mill and .mill.scala source files scalameta/metals#6752 Add .mill extension to Scala language highlighting github-linguist/linguist#7028, might just need to shepherd those changes in

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

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

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

Some of the boilerplate introduced in Overhaul build file management with new build.mill/package.mill format #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 [WIP] Add buildTarget/wrappedSources to protocol build-server-protocol/build-server-protocol#673), such boilerplate becomes unnecessary and can be dropped

If First Party Support for the Kotlin language (2000USD) #3451 lands, we can probably support Kotlin without Provide a way to extend the Mill BSP server #2598 by just hardcoding support for mill.kotlinlib.* inside of mill.bsp

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