Separate versioning of sbt-scalafix and scalafix

[mlachkar]

• Separate versioning of sbt-scalafix and scalafix-core similar to sbt-scalafmt and scalafmt-core. Users should declare the Scalafix version in .scalafix.conf so that clients like Metals or maybe IntelliJ can load the correct version of Scalafix without having to inspect project/plugins.sbt

• It will make easier the release of scalafix, which is now depending on sbt-scalafix.

#fixes #1084

[bjaglin]

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 have a good solution for that though, as we might want to signal 1.0 at the same time for scalafix-core and sbt-scalafix.

[mlachkar]

I agree that it's quite annoying to specify the sbt-scalafix version, and then add a version inside the scalafix.conf from the user point of view, that looks almost the same. Moreover, I wonder if people will update the version inside .scalafix.conf (except if scala steward is able to manage this).

On the other hand, I think that those two versions should be independent since semantically they are different and they could occur independently. It will make easier the release management.

I wonder if it's possible to have a default value for scalafix version, provided by the sbt plugin, which will need a commit to evolve, but not an urgent one (avoiding the error when fetching artifacts for really early adopters ^^ ). The scafix-version config, will be used only for the advanced user (metals for example).

So my idea is not to show directly this version conf to avoid the confusion that raises from "versions remaining almost the same". What do you think ?

[olafurpg]

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 sight but it helps clarify that the two versions are independent. I regret we didn't do that with sbt-scalafmt (it was proposed).

I would require the version field in .scalafix.conf from scalafix-core:1.0.0 going forward. Otherwise I am concerned many users will stay on old scalafix versions using the latest default from scalafix.

One problem I see with this scheme is that sbt-scalafix won't know what version of SemanticDB to install since it's provided by scalafix-interfaces. The options I see to fix this problem are

• keep sbt-scalafix and scalafix-core versions in sync and pay the complexity price for releases
• dynamically fetch and load resources for scalafix-interfaces.jar that matches the version in .scalafix.conf
• require users to additionally specify semanticdb version in .scalafix.conf

I'm not sure what the best solution is 🤔

[mlachkar]

why couldn't we evolve the default value of scalafix with releases?

I don't think users should specify semanticdb version, it's internal to scalafix (they don't know much about which one is the correct one).

[bjaglin]

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 (backed by Scalafix.classloadInstance().scalametaVersion). However, sbt 1.3.x's semanticdbVersion being a setting key, we would need it to be a setting key too, causing an eager lookup at sbt init time...addCompilerPlugin does not have this limitation though (so the lookup could remain lazy in a task key).

[bjaglin]

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 sight but it helps clarify that the two versions are independent. I regret we didn't do that with sbt-scalafmt (it was proposed).

👍

[olafurpg]

The biggest motivation to separate versioning of sbt-scalafix and scalafix-core is that it means other integrations (mill, gradle, maybe metals) also don't need to cut a new release for every new Scalafix release. It would be hugely beneficial if all clients can use scalafix-interfaces to support any version of Scalafix. The current situation is the sbt-scalafix and scalafix-core must be released together, and it usually means that other clients end up staying on old Scalafix versions.

That looks like the best option to me.

I agree.

One option to avoid the eager sbt init lookup is to have users install sbt-scalafix in the meta-meta-build project/project/plugins.sbt. We could read .scalafix.conf from there and expose the version in project/plugins.sbt. I'm still not a fan of that approach because it's unorthodox I am concerned it would be confusing for users.

[bjaglin]

I'm still not a fan of that approach because it's unorthodox I am concerned it would be confusing for users.

Indeed, although technically it's a good workaround!

Would it be an option to challenge in sbt the fact that semanticdbVersion is a setting key? By challenging, I mean keeping it around for compatibility but introducing a semanticdbCompilerPluginVersion task key with the exact same semantics.

[olafurpg]

@bjaglin it looks like semanticdbVersion is eventually used by allDependencies which is a task key so it might be possible to make that change upstream in sbt (cc/ @eed3si9n ). However, such an approach would only work with new versions of sbt, which is a bit unsatisfying.

[bjaglin]

Yes I don't think there is a need for it to be a setting key. Regarding sbt 1.3.x: I know it's possible to declare a task key twice, so maybe we could have the "new one" in autoImports and affect libraryDependencies ourselves. Not sure how the duplicated key in scope for sbt 1.4.x clients would play though.

[olafurpg]

As a starting point, I think it's fine to fetch the semanticdb version via scalafix-interfaces.jar using coursier resolution during sbt init. There will be minor overhead from the resolution but I estimate it will only be a few milliseconds when cached (if I had to take a wild guess, around 20ms). This overhead is unavoidable regardless of the approach we take.