-
Notifications
You must be signed in to change notification settings - Fork 43
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
add --triggered support when scalafixOnCompile is enabled #169
Conversation
taskKey[Seq[String]]( | ||
"Pass extra arguments to scalafix only when scalafix is triggred by compilation. " + | ||
"Only --triggered argument is passed by default." | ||
) |
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.
scalafixArgsOnCompile
TaskKey is intended to be more extensible than just passing --triggered
.
For example:
scalafixArgsOnCompile += "--check"
allows to lint on compilation and rewrite on explicit invocation with the same scalafix configurations.- Preferring
TaskKey
overSettingKey
becauseTaskKey
can rely on otherTaskKey
values, whilescalafixArgsOnCompile
is rarely referred by otherSettingKey
s. (Analogous toscalacOptions
)
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.
See my comment in scalacenter/scalafix#1217 (review), I am questionning the need for such a "open" customization point if it's just for --check
. Do you have something else in mind?
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.
I'd think several alternatives of arguments on compilation in my mind.
-
--triggered --check
or--triggered
: These should work well in most use cases, but it might be confusing if.scalafix.conf
gets bigger and a lot of difference in configuration betweentriggered
and explicit invocation. -
--config .scalafix.oncompile.conf
: In case.scalafix.conf
is already big, or overlaying settings will make huge difference between on-compile or not, it would be easier to divide-and-conquer scalafix.conf file rather thanoverlaying
. -
--check
: This makesscalafixOnCompile
just a linter in the simplest way. No triggered overlay. This might be a matter of preference, since this can be the same as--triggerd --check
as long as.scalafix.conf
has notriggered
key.
Disclaimer: these alternatives are based on my assumptions. While I haven't seen HUGE .scalafix.conf
which has to be divided and conquered for now, it might be chicken or egg.
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.
I have reconsidered this customization point, and removed it for now.
There are few rules which may break source codes in running on-compile, and can be managed only with --triggered
.
d3c1b9b
to
ed730be
Compare
Question: what is the best way to test Currently I change |
There will be a SNAPSHOT published once scalacenter/scalafix#1217 is merged, so you should be able to get the CI green at that point. For now, I guess you could hardcode the SNAPSHOT in
|
@@ -107,7 +113,7 @@ object ScalafixPlugin extends AutoPlugin { | |||
compile.value // evaluated first, before the potential scalafix evaluation | |||
if (scalafixOnCompile.value) | |||
scalafix | |||
.toTask("") | |||
.toTask(scalafixArgsOnCompile.value.mkString(" ", " ", "")) |
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.
it would be nice to update the scripted test about caching, to make sure that an explicit scalafix
after a compile with scalafixOnCompile
does run rules that are not defined in the triggered
overlay.
Given the current cache implementation, I think an explicit scalafix
invocation will no longer benefit from the cache of the previous compile
invocations after this PR. That's safer, as we can't assume that the configuration is effectively the same and add --triggered
in
sbt-scalafix/src/main/scala/scalafix/sbt/ScalafixPlugin.scala
Lines 510 to 511 in 8284c35
case "--check" | "--test" => | |
// CHECK & IN_PLACE can share the same cache |
triggered
section in the configuration.
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.
Thank you for your suggestion. I'll check how cache works later!
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.
--triggered
is considered as a cache key only if there is triggered
section in .scalafix.conf
.
@taisukeoe I hope you are well! Any update on this? Are you reconsidering the need? (in which case we could deprecate/clean up the parts in the scalafix repo) |
@bjaglin |
2a11644
to
b6ee18d
Compare
b6ee18d
to
1407d55
Compare
@bjaglin I'm very sorry for making you wait. Now this PR is ready. Would you please review this when you have time? |
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.
Thanks for taking this to the finish line! I really appreciate the extensive testing 🙇 Structure and code LGTM! Please see a few naming/cosmetic suggestions.
Next step would be to document this in the website (https://scalacenter.github.io/scalafix/docs/users/configuration.html looks like a good place?) - unfortunately that's on the scalafix repo!
-> scalafix --triggered --check | ||
$ delete src/main/scala | ||
|
||
# files should not be re-checked in scalafix explicit invocation after scalafix runs onCompile if any triggered configuration is not defined |
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.
# files should not be re-checked in scalafix explicit invocation after scalafix runs onCompile if any triggered configuration is not defined | |
# files should not be re-checked in scalafix explicit invocation after scalafix runs onCompile if no triggered configuration is defined |
@@ -21,3 +21,8 @@ lazy val rewrite = project | |||
addCompilerPlugin(scalafixSemanticdb) | |||
) | |||
.settings(scalafixConfigSettings(IntegrationTest): _*) | |||
|
|||
lazy val args = project |
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.
what does args refer to? what about
lazy val args = project | |
lazy val triggered = project |
@@ -529,13 +530,29 @@ object ScalafixPlugin extends AutoPlugin { | |||
// custom tool classpaths might contain directories for which we would need to stamp all files, so | |||
// just disable caching for now to keep it simple and to be safe | |||
throw StampingImpossible | |||
case "--triggered" => | |||
// If there is a triggered section in a default config file, --triggered flag should be accounted. |
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.
looking at the implementation, it seems to work also for non-default configurations?
// If there is a triggered section in a default config file, --triggered flag should be accounted. | |
// If there is a triggered section in the config file, --triggered flag should be accounted. |
"Run Scalafix rule(s) declared in .scalafix.conf on compilation and fail on lint errors," + | ||
"with overlaying configuration by `triggered` sections if defined in .scalafix.conf file." + |
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.
The plural in "sections" confused me a bit. I was using "overlay' as a verb in our previous discussions but I wonder if "overriden" isn't more clear in that context. What about:
"Run Scalafix rule(s) declared in .scalafix.conf on compilation and fail on lint errors," + | |
"with overlaying configuration by `triggered` sections if defined in .scalafix.conf file." + | |
"Run Scalafix rule(s) declared in .scalafix.conf on compilation and fail on lint errors. " + | |
"Default rules & rule configuration can be overriden using the `triggered` section." + |
val confInArgs = interface.args | ||
.collect { case Arg.Config(conf) => conf } | ||
.flatten | ||
.lastOption |
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 Thank you for your quick review! I've modified wordings. I think I can finish documentation in this couple of days, by next weekend at the latest. Is it OK for you, or should I hurry a bit more? |
@bjaglin |
This is a companion Pull Request of scalacenter/scalafix#1217 .
This adds
--triggered
support whenscalafixOnCompile
is enabled.