Metals v2 import errors

[filipwiech]

Describe the bug

Project setup:

• SBT 1.12.1
• Scala 3.8.1
• Metals v2.0.0-M9 & 2.0.0-M9-119-1ea725fc-SNAPSHOT
• Zed editor v0.235.0 with Scala extension v0.2.2

After opening a fresh project checkout in the Metals logs I can see that the new MBT import seems to have finished and was really fast:

2026.04.24 13:43:10 INFO  mbt-v2: indexing 4014 files
2026.04.24 13:43:10 WARN  [default] no logical packages found in source path (mode: MBT)
2026.04.24 13:43:13 INFO  time: mbt-v2 loaded index for 4014 files in 2.72s

Clicking around the project at least some of the "go to definition" calls work. However, there are some issues:

• There's a persistent "Sync (0%)" progress message visible in the LSP status bar, never going away after 15+ minutes. In the LSP logs I see that Metals is indeed still sending $/progress request to the editor every second.
• There's 1000+ error diagnostics reported. It's hard to identify everything relevant, especially since some of it cascades, but the top main problems seem to be:
  • Unrecognized imports from third-party dependencies outside of the Scala and Java standard library:
    import io.circe |object circe is not a member of package io (scala presentation compiler)
  • Unrecognized star (*) imports, even from the internal project sources or from the Scala library:
    import scala.jdk.CollectionConverters.* |value * is not a member of object scala.jdk.CollectionConverters (scala presentation compiler)
  • Unrecognized imports from the companion objects:
    import com.package.SomeObject.SomeEnum |value SomeEnum is not a member of object com.package.SomeObject (scala presentation compiler)
    import com.package.SomeObject2.myFunction |value myFunction is not a member of object com.package.SomeObject2

There might be more, but I suspect most, if not all, errors stem from the missing types. 👍

Expected behavior

No response

Operating system

macOS

Editor/Extension

Other

Version of Metals

v2.0.0-M9, 2.0.0-M9-119-1ea725fc-SNAPSHOT

Scala version/s

3.8.1

Extra context or search terms

No response

[tgodzik]

Thanks for reporting!

There's 1000+ error diagnostics reported. It's hard to identify everything relevant, especially since some of it cascades, but the top main problems seem to be:

This is expected if the build is not imported nor there is a .mbt/mbt.json file with a list of dependencies.

https://metals-lsp.org/#3rd-party-dependencies

The sync issue might be related to a prompt for import, this my guess but we would need to dig in there.

[filipwiech]

Thanks for a quick answer! 😄

Oh, I saw the webpage, I just misunderstood it. I thought that since SBT is marked as "supported", while Maven and Gradle are "setup required", and later there are only instructions for Maven and Gradle about how to import third-party dependencies, then for SBT it will be done out of the box. 😅 Are there plans to have Metals export the required MBT index file from the SBT automatically? Also, haven't looked into it yet, but if I understand it correctly since #8316 if I provide something like .mbt.sh script in the project root it will be automatically called by Metals to (re)generate the MBT JSON whenever it detects a change in the SBT build definition (like it currently asks for re-import)? 🙂

BTW I was prompted by Metals if I want to import the new SBT workspace, but at this point it goes back to the usual Bloop/BSP import, which kind of defeats the main selling point of Metals V2 I think. 😉

Sorry for a lot of questions, I know it's all still work in progress, and will be documented and improved in the future, but the lightweight MBT import is just too good to ignore. 😅

[filipwiech]

OK, some updates:

• Updated to the latest Metals version 2.0.0-M9-166-47c0722b-SNAPSHOT.
• Created SBT task to generate the .metals/mbt.json file with all the project dependencies. In the end didn't use the script exporter path that I've mentioned above, because when I began to think about downloading source JARs and handling transitive dependencies it all started to get complicated really quickly. Using SBT classpath it's much simpler, although not very portable between different projects.

Without mbt.json present:
One more observation about the previous scenario without the mbt.json index. After restarting the editor after the initial project import, Metals seems to switch from the MBT to a broken Bloop import on its own. The LSP doesn't work (no diagnostics, go to definition, etc.), Metals complains about missing .bloop folder (because indeed it's not there), Bloop server starts running in the background. To get back to the MBT mode I had to remove the .metals folder from the project.

With mbt.json present:
Metals starts in MBT mode (even after editor restart, one time it even asked for MBT re-import), according to the logs MBT indexing finished, "Sync" status disappears. There are no diagnostics, LSP doesn't work. There is a lot of the following messages in the logs:

2026.04.24 17:23:58 INFO  compiler crashed due to an error in the Scala compiler, retrying with new compiler instance.

Looking into the Metals Doctor, they all appear to say the same thing:

<...>
presentation compiler configuration:
Scala version: 2.13.18
<...>
scala.reflect.internal.FatalError: object Array does not have a method apply

Not sure if it's a mismatch between Scala versions, since the project is in Scala 3? 🤔

[filipwiech]

One more update, after passing "fallbackScalaVersion": "3.8.1" to the Metals settings, there's now much fewer of those presentation compiler errors. To be precise, there's none in the Metals logs (sometimes maybe a couple), but there are a few visible in the Doctor reports. Looks like there are still a bunch right after startup, but then they don't show up anymore when interacting with the project files. The ones that are logged are still the same ("object Array does not have a method apply" + Scala 2.13.18). Metals Doctor now shows project as Scala 3.8.1 and not 2.13.18 as well. LSP still doesn't work unfortunately. 🙁

There's also this in the Metals logs, no idea if it could break the LSP server:

2026.04.24 18:04:26 ERROR Unexpected error initializing server: 
java.lang.UnsupportedOperationException
	at org.eclipse.lsp4j.services.LanguageClient.refreshSemanticTokens(LanguageClient.java:193)
	at scala.meta.internal.metals.clients.language.ConfiguredLanguageClient.refreshSemanticTokens(ConfiguredLanguageClient.scala:190)
	at scala.meta.internal.metals.MetalsLspService.$anonfun$onWorksheetChanged$4(MetalsLspService.scala:1995)
	at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:503)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.lang.Thread.run(Thread.java:1583)

Or maybe at this point this is caused by the #8146? 🤔

[tgodzik]

One important thing to mention, and why we are still at milestone phase, is that the Scala 3 support is not yet finished. It should work in 3.8.4 and 3.3.8, but before it will not be usable with just MBT json file.

Not sure if it's a mismatch between Scala versions, since the project is in Scala 3? 🤔

You can specify the scala version for the namespace or use the fallback, otherwise there might be a weird issue. The apply one seems to be an incompatibility when mixing different scala versions on the classpath, though not sure.

After restarting the editor after the initial project import, Metals seems to switch from the MBT to a broken Bloop import on its own

Looks like a bug that was fixed in main, I am porting all the changes to main-v2 as another thing we need to do before fully releasing.