Towards Scalafix v1.0

[olafurpg]

Scalafix v0.9.x has been quite stable for a long time now so I think it would be nice to start preparing a v1.0.0 release. I would like to keep the current API mostly unchanged in v1.x so the upgrade should be smooth for most users. This issue is just to track what changes I think are worth getting done before we release v1.x

• cross-build Scalafix for 2.13
• change sbt-scalafix to run scalafix_2.13 by default instead of scalafix_2.12
• We may want an optional mode in sbt-scalafix to use scalafix_2.12 on 2.12 sources and scalafix_2.11 on 2.11 sources, which would unblock ExplicitResultType usage on more Scala versions. However, this would mean that custom Scalafix rules would also need to be cross-published.
• 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
• upgrade to Metaconfig v1.0 (which is not yet released)
• document breaking changes (go through https://github.com/scalacenter/scalafix/milestone/19?closed=1)

[taisukeoe]

@olafurpg
I'm excited to see v1.0.0 is approaching!

We may want an optional mode in sbt-scalafix to use scalafix_2.12 on 2.12 sources and scalafix_2.11 on 2.11 sources

Just for my curiosity, but hope it's a relevant question for everyone:

Is there any reason to give up Scalafix provide an Java-API on top of the presentation compiler option, described in #998 issue?
(I'm looking over #998 and trying to find time to solve it.)

[olafurpg]

@taisukeoe you may want to sync with @mlachkar on #998

I believe a good starting point regardless of approach would be to add 2.13 support for scalafix-core.

I'm still open to go the Java-API approach. My biggest concern with that direction is that it will be difficult to come up with generic methods since the compiler provides a lot of functionality. If we decide to only implement a small API for ExplicitResultTypes and not expand the scope of that Java API then maybe it will be OK

[bjaglin]

As a rule author, I can assume that rules built against scalafix-core 1.x (and probably earlier, since I am not sure there was ever any breaking change there?) will be forward-compatible with any scalafix-interfaces 1.x.

But how should existing rules handle a potential scalafix-interfaces 2.x? It's probably too speculative/over-engineered to include already now the scalafix binary version as a module suffix (on top of the scala version), but I guess that could be done later, and it would be scalafix-interfaces responsibility (in the logic implemented for #1151) to pick the right artifact and fail cleanly if it does not exist (instead of having runtime/linking errors).

[olafurpg]

My current thinking is to never break binary compatibility. If we need a new api we can put it under the “scalafix.v2” package. I would prefer to avoid putting the Scalafix version in the module name. Another thing we can do is let Scalafix rules declare what Scalafix version they support and have some dynamic check to validate a rule is compatible with the installed Scalafix version.

[olafurpg]

I think it’s possible to aim for no publicly facing binary breaking changes between 0.9.x and 1.x so existing rules will continue to work unchanged.

[bjaglin]

My bad, I hadn't realized that there was already versioning in place at the package level for scalafix-core (scalafix.v1.Rule), so Scalafix 1.0 really is a non-event for rule authors 👍

[olafurpg]

The scalafix.{v0,v1,v2,...} convention isn't perfect. It both complicates public APIs (IDEs auto-complete the same name that appears in different versions) and you end up copy-pasting a fair amount of code if you need to create scalafix.v2 one day.

I'm not sure if we will ever need scalafix.v2 but the option is there. The v1 API is designed so that it's possible to evolve it without breaking binary compatibility: limited case classes, limited default method parameters, internal implementation details live in scalafix.internal package.

[bjaglin]

About Scalafix 2.11/2.13 usage in sbt: there was good progress over the last weeks, and #1166 should be the last step, but what should be the strategy to promote rule authors to start cross-publishing? Would it be aggressive to have scalafixScalaBinaryVersion follow the target sources version from 1.x?

[mlachkar]

In my opinion, scalafixScalaBinaryVersion should follow the scalaVersion starting 1.x.
We could use contributors.scala-lang.org to promote cross-publishing rules. Maybe we can also use scaladex to find most external rules and open github issues for cross-compiling. Maybe also, we can start the community page on scalafix website/doc #1086