scala-3-migration-guide
scala-3-migration-guide copied to clipboard
scalacenter
Document editors (metals) support for cross-built projects
AFAIK there's no documentation available rn about using an editor (vscode) together with metals and have support for both Scala 2.x and Scala 3 in a single project. It would be nice if that rather common use case was supported and documented.
I agree that we are lacking documentation on this side. But it is a general concern about cross-built project (version and platform).
@tgodzik Don't you think it should be documented in the Metals website? This way we could add a link from here and maybe elaborate further for the context of the migration.
Not sure where to add it, we are saying here that Scala 3 is supported. We could add it also to overview, but the default behaviour is that Metals supports multiple versions at the same time.
We could add a mention in migration guide that multiple versions are supported and link to Metals with a comment to check exactly what is supported.
Thanks for your replies.
Metals does support both languages out of the box but as far as I can tell, it does not support a single project having sources in both Scala 2 and Scala 3. ie. if you have macros for both languages in different folders (src/scala-2 and src/scala-3).
Maybe something needs to be configured or a specific setting set in sbt, but I could not get it working.
Metals does support both languages out of the box but as far as I can tell, it does not support a single project having sources in both Scala 2 and Scala 3. ie. if you have macros for both languages in different folders (src/scala-2 and src/scala-3).
I guess you are using a crossScalaVersions which is a stateful way of cross building (doc in sbt).
It means that, at any given time, sbt only knows about one scalaVersion and consequently bloopInstall configure Bloop for that single version. If you run ++<scalaVersion, Bloop won't be aware of it until bloopInstall is run again (or Import build in Metals).
It is slightly better with sbt as the build server because Metals will always be in-sync with sbt when compiling. But you still need to re-import the build so that Metals is aware of the new scala-version source directory. (That can be improved in future versions with buildChange notification in BSP, that is not yet supported by sbt).
Using sbt-projectmatrix (doc here) works a lot better with Metals because it creates one project (one BSP build target) for each scalaVersion.
So yes we should document that sbt-projectmatrix is well supported by Metals but crossScalaVersion is not really.
We could try to always run +bloopInstall, but we would need to do a change in Bloop to generate separate build targets for each scala version. It should be simple enough though.
Indeed I'm using crossScalaVersions. I would guess most cross-built projects out there do the same so it'd be great if it could "just work".
While all of the above is true, and it would be nice if it worked, none of this is specific to Scala 3. If you have sources in scala-2.12 and scala-2.13, only one of those will be recognized by Metals. I don't think IntelliJ fares any better.
I did not know that. Although while it's correct it does not make it any less of an issue.
You are less likely to run into the issue between Scala 2.12 and 2.13 bc. they are mostly compatible. OTOH If you cross-build for 2.13 and 3.0, you are almost guaranteed to run into this since the languages are so different. I worry that this lack of ergonomics will in practice hinder the work to cross-publish and in the end encourage libs maintainers to just stick to Scala 2.
@jto You are totally right. I think we should be able to work on it soon. Followed up with an issue here https://github.com/scalameta/metals/issues/2287