Brice Jaglin

Workaround: https://github.com/scalacenter/scalafix/blob/7cfbad5582705b11df455d8606a1007b23604ef1/project/ScalafixBuild.scala#L220-L235

A first solution would be to only export some of the modules of the matrix as recommended in https://github.com/sbt/sbt-projectmatrix/issues/25#issuecomment-623850021.

@tgodzik I didn't get the time to look at it myself. @rvacaru can you report your problems here?

This needs to stay as it's not related to MiMa/sbt-version-policy.

Thanks for the report! This looks like a problem in the [SemanticDB scala compiler plugin](https://scalameta.org/docs/semanticdb/guide.html#scalac-compiler-plugin), before scalafix even gets a chance to run. Could you provide more information about your...

I think we should start with a `Source3` rule that turns Scala 2 code into Scala 2 code that compiles under `-Xsource:3`. It's really what people migrating must do, and...

I wonder if this "migration" rule should be available in scalafix-rules though - could it be implemented/tested in https://github.com/scalacenter/scala3-migrate?

From my experience with `scalafmt` / `sbt-scalafmt`: it can be confusing for the users if the release cycles are distinct but the versions remain in the same vicinity. I don't...

> dynamically fetch and load resources for scalafix-interfaces.jar that matches the version in .scalafix.conf That looks like the best option to me. Implementation-wise, https://github.com/scalacenter/sbt-scalafix/blob/9d7d17743208a4a04fac5138d947f5c1ecfabe93/src/main/scala/scalafix/sbt/ScalafixPlugin.scala#L54-L55 could be wrapped in a key...

> I think it's a good idea to have clearly distinct version numbers for sbt-scalafix and scalafix-core, for example sbt-scalafix:20.0.0 and scalafix-core:1.0.0. It might be a bit weird at first...