-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
document scalafixOnCompileConfig key & scalafixOnCompile shortcomings #1211
Conversation
/cc @taisukeoe |
93f7f6d
to
86cae56
Compare
b26c567
to
6b576c8
Compare
Although this looks like an easy way to use Scalafix as a linter, use this | ||
feature with care as it has several shortcomings, for example: | ||
|
||
1. Some rules such as `RemoveUnused` can be counter-productive if applied too | ||
often/early, as the work-in-progress code that was just added might disappear | ||
after a simple `test`. | ||
1. If you run many semantic rules by default, the last one(s) to run might see | ||
stale information and fail the invocation, which needs to be re-run manually. | ||
This is [not specific to `scalafixOnCompile`](https://github.com/scalacenter/scalafix/issues/1204), | ||
but the problem becomes much more visible with it. | ||
1. To keep the overhad minimal, `scalafixCaching` is automatically enabled when | ||
`scalafixOnCompile` is, which can cause unexpected behaviors if you run into | ||
false positive cache hits. `scalafixCaching` can explicitly be set to | ||
`false` in that case. | ||
1. Non-idempotent rewrite rules might get you in an infinite loop where sources | ||
never converge - not specific to `scalafixOnCompile` either, but rather | ||
confusing when triggered automatically. | ||
1. Bugs in rule implementations can prevent you from getting a successul | ||
`compile`, blocking testing or publishing for example | ||
|
||
Some of these shortcomings can be mitigated by the `scalafixOnCompileConfig` | ||
setting key, which allows to use a separate configuration file whenever | ||
Scalafix is triggered by `compile`. This way, Scalafix can execute a | ||
different, safer set of rules compared to the regular `scalafixConfig` that | ||
remains used for explicit `scalafix` & `scalafixAll` invocations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@taisukeoe I have (shamelessly) included your own concern in this list. Feedback very much welcomed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bjaglin Great capture 👍 Thank you very much!
In the future, it would be nicer to describe what kind of rules are recommended for on-compile, although I haven't found the adequate words yet.
The safest way is to recommend only diagnostic rules such as DisableSyntax, while there are few rules only for diagnostics. I feel it is a bit too conservative and might miss some useful combinations.
So at this moment, I'd agree with your explanation.
6b576c8
to
d9898fa
Compare
d9898fa
to
dc13b92
Compare
dc13b92
to
561f777
Compare
Considering scalacenter/sbt-scalafix#148 (review), I have spinned-off pure |
Closing this as obsolete, since #1213 was merged and the strategy for scalacenter/sbt-scalafix#148 is revisited in #1217 |
Companion PR of scalacenter/sbt-scalafix#148. It is still in discussion but drafting the public doc helps weighting-in pros & cons I believe.