make it easy to run Scalafix on ALL sbt configurations

[bjaglin]

trafficstars

scalafixAll only runs Scalafix on Compile and Test by default (same behavior as sbt-scalafmt's scalafmtAll).

Suggestion: scalafixEnableAll (or scalafixEnable itself?) could automatically inject the scalafix settings on all configurations.

Originally discussed in https://github.com/fthomas/scala-steward/pull/1523#issuecomment-653673947

[mlachkar]

Should it run on all configurations by default ?

[bjaglin]

Should it run on all configurations by default ?

I guess you refer to the or scalafixEnable itself? comment? Here is my take on it a few months after opening that ticket:

• Pros
  • one-shot migrations invocations where scalafixEnable is documented will potentially cover more sources (with a limited risk of regression, as the worst thing that can happen is that the command returns an error code if some exotic configurations with sources don't work, but rewrites will happen anyway for standard configurations)
  • scala-steward benefits from that as well
• Cons
  • makes it hard for people integrating ScalafixPlugin for good in their build containing non-standard configurations that they need to explicitly follow https://scalacenter.github.io/scalafix/docs/users/installation.html#integration-tests since scalafixAll just worked after scalafixEnable

I'd say the pros outweigh the cons. That said, custom configurations are now officially discouraged, so I am not sure this is very important anyway.

The most compelling case would be for builds with IntegrationTest which is a special case, but not that uncommon. There is currently no way to run scalafix on it sources using scalafixEnable: https://scalacenter.github.io/scalafix/docs/users/installation.html#integration-tests must be followed.

[bjaglin]

If you meant that scalafixAll should target all configurations no matter if scalafixEnable was called before or not, then I believe we should take the discussion with scalafmt folks as well, since scalafixAll currently matches the scalafmtAll semantics, which are in line with what sbt recommends: https://www.scala-sbt.org/release/docs/Plugins-Best-Practices.html#Provide+raw+settings+and+configured+settings. I am not sure it's a good idea, as I don't know any other plugin "polluting" all configurations by default.

[mlachkar]

I meant this

If you meant that scalafixAll should target all configurations no matter if scalafixEnable was called before or not,

In Scala3-migrate, we decide by default when we call migrate projectID command, to do it on all configurations. I wasn't aware of sbt recommandations, and I agree that formatting/linting may be not that important to run on every configurations especially if people are not expecting this behavior. Maybe we can have something like this projectId/CustomConfig/scalafix so people can run it on other configurations. Maybe it's already possible, so in this case we may just document it.

[bjaglin]

@olafurpg @adpi2 I'd be happy to get your opinion on that one

[olafurpg]

I think it’s ok to automatically handle IntegrationTest if possible but I think it’s OK to require manual settings for other configurations. I’m glad that sbt officially discourages configurations because they really make it complicated for tools to provide a good experience out of the box.

There are BTW reasonable usecases for custom configurations where I would not expect Scalafix to interfere with. For example, in the Scalameta repo we create configurations to use different test framework flags for commands like “slow:test” and “all:test”.

[bjaglin]

Closing as no longer relevant considering the direction that sbt is taking