Shade Scalameta v1 in sbt-scalafmt

[olafurpg]

Scalafmt is currently using Scalameta v1 and Scalafix uses v2. See #975 for the ticket on upgrading Scalafmt to v2. However,

• I don't know when me or someone else will get around to upgrade
• there is a growing need to be able to use sbt-scalafmt and sbt-scalafix together but by default this will not work due to class incompatibilities between Scalameta v1 and v2.

As a temporary relief, we could publish sbt-scalafmt with the following packages shaded

• scala.meta
• metaconfig
• org.langmeta (maybe not necessary)

Additionally, we may need to exclude scalapb from the scalafmt's transitive dependencies. Scalafmt doesn't use it but it's brought in transitively. This workaround would allow sbt-scalafix and sbt-scalafmt to live happily together on the same classpath without doing classloading hacks in sbt-scalafix.

[fommil]

@alexarchambault TL;DR if sbt-scalafmt shaded scala.meta then we'd be able to have a much more efficient sbt-scalafix and avoid classpath nonsense. Do you think it'd be hard to do this?

[alexarchambault]

scala-meta shoudn't rely much on reflection, so I guess that should work… There's an example of how to do that in coursier, see around here and here.

Note that the shadeNamespaces setting is optional. It only aims at speeding things by shading whole namespaces rather than by shading the classes found in it one-by-one. But one has to be sure that all classes from that namespace are indeed in the shaded dependencies.

[pauldraper]

This is one of the cases where separate classloader (e.g. the approach of https://github.com/lucidsoftware/neo-sbt-scalafmt) helps.

[fommil]

That brings is own problems, the multiple classloaders are unusable on large projects because of memory.

[olafurpg]

I am leaning towards biting the bullet and upgrade to meta v3. I already take the first steps in this direction in #1145. Shading the dependency is not a long term solution

[fommil]

that's awesome news!