-
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
add --triggered flag to load overlay section in .scalafix.conf #1217
Conversation
support onCompile section in .scalafix.conf
// will be overridden by | ||
// onCompile = { | ||
// DisableSyntax.noThrows = true | ||
// } |
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.
Or should we allow to override DisableSyntax.noThrows
only,
and keep DisableSyntax.noVars = true
or other DisableSyntax settings?
I'm wondering what is the best... 🤔
Your feedback is much appreciated.
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 thought merging-shallow strategy is simpler and clearer, since users can understand what is going to run without merging Confs one by one in their mind.
However, I'd imagine several concrete use cases -- for example, users just want to turn OrganizeImports.removeUnused
into false
on compile. With merging-shallow strategy, they might face severe conf duplications especially in OrganizeImports.groups
(or it can be generalized as Conf.Lst
s), which are not pleasant.
So I have changed my mind and implementation with 342f74d .
Now Confs are merged deeply, so that users can add onCompile.OrganizeImports.removeUnused = false
with keep respecting original OrganizeImports.groups
Conf.
I'd still want to hear your opinions about this.
Thanks for following up @taisukeoe - it's vacation time here, so expect some delays for the review |
@bjaglin Thank you for your response. |
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.
Big apologies for getting back so late to this PR! Thanks for following up after our long discussion in scalacenter/sbt-scalafix#148, let's get this (and the sbt-scalafix companion to come) in before the next release!
I have a few implementation cosmetic comments, but mostly I am wondering if onCompile
is not too specific as a build tool might invoke this in a different context than compile. From your use-case, I feel like you want a specific set of rules and/or rule settings when scalafix is triggered "in the background" (which can be "sneaky" for the user). Would --non-interactive
/ nonInteractive
be a more generic name for that?
"Run only rules defined in onCompile section in .scalafix.conf," + | ||
"or rules explicitly passed via --rules" |
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.
Maybe this is a good place to mention the fact that the section only overlays the default stuff?
"Run only rules defined in onCompile section in .scalafix.conf," + | |
"or rules explicitly passed via --rules" | |
"Overlay the default rules & rule settings in .scalafix.conf with the `onCompile` section" |
@@ -242,9 +247,21 @@ case class Args( | |||
RuleDecoder.decoder(ruleDecoderSettings.withConfig(scalafixConfig)) | |||
} | |||
|
|||
// With a --on-compile flag, looking for settings in onCompile block first, and fallback to standard settings. | |||
def preProcessedConf(base: Conf): Conf = |
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.
if we use the overlay
term, this could be more precise
def preProcessedConf(base: Conf): Conf = | |
def maybeOnCompileOverlaidConf(base: Conf): Conf = |
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.
Overlay
seems to be a nicer word 👍
val confOnCompile = ConfGet.getKey(base, "onCompile" :: Nil) | ||
confOnCompile.fold(base)( | ||
ConfOps.merge(ScalafixConfOps.drop(base, "onCompile"), _) | ||
) |
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.
while you are at it, can't you extract the entire get/fold/merge logic to ScalafixConfOps
so we better understand the intent here?
@bjaglin Thank you for your reviewing! While I'd agree that Considering the nature that it adds a hook on compile, what do you think about I'm happy to apply suggested changes to this branch, once we fix the term. |
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.
While I'd agree that
--non-interactive
can be applied to more general use case than--on-compile
, I'm wondering how we can make it more straight forward name. (In general, it would be nicer to rephrasenon-XXX
toYYY
).Considering the nature that it adds a hook on compile, what do you think about
--hooked
or--triggered
?
I would say triggered
is the best proposal so far - I went through the PR and added suggestions in a few places to see how it looks. @mlachkar your opinion is welcome on this as I guess this can be useful for the Metals integration.
scalafix-interfaces/src/main/java/scalafix/interfaces/ScalafixMainMode.java
Outdated
Show resolved
Hide resolved
scalafix-interfaces/src/main/java/scalafix/interfaces/ScalafixArguments.java
Outdated
Show resolved
Hide resolved
scalafix-tests/unit/src/test/scala/scalafix/tests/cli/CliSyntacticSuite.scala
Outdated
Show resolved
Hide resolved
…MainMode.java Co-authored-by: Brice Jaglin <bjaglin@gmail.com>
…Arguments.java Co-authored-by: Brice Jaglin <bjaglin@gmail.com>
Co-authored-by: Brice Jaglin <bjaglin@gmail.com>
…cticSuite.scala Co-authored-by: Brice Jaglin <bjaglin@gmail.com>
I've reflected review comments with |
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.
👍 LGTM!
@mlachkar any objection/opinion?
What do you think about adding scalafixArgumentOnCompile: SettingKey[String] (or SettingKey[Seq[String]]) key to sbt-scalafix?
With scalafixArgumentOnCompile := "--check", users can switch their rules to lint only in their every scalafix run on-compile, which might be useful.
For that, we could have a scalafixCheckOnCompile
setting key (mutually exclusive with scalafixOnCompile
), which would request a CHECK_TRIGGERED
mode execution I guess? Having an arbitrary list of arguments means that we wouldn't fully control the mode, so it can be confusing to know which configuration (overlay) is used, no?
Thank you for reviewing again!
Since we can just use both of CHECK and IN_PLACE_TRIGGERED at once, I wouldn't think we need to introduce new CHECK_TRIGGERED mode. I also worry that exclusiveness between different sbt key seems to be tricky.
I see your point. Or, related to tool integration, is there any reason to clarify or restrict which arguments are passed on compile? |
@olafurpg any objection? |
This is a follow up PullRequest of scalacenter/sbt-scalafix#148 .
As discussed at the previous PullRequest, we find it would be better to support on-compile specific scalafix configuration in CLI, rather than sbt-scalafix.
So that I would add
--on-compile
flag and support onCompile section in .scalafix.conf .sbt-scalafix follow up
With this PullRequest, sbt-scalafix can pass
--on-compile
as a scalafix InputTask argument. So scalafix running on-compile will respectonCompile
configuration in.scalafix.conf
.And I have an extra idea:
What do you think about adding
scalafixArgumentOnCompile: SettingKey[String]
(orSettingKey[Seq[String]]
) key to sbt-scalafix?With
scalafixArgumentOnCompile := "--check"
, users can switch their rules to lint only in their every scalafix run on-compile, which might be useful.