Ktlint: Use cli param value as a source of globally disabled rules

[idntfy]

Context

• #503 - adds support for globally disabled rules through editorconfig

# Comma-separated list of rules to disable (Since 0.34.0)
# Note that rules in any ruleset other than the standard ruleset will need to be prefixed
# by the ruleset identifier.
disabled_rules=no-wildcard-imports,experimental:annotation,my-custom-ruleset:my-custom-rule

• #48 - summarising, is a very long discussion about abusing the authority by enabling no-wildcard-import by default in the tool we all love.

This issue is an attempt to find a pragmatic consensus.

Although it would seem that #503 could resolve the situation around #48 but it still hurts the wide adoption of the tool.

On a scale it's really hard to adopt now when it's enabled. We have both big number of projects and even more bigger number of developers. Committing .editorconfig to all the projects or asking everyone to call --apply-to-idea-project are just no way to go, because it cannot be centralized thus hardly manageable.

The Proposal 1 (UPD: this was chosen to implement now)

Introduce a cli param value of which would be used as a source to the functionality already introduced in #503 - so basically it's nothing new.

In this form it can be configured widely even across many projects, e.g. if parent-pom or some common maven/gradle plugin is used, without committing .editorconfig to all the projects and without asking an every single developer to change default idea settings by calling --apply-to-idea-project.

The Proposal 2 (UPD: #548 was created to discuss further)

Create several sets of code styles:

• default, Jetbrains-based on official kotlin coding conventions and intelliJ idea default settings - this one is not supported now.
• android-specific, which would match google's recommendation for android development - it seems ktlint tends to support this standard.

Make it switchable through cli param. Thus all the parties - android developers and the rest - would use what they need.

---

Bottomline: while 2 could be too extreme, 1 is just a simple addition to the functionality that already exists.

[shashachu]

An --android CLI param actually already exists, but it's not being used in this capacity. I don't think your proposal to move the no wildcards rule into and android ruleset is a bad, as it does exist only in the Android Kotlin styleguide. I admit that as an Android developer I'm biased towards that direction, but I don't have a good pulse on how non-Android Kotlin developers work. The reason I'm hesitant is that it opens the door to a lot of arguing about whether a rule should be android-only, and as far as I know, the no wildcard imports rule would be the only rule in the android ruleset. Let me give this some thought.

[JakeWharton]

The Google Kotlin style guide (which encompasses all Kotlin code written at Google, not just Android code) also has this rule and they are ktlint consumers.

It's currently a copy of the Google Android Kotlin style guide with some tweaks (such as 2 spaces instead of 4, praise be). I hope one day to invert that dependency and have a publicly-published Google Kotlin style guide with the Google Android Kotlin style guide being only tweaks to it (4 space instead of 2, booooooooo).

[idntfy]

The reason I'm hesitant is that it opens the door to a lot of arguing about whether a rule should be android-only

Call the potatoes default and strict. The ones who disagree would be glad to use something that's called strict, the ones who prefer default ruleset would be glad to use the default one.

If not, the first proposal seems to be pretty simple to implement which would be satisfactory as well.

[idntfy]

After a bit of thinking - I think we need to proceed with the first proposal: just adding a cli param to do the same as #503 does.

I'll describe the thought process: since the notion of default changes with the ruleset proposal, the current consumers will need to switch to the behaviour they got used to. I imagine you need to maintain your current audience happy, only new consumers are not happy with this no-wildcards enabled. Hence, the strict one becomes default, and the other ruleset just weakens rules. However, for this it would be more flexible to provide the above-mentioned cli param.

[shashachu]

After a bit of thinking - I think we need to proceed with the first proposal: just adding a cli param to do the same as #503 does.

I'll describe the thought process: since the notion of default changes with the ruleset proposal, the current consumers will need to switch to the behaviour they got used to. I imagine you need to maintain your current audience happy, only new consumers are not happy with this no-wildcards enabled. Hence, the strict one becomes default, and the other ruleset just weakens rules. However, for this it would be more flexible to provide the above-mentioned cli param.

Makes sense. Moving rules into --android is, like you said, somewhat of a backwards-incompatible change, and perhaps something worthy of a larger discussion.

I'll put up a PR for adding --disabled_rules as a CLI flag and push it with the already-planned 0.34.1 release, due the end of this week.

[idntfy]

Thank you for a quick turnaround @shashachu 🎉

[shashachu]

I'll wait a couple days to make sure there aren't any other issues we need to patch for 0.34.0 then put up a new release.

[shashachu]

@idntfy I just released 0.34.1 with the new flag.