Skip to content
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

Merged
merged 11 commits into from
Nov 1, 2020

Conversation

taisukeoe
Copy link
Contributor

@taisukeoe taisukeoe commented Jul 19, 2020

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 respect onCompile configuration in .scalafix.conf.

And I have an extra idea:

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.

support onCompile section in .scalafix.conf
// will be overridden by
// onCompile = {
// DisableSyntax.noThrows = true
// }
Copy link
Contributor Author

@taisukeoe taisukeoe Jul 22, 2020

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.

Copy link
Contributor Author

@taisukeoe taisukeoe Jul 24, 2020

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.Lsts), 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.

@bjaglin
Copy link
Collaborator

bjaglin commented Jul 23, 2020

Thanks for following up @taisukeoe - it's vacation time here, so expect some delays for the review

@taisukeoe
Copy link
Contributor Author

@bjaglin Thank you for your response.
No problem, please enjoy your vacation 👍

Copy link
Collaborator

@bjaglin bjaglin left a 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?

Comment on lines 85 to 86
"Run only rules defined in onCompile section in .scalafix.conf," +
"or rules explicitly passed via --rules"
Copy link
Collaborator

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?

Suggested change
"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 =
Copy link
Collaborator

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

Suggested change
def preProcessedConf(base: Conf): Conf =
def maybeOnCompileOverlaidConf(base: Conf): Conf =

Copy link
Contributor Author

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 👍

Comment on lines 253 to 256
val confOnCompile = ConfGet.getKey(base, "onCompile" :: Nil)
confOnCompile.fold(base)(
ConfOps.merge(ScalafixConfOps.drop(base, "onCompile"), _)
)
Copy link
Collaborator

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?

@taisukeoe
Copy link
Contributor Author

@bjaglin Thank you for your reviewing!
Indeed on-compile would be too specific, and it would be nicer to be relevant name for a build tool or an editor.

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 rephrase non-XXX to YYY).

Considering the nature that it adds a hook on compile, what do you think about --hooked or --triggered?

I'm happy to apply suggested changes to this branch, once we fix the term.
I'm planning to do this stuff, let's say this weekend. Is it OK for your release schedule?

Copy link
Collaborator

@bjaglin bjaglin left a 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 rephrase non-XXX to YYY).

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.

@taisukeoe
Copy link
Contributor Author

taisukeoe commented Oct 10, 2020

I've reflected review comments with triggered.
I'm still fine to change the term triggered if better proposal comes before merging.

Copy link
Collaborator

@bjaglin bjaglin left a 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?

@bjaglin bjaglin changed the title add --on-compile flag / support onCompile section in .scalafix.conf add --triggered flag to load overlay section in .scalafix.conf Oct 11, 2020
@taisukeoe
Copy link
Contributor Author

taisukeoe commented Oct 12, 2020

Thank you for reviewing again!

For that, we could have a scalafixCheckOnCompile setting key (mutually exclusive with scalafixOnCompile), which would request a CHECK_TRIGGERED mode execution I guess?

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.

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?

I see your point.
If we have another mode to overlay config than triggered in future, it will be confusing.

Or, related to tool integration, is there any reason to clarify or restrict which arguments are passed on compile?

@bjaglin
Copy link
Collaborator

bjaglin commented Oct 22, 2020

@olafurpg any objection?

@bjaglin bjaglin merged commit 37a29f4 into scalacenter:master Nov 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants