Scalafix & built-in Scala CLI rules in fix, or the future of the fix sub-command

[Gedochao]

Context

This is an effort to continue the discussion from #3400 (comment) in an easier-to-reference thread.
cc @bjaglin @tgodzik

As scalafix integration has become an experimental feature, it's been discussed how scalafix rules should co-exist with pre-existing Scala CLI fix rules (or, well, rule, since at this time we have exactly one).

Experimental status of the fix sub-command

The fix sub-command is still under construction, there's still a number of pending issues (see the subcommand:fix label), with more likely to be created as we go.

scalafix integration has been available since Scala CLI v1.6.0: https://scala-cli.virtuslab.org/docs/release_notes/#%EF%B8%8F-experimental-scalafix-integration

So basically, while a showcase is available, nothing is set in stone just yet.

How things are right now (Scala CLI v1.6.2, as of starting this discussion)

https://scala-cli.virtuslab.org/docs/commands/fix

scala-cli fix . --power
# The `fix` sub-command is experimental
# Please bear in mind that non-ideal user experience should be expected.
# If you encounter any bugs or have feedback to share, make sure to reach out to the maintenance team at https://github.com/VirtusLab/scala-cli
# Running built-in rules...
# Writing project.scala
# Removing directives from Smth.scala
# Built-in rules completed.
# Running scalafix rules...
# Starting compilation server
# Compiling project (Scala 3.6.3, JVM (23))
# [warn] ./Main.scala:2:7
# [warn] unused local definition
# [warn]   val unused = "unused"
# [warn]       ^^^^^^
# Compiled project (Scala 3.6.3, JVM (23))
# scalafix rules completed.

By default, both Scalafix and Scala CLI built-in rules are enabled to be run.
They can be controlled, respectively, with --enable-built-in and --enable-scalafix flags.

Why do we even have 2 different sets of rules right now?

What is currently referred to built-in rules is actually the former functionality of the fix sub-command. It used to be just a simple util for migrating using directives from across a Scala CLI project to a project.scala configuration file, eliminating duplicates and getting rid of the warnings tied to keeping directives spread across multiple files. It has been initially released as experimental and never been promoted to stable.

Potential other rules tied to using directives were being discussed, which is why the door for more built-in functionalities has been left open (thus, we speak about built-in rules, plural, while we currently only have a single one).

As scalafix integration got added, we've decided in the Scala CLI maintenance team that it'd make more sense to add it as part of the existing fix sub-command, rather than to create a new scalafix sub-command.
The delivered functionality is adjacent and makes sense to be in one place, as well as scala-cli scalafix didn't seem like great syntax (not to mention scala scalafix, if one uses the language installation scala command).

Subject of discussion

• should we keep it as a multi-purpose fix sub-command as it is, scalafix integration being one of its features?
  • note that making fix scalafix-only would require engineering effort to migrate the existing built-in rule as a Scalafix rule
  • alternatively, we could disable built-in rules by default in fix, and enable them in a sister sub-command (scala-cli build fix has been suggested)
• how should we configure individual built-in rules (allowing to enable/disable them individually)?
  • should we have a .scala-cli-rules.conf configuration file, following the same syntax as .scalafix.conf?
  • should we configure built-in rules via using directives, instead?
  • while it'd be tempting to keep them in .scalafix.conf, I think it might be a bad idea, since that'd make the Scalafix configuration file less portable (it'd accept configurations which would only ever be supported with Scala CLI, and then stop working when exported to SBT/Mill)
• rather than built-in rules, we could refer to the non-scalafix rules as Scala CLI rules. Would that be more intuitive? (scala-cli fix . --enable-scala-cli-rules=false)
• any other ideas and/or feedback regarding the fix sub-command is welcome.