(The Scala Center team is dedicated to providing regular and transparent community updates about project plans & progress. In this forum we created a new topic category to allow quicker orientation going forward: “Scala Center Updates”. Even though all feedback is welcome, we keep the right to make executive decisions about projects we lead. Overview of all our activities can always be found at https://scala.epfl.ch/records.html)
Scalafix Release v1.0
Scalafix, which is a refactoring and linting tool for Scala, could be a key factor in the success of Scala 3 migration. For that, the tool needs to evolve and to integrate some necessary features described in this github issue.
The main issue is that Scalafix rules are currently not published against a specific version and are supposed to work with all Scalafix supported versions. In reality, this is not the case, especially for rules that interface directly with the compiler (for example #998).
Next release should contain some important features that will allow us to use Scalafix for Scala migration:
- Rules will be bound to a specific Scala version. In order to support all Scala versions, rules will need to cross build over all the desired versions.
- Migrate Scalafix to Scala 2.13. This migration will require fixing some rules that do not work currently with Scala 2.13.
Scalafix Integration in Metals
Scalafix is usually used in batch mode via sbt to fix the entire code base before committing a change. We can reuse it by integrating Scalafix directly in Metals to provide new refactoring possibilities to the IDE. This change will unblock the implementation of some missing features such as “organize imports” or “remove unused”.
One of the challenges with this integration is the user experience which requires special attention when compared to the technical aspects. This is why we plan to first focus on a POC, then gather user feedback and finally implement the Scalafix integration (#1675).
Currently, we see several options:
Applying Scalafix rules through metals based on the project’s Scalafix configuration. We could have different commands for:
apply all rules on file,
apply only remove unused rule,
apply only organize imports rule. The first command would be the heaviest, so maybe it will only be available via command and the rest might be made accessible also via Code Actions (remove unused) or shortcuts (organize imports).
Applying changes in metals using Scalafix regardless of the project’s configuration, but with limited scope (“organize imports” or “remove unused”). In this case Scalafix usage would be internal and not exposed to the user.
A mix of both approaches