Use BSP for IntelliJ import rather than our custom intellij tasks? #778
Description
Remaining issues:
- Running compiler JUnit tests in IntelliJ through BSP fails #786 (Running compiler JUnit)
- https://youtrack.jetbrains.com/issue/SCL-19503 (Trailing commas in build.sbt)
- https://youtrack.jetbrains.com/issue/SCL-19425 (project sources not attached to build project)
- https://youtrack.jetbrains.com/issue/SCL-18361 (BSP import does not exclude target directories)
- https://youtrack.jetbrains.com/issue/SCL-19300 (Notification: sbt build scripts found for sbt project imported with BSP)
- update readme (https://github.com/scala/scala#ide-setup)
IntelliJ could never correctly import our project as a standard SBT project. IIRC that was due to an assumption that scala-library was a third party dependency, whereas in our project we have it as an internal sub-project.
Instead, we have some custom SBT tasks that fill in template IntelliJ config from ./src/intellij/*.SAMPLE and combine it with result of the update task to fill in the classpath.
SBT 1.4.x introduced support for the Build Server Protocol (BSP), which is an alternative means to import the project structure into IntelliJ (or Metals, VSCode, ...).
We should try to migrate to this as the standard way to use our project in an IDE of the users choice.
Status
- Checkout 2.13.x
- Run
sbtonce to generate./bsp/sbt.json - In Intellij, "File, New Project from Existing Sources, $CODE/scala, BSP"
The import was successful for me. In the SBT shell I left running, I saw a notification that a new client has connected.
Here's what I saw in the Build->Sync output in IntelliJ:
Processing workspace/buildTargets Processing buildTarget/sources compiling 533 Scala sources and 33 Java sources to /Users/jz/code/scala-worktrees/scala-bsp-intellij/build/quick/classes/library ... /Users/jz/code/scala-worktrees/scala-bsp-intellij/src/library/scala/reflect/package.scala:61:27: @nowarn annotation does not suppress any warnings if (!m.isAccessible: @nowarn("cat=deprecation")) { ^ one warning found compiling 160 Scala sources and 3 Java sources to /Users/jz/code/scala-worktrees/scala-bsp-intellij/build/quick/classes/reflect ... /Users/jz/code/scala-worktrees/scala-bsp-intellij/src/reflect/scala/reflect/internal/util/AbstractFileClassLoader.scala:114:43: @nowarn annotation does not suppress any warnings case null => super.getPackage(name): @nowarn("cat=deprecation") ^ one warning found compiling 326 Scala sources and 5 Java sources to /Users/jz/code/scala-worktrees/scala-bsp-intellij/build/quick/classes/compiler ... /Users/jz/code/scala-worktrees/scala-bsp-intellij/src/compiler/scala/tools/nsc/ast/TreeBrowsers.scala:218:76: @nowarn annotation does not suppress any warnings val menuKey = Toolkit.getDefaultToolkit().getMenuShortcutKeyMask(): @nowarn("cat=deprecation") // deprecated since JDK 10, replacement only available in 10+ ^ one warning found compiling 61 Scala sources and 1 Java source to /Users/jz/code/scala-worktrees/scala-bsp-intellij/test/benchmarks/target/scala-2.13/classes ... 41 deprecations (since 2.13.0) 1 deprecation (since 2.13.2) 10 deprecations (since 2.13.3) 52 deprecations in total; re-run with -deprecation for details four warnings found Processing buildTarget/dependencySources Updating Resolved dependencies Updating Resolved dependencies Fetching artifacts of Fetched artifacts of Updating Resolved dependencies Fetching artifacts of Fetched artifacts of Fetching artifacts of Fetched artifacts of Fetching artifacts of Fetched artifacts of Fetching artifacts of Fetched artifacts of Fetching artifacts of Fetched artifacts of Fetching artifacts of Fetched artifacts of Processing buildTarget/scalacOptions Notes:
- Why does it need to compile the sources? Does this mean that we can't re-import the project structure if there is an error in the sources somewhere?
- What's with the missing project names after "Fetched artifacts of "?
- Per-project scala compiler options look to be correctly propagated, including -srcpath on the library project
- There appear to be extra intra-project dependencies on the "Test" scope. This is harmless but it would be preferable if BSP could more accurately reflect the true dependencies.
- Clicking Run on a JUnit tests Just Works!
- We no longer get a sub-project for the SBT build definition itself, so lose all code-assist in there.