Configurability of ktlint

[paul-dingemans]

Since I became maintainer of ktlint, I have tried to limit the configurability of ktlint to reduce complexity as much as possible. In parts of the community there is a strong desire to have more configuration options.

Let discuss about configurabilty here! What would be the correct level of configurability? How can we keep it maintainable in the long run? How should the configuration be stored in a project? How do we decide on the choice of the default value of new configuration settings?

[meyertime]

I'm curious what others think about this. It seems like the configuration options ktlint does support so far fall roughly into two buckets:

1. General code style options, like indent_style and max_line_length
   • A handful of these are part of the .editorconfig specification. I like the idea of continuing to support these options since IDEs and other editors will also pick them up.
2. Rule-specific options, like ktlint_function_naming_ignore_when_annotated_with
   • Some of these call out the name of the rule in the setting name, as in the above example.
     • Tying a setting to a rule may make maintenance a little easier. But I don't think it makes things better for the user unless they can have multiple instances of the same rule. (For example, enforce different function naming conventions for different situations such as composable functions.)
   • Some of these piggy-back off of IntelliJ's settings, like ij_kotlin_allow_trailing_comma. The pattern IntelliJ seems to follow with these focuses on the code style option rather than the rule that it applies to.
     • I'm not sure how I feel about these. On the one hand, some of the work of figuring out what the options should be will have already been done for us, and IntelliJ will respect all the same formatting. But then do we try to support all of IntelliJ's options eventually? And what if IntelliJ doesn't have an option that we want? Or do we just take a cue from IntelliJ and come up with our own set of code style options that aren't tied 1-to-1 with rules?

Configurable formatting linters that I've used in the past took a different approach entirely: You could specify instances of rules and give each rule different options. Rules also had some common options, such as including or excluding certain names or annotations. If we went that route, then I think a simple INI format as in .editorconfig would not be sufficient. Probably .kts with a domain-specific language, similar to the way Gradle is configured, would be ideal. That would probably require a major overhaul of ktlint, however.

Those are just some ideas that come to my mind; I'd appreciate some input.

[eygraber]

I think that the general code style options do well in .editorconfig (especially when there's ide support for them), but it's impractical for real configurability.

I'm partial to how detekt handles configuration (and sounds a lot like what you are describing). They use yaml to configure rules, which is probably easier to build support for, yet more limited than a kts file.

[paul-dingemans]

Rule-specific options, like ktlint_function_naming_ignore_when_annotated_with

• Some of these call out the name of the rule in the setting name, as in the above example.
• Some of these piggy-back off of IntelliJ's settings, like ij_kotlin_allow_trailing_comma.

There is a third group of rule specific option, which do not have the rule name include. Best example is ktlint_code_style which by nature can not be couple to a single rule. But we also have older options like ktlint_ignore_back_ticked_identifier which is specific for a rule, but not include the rule name. The reason that I started to include the rule name in the options is to make it more explicit for the user to understand which rule the option has effect on. It is slightly helpful to me as maintainer to quickly answer questions, when I do not have immediate access to my IDEA. But when I have access to my IDEA the rule name inside the option is not beneficial.

Piggy back on intellij options is convenient to avoid inconsistent behavior between IDEA formatting and ktlint formatting. However, in the example of ij_kotlin_allow_trailing_comma the meaning of this option in ktlint is more strict than in IDEA.

If we went that route, then I think a simple INI format as in .editorconfig would not be sufficient. Probably .kts with a domain-specific language, similar to the way Gradle is configured, would be ideal. That would probably require a major overhaul of ktlint, however.

I do understand that the .editorconfig format might be limiting when adding full configurability. I am really worried though about the impact of replacing the .editorconfig as configuration tool. Ktlint picks up the .editorconfig automatically when it exists, this could work well for any other configuration format. But I do see problems with following:

• API consumers can override .editconfig settings programmatically when defining the KtLintRuleEngine. Some API consumers seem to use this quite intensively to connect their own internal configuration options to configure ktlint.
• The .editorconfig can be defined at any place inside the project hierarchy to change ktlint settings for example for test or generated code.

[kenyee]

Piggy back on intellij options is convenient to avoid inconsistent behavior between IDEA formatting and ktlint formatting.

I'd say that's a pretty important pro for keeping this in .editorConfig instead of moving over to a YAML file.
Ideally IDEA formatting and ktlint formatting are the same for consistency...

[paul-dingemans]

Ideally IDEA formatting and ktlint formatting are the same for consistency...

I don't think the goal should be to keep the format the same (as in being identical). It is great when ktlint formatting does not conflict with Intellij IDEA formatting, but there are cases in which the actually is wanted to solve bugs in IDEA formatting.

But we should not introduce configuration options if Intellij IDEA already exposes ij properties which are closely related.

[kenyee]

I'd lean towards less complexity.
Ktlint used to be the anti bikeshedding formatting option for Kotlin. A common complaint is formatting keeps changing with each version and the complexity is probably party of it.
It got bad enough that some companies like Google and Slack have switched over to ktfmt.

Configurability leads to bikeshedding.
Sadly, exceptions like Compose function naming require configurability so there has to be some...

[eygraber]

Ironically the lack of configurability has led to bikeshedding as well.

[PoisonedYouth]

I use ktlint in both all my private and production projects. The main reason for this:

• no discussions about code format
• including format check in the CI pipeline.

I prefer to use the standard configuration and don't like to configure too much because this will lead to discussions in the team about it.

What I don't like is to reformat the whole project when updating to a new ktlint version.

detekt is a good example for having good defaults and a stability of rules, so the maintenance effort is very small.

[jeremymailen]

Yes, I agree strongly. Ktlint has been around for quite some time. At this point it should be trending towards stability.

While I certainly appreciate the intensive efforts to improve all the technicals of the code base and project, from a practical standpoint:

• as an open source maintainer, it's meant a lot of labor for me and others to keep kotlinter-gradle working with each ktlint release
• and as a user of ktlint, I've had to disrupt our team with big formatting formatting changes for many ktlint releases

I would suggest a pragmatic approach to configuration that allows for a "cleaner" and more straightforward use of the tool. After all, most people are using a formatter to simplify their lives and get time back for their team. Things that would help:

• Ensure formatting rules are independent so that disabling one doesn't require disabling another
• Formatting defaults for each standard should track with IDE defaults and not apply any radical looking formatting just for the sake of pure consistency

[paul-dingemans]

as an open source maintainer, it's meant a lot of labor for me and others to keep kotlinter-gradle working with each ktlint release

Since 1.0 release the API of ktlint is stable. To arrive at that point the API consumers had to endure breaking change after breaking change. Having said that, I am worried about introducing another way of storing configuration options for ktlint. It will definitely be a breaking change.

Ensure formatting rules are independent so that disabling one doesn't require disabling another

This topic has been addressed in past as well. There are good reasons to make rules depending on each others. There have also been occasions in which this was done for wrong reasons, and have been corrected in later releases. It will be impossible to remove all dependencies between rules without having a massive impact on the code.

Formatting defaults for each standard should track with IDE defaults and not apply any radical looking formatting just for the sake of pure consistency

How does this relate to the topic of configurability?

[jeremymailen]

How does this relate to the topic of configurability?

I guess what I'm driving at is that configuration is nice to have, but most users shouldn't need it if problematic defaults can be avoided. I would advocate for a light touch on this effort. Beyond IDE <-> linter harmony the other reason I vote for sticking with .editorconfig is that I believe both ktlint-gradle and kotlinter-gradle have standardized on using this mechanism to configure ktlint. I recognize that it's a more limited format, but I think the analysis that you and @meyertime did in this thread indicates, if designed thoughtfully, it's possible to express the necessary configuration through .editorconfig.

[meyertime]

This is all really good feedback. Sorry I've been so quiet. I was on vacation, and then I've been scrambling to catch up at my day job.

I figured there would be push-back on the idea of expanding beyond .editorconfig. I think we can still achieve decent configurability without doing so.

It also sounds like it's important that updates to ktlint do not trigger large formatting changes. I think we can achieve that pretty easily by making new rules disabled by default and new configuration options default to the current behavior. At least until we bump the major version, at which point we might bring the defaults more in line with the IntelliJ formatter (and/or official style guides), and provide instructions for preserving the existing behavior in the release notes.

I'm curious about the dependencies between rules. I understand why certain configuration options may affect multiple rules, but I'm wondering how and why rules depend on each other. @paul-dingemans, could you link me to where that was discussed in the past?

It did give me an idea, however. First of all, I think making rules independent would help keep things maintainable. But taking that a step further, what if we split the rules out more granularly? For example, there's one annotation wrapping rule that handles annotations in all contexts. Instead, this could be split into function annotation wrapping, class annotation wrapping, property annotation wrapping, etc. This would make the existing rule disabling capability more powerful. The wrapping could also be configured differently depending on the context. Each rule would also be more focused and easier to test. Of course, we would want backwards-compatibility, so all the annotation wrapping rules could be part of a rule group, so that existing configurations that disable the annotation wrapping rule would disable all the rules in that group.

[paul-dingemans]

It also sounds like it's important that updates to ktlint do not trigger large formatting changes.

For some users this is indeed a concern. Other users take it way more light hearted, and just accept the changes (sometimes after disabling some rule that goes too far). It always make me wonder, what the reason for upgrading is, when you do not want to risk big code changes in your code base. If you stick to a well known version of ktlint, you will never be surprised.

Now that ktlint API has been stabelized, the API Consumers of ktlint seem to support more versions of ktlint.

It also sounds like it's important that updates to ktlint do not trigger large formatting changes. I think we can achieve that pretty easily by making new rules disabled by default and new configuration options default to the current behavior. At least until we bump the major version, at which point we might bring the defaults more in line with the IntelliJ formatter (and/or official style guides), and provide instructions for preserving the existing behavior in the release notes.

New rules are already introduced as experimental rules. Such rules are only run after explicit opt-in of the user. Either by opt-in on all all experimental rule ktlint_experimental = enabled or by opt-in on specific rules ktlint_standard_<rule-id> = enabled only. Major ktlint releases should happen very infrequently and only when there is no other way to keep backward compatibility. Holding off new rules from being enabled by default until such a release occurs is not a good idea. Also, it could lead to a situation that a new major version of ktlint needs to be released solely for the reason to get a new rule enabled by default. For example in case the styleguide are changed, or a new rule is introduced which is compatible with the guideline.

... and provide instructions for preserving the existing behavior in the release notes.

This is a good idea whenever possible. But problem arise when a new violation is added to an existing rules because it is logically related to that rule but which is 'breaking' backward compatible for some users, but 'essential' to others.

I'm curious about the dependencies between rules. I understand why certain configuration options may affect multiple rules, but I'm wondering how and why rules depend on each other. @paul-dingemans, could you link me to where that was discussed in the past?

There has been little debate about this in the community. Though, one of the active maintainers in the past has stressed that if possible it should be avoided if possible.

Most dependencies between rules are ordering dependencies. Executing the rules in a specific order has two main reasons. The first reason is reproduceability.

Given any piece of code which is procesed, the reported violations and autocorrections should always be identically. In the past it could happen that between any to versions of ktlint there could be a difference because the order in which rules were executed could change per compilation (e.g. determined by the order of loading the rule classes) of ktlint.

The second reason is reducing the number of passthroughs before no more code violations are found. Since a couple of releases, ktlint reformats a piece of code up to 3 times in case an autocorrection has been applied. But even then it can happen that another lint violation is still found. Optimizing the rule order can drastically reduce the number or reformats that are needed before the code is stable.

A rule dependency can occur in two forms. When marked as REGARDLESS_WHETHER_RUN_AFTER_RULE_IS_LOADED_OR_DISABLED the dependency has no effect on configurability. Ktlint will only print a warning in case the depending rule is not loaded, or is disabled.

It did give me an idea, however. First of all, I think making rules independent would help keep things maintainable.

When marked as ONLY_WHEN_RUN_AFTER_RULE_IS_LOADED_AND_ENABLED there is a technical reason that both rules need to be loaded and enabled. Currently there are only 3 such rules:

• string-template-indent
• trailing-comma-on-call-site
• trailing-comma-on-declaration-site
  See source code for reasons. I am curious how you would make them independent without replicating all code from one rule to another.

But taking that a step further, what if we split the rules out more granularly? For example, there's one annotation wrapping rule that handles annotations in all contexts. Instead, this could be split into function annotation wrapping, class annotation wrapping, property annotation wrapping, etc. This would make the existing rule disabling capability more powerful. The wrapping could also be configured differently depending on the context. Each rule would also be more focused and easier to test. Of course, we would want backwards-compatibility, so all the annotation wrapping rules could be part of a rule group, so that existing configurations that disable the annotation wrapping rule would disable all the rules in that group.

Ktlint contains 97 rules (including experimental). 42 rules emit exactly 1 violation. The other 55 rules emit 215 different violations. The class-signature and function-signature emit the most violations for a single rule.

So at the most fine grained configuration level you would need 257 configuration options to offer the user the "freedom" to configure ktlint exactly to their liking.

Although ktlint is still pretty fast on bigger code bases, the number of rules has a direct impact on the performance. The rules are implemented with the Visitor pattern. Every rule will be called for every node in the AST of every file that is being scanned. More over, I expect that a lot of code either has to be duplicated or be extracted for reuse.

Also increasing the number of rules, or configuration options will have a huge impact on the documentation part. The impact of maintaining that documentation should not be underestimated.

@meyertime I do like the new energy you bring to the table and that you question many things. I had like to encourage you to start small and make smaller step changes instead of a major overhaul.

[meyertime]

Thanks for the breakdown of the rule dependencies! That is super helpful.

I do like the new energy you bring to the table and that you question many things. I had like to encourage you to start small and make smaller step changes instead of a major overhaul.

Agreed. I am not planning to do a major overhaul. I just want to make sure the smaller steps I take move the project in the right direction.

It always make me wonder, what the reason for upgrading is, when you do not want to risk big code changes in your code base. If you stick to a well known version of ktlint, you will never be surprised.

We upgrade all of our dependencies periodically, first of all for security reasons. Vulnerabilities are routinely identified where we are required to upgrade, so if we wait too long to upgrade, then we risk it being a much bigger job to upgrade when we are required to. This is typical of large enterprises these days. Granted, ktlint does not run as part of our application, only as part of its build process. But it is still external code that is downloaded and run on a Target computer inside the Target network, so security is a concern. There are other reasons too. For example, we keep up-to-date with the Kotlin language as well, which may require an upgrade of ktlint.

Major ktlint releases should happen very infrequently and only when there is no other way to keep backward compatibility. Holding off new rules from being enabled by default until such a release occurs is not a good idea.

Semantic versioning has become the de facto standard, and according to it, backwards incompatible changes require a major version bump. To me, if the code passes lint, you upgrade ktlint, and the code no longer passes lint, then it's not backwards compatible. Or, at the very least, there should be a way to configure ktlint so that it behaves the way it did in the previous version.

There needs to be some kind of contract. I think a big reason why some users are upset is because there have been releases since 1.0.0 which have included breaking changes that require either big reformatting, or disabling another chunk of ktlint. This violates the unspoken contract of semantic versioning. When we see a patch or minor version bump, we expect to be able to upgrade without changing anything. When instead we find a breaking change, it's irritating. On top of that, we have to sift through potentially many release notes to find what we need to fix it, since there could have been many patch and/or minor releases since we last upgraded. On the other hand, when we see a major version bump, we expect breaking changes and know to look at the major version release notes or migration guide to see what to do. It also doesn't happen as often.

The way I see it, there are 3 options:

1. Continue including breaking changes outside of major releases and continue irritating users.
2. Stay true to semantic versioning and limit breaking changes to major releases, try to avoid breaking changes as much as possible, rarely/never bump the major release version, and be stuck having to support all previous behaviors through configuration options.
3. Stay true to semantic versioning and limit breaking changes to major releases, and adopt a shorter major release cycle (every 6 months, 1 year, or 2 years, for example). Keep full backwards compatibility through configuration options until the next major release.

I really don't like the first two options. As you've brought out, we don't want to grow the configuration options too much. Option 3 is a compromise that allows innovation while keeping the semantic versioning contract. Actually, every 6 months wouldn't even be that rapid. Google Chrome releases a new major version every 6 weeks. Android Studio is about quarterly, though lately it's been every 2 months.

New rules are already introduced as experimental rules. Such rules are only run after explicit opt-in of the user.

Experimental rules would of course be the exception to all of this. Once you enable an experimental feature, you know you're opening yourself up to breaking changes at any time.

Promoting an experimental rule to a standard rule that is enabled by default would be a breaking change that should really require a major version bump. However, at least in that case, it's easy to explicitly disable it, so it's not as much of an issue.

But problem arise when a new violation is added to an existing rules because it is logically related to that rule but which is 'breaking' backward compatible for some users, but 'essential' to others.

This is really the problem, because the only workaround is to disable the rule completely, when you were using that rule previously, so you're losing functionality. Changing the behavior of a (non-experimental) rule with no option to keep the original behavior is absolutely a breaking change. The only option is 1) break semantic versioning and anger people, 2) introduce a configuration option, or 3) bump the major version.

In the past, ktlint was version 0.x.x for some time. Even according to semantic versioning, when the major version is 0, any changes can happen in any release, even breaking changes. We expect that. So while promoting experimental rules in minor releases may not have caused much fuss back then, there is a different expectation now that it's 1.x.x. In fact, some projects have considered, for example, 0.1 -> 0.2 to be a major release, whereas 1.1 -> 1.2 is definitely a minor release.

[paul-dingemans]

We upgrade all of our dependencies periodically, first of all for security reasons. Vulnerabilities are routinely identified where we are required to upgrade, so if we wait too long to upgrade, then we risk it being a much bigger job to upgrade when we are required to. This is typical of large enterprises these days. Granted, ktlint does not run as part of our application, only as part of its build process. But it is still external code that is downloaded and run on a Target computer inside the Target network, so security is a concern. There are other reasons too. For example, we keep up-to-date with the Kotlin language as well, which may require an upgrade of ktlint.

Yes of course. I was a bit sarcastic (should have added /s) when making this remark about why upgrading if you don't want code changes. But I do see a lot question in the issue tracker of people still using prehistoric versions of ktlint and then suddenly upgrade from for example 0.45.0 to current version, and still are surprised that backward compatibilty broke.

I do understand that promoting an experimental rule can be result in experiencing a breaking change in case you are not using the experimental rules already. Problem is that too few users are using the experimental rules, so there is a lack of feedback as long as the rule is in the experimental stage. After promoting the rule to non-experimental, more feedback is received. Delaying promoting of experimental rules to the next major release only partly resolves the problem of backward compatibility.

For example, we keep up-to-date with the Kotlin language as well, which may require an upgrade of ktlint.

This is very hypothetical. Of last three years I can only remember a couple of language features for which ktlint was changed. If I recall correctly this were the context receiver, and the range until operator.

The big topic that you address is the versioning of ktlint. Here we have a totally different problem. Ktlint is not a single artifact but up to 16 artificacts (https://pinterest.github.io/ktlint/latest/api/overview/). Currently all artifacts have the same version number which from a maintainability perspective is most easiest to handle. When I apply the semantic versioning I take the API Consumers of the KtlintRuleEngine as the most important customers. Your reasoning seem to focus on the users of ktlint-cli or more precisely the ktlint-ruleset-standard. We can explore whether it makes sense to use a separate version number for those artifacts. Or, maybe more widly, to move those artifacts to a (or two?) separate projects. ktlint-cli is nothing more than another API consumer that is using the ktlint-rule-engine, ktlint-rule-engine-core and the ktlint-standard-ruleset artifcacts.

This violates the unspoken contract of semantic versioning. When we see a patch or minor version bump, we expect to be able to upgrade without changing anything.

How would you expect that ktlint can guarantee that no breaking change occurs in minor/patch releases? Currently the project contains almost 2700 unit tests. Next to this I test every released on a bunch of open source projects containing more than 300K lines of code. Yes, I am aware that have introduced breaking changes for which I have changed unit tests, and saw big refactorings in the reference projects. But there is no way, that we can guarantee that no breaking change is introduced in a minor/patch version because code can be written in an infinite number of ways. After every release, you will see that new bugs pop up for scenarios that were not yet covered by tests. And if it happens, how would you mitigate? Revert the change? Or add yet another configuration option? I really don't see how this can work out in a maintainable way. Neither I am convinced that it would solve problems of a majority of ktlint users.

[meyertime]

Currently all artifacts have the same version number which from a maintainability perspective is most easiest to handle. When I apply the semantic versioning I take the API Consumers of the KtlintRuleEngine as the most important customers. Your reasoning seem to focus on the users of ktlint-cli or more precisely the ktlint-ruleset-standard.

I see where you're coming from. I would argue, though, that the main purpose of ktlint is to format code for us end-users, the majority of which are probably using the standard ruleset. API consumers are important too, but only because it helps end-users use ktlint for its primary purpose of formatting code.

We can explore whether it makes sense to use a separate version number for those artifacts. Or, maybe more widly, to move those artifacts to a (or two?) separate projects. ktlint-cli is nothing more than another API consumer that is using the ktlint-rule-engine, ktlint-rule-engine-core and the ktlint-standard-ruleset artifcacts.

I was actually going to suggest this, but you beat me to it. It seems like the API should be stable by now, and breaking changes should be rare, whereas the standard ruleset wants to change more rapidly. But I haven't even had time yet to make my first contribution to ktlint, so I'm not going to push for that yet.

How would you expect that ktlint can guarantee that no breaking change occurs in minor/patch releases? [...] But there is no way, that we can guarantee that no breaking change is introduced in a minor/patch version because code can be written in an infinite number of ways. [...] And if it happens, how would you mitigate? Revert the change? Or add yet another configuration option?

This is part of why I want to nail down a contract so that users can have clear expectations. Normally, if a breaking change happens outside a major release, yes, you would revert the change, or fix it so that it is no longer breaking. The fix would be in a patch release, and a "known issue" would be noted on the affected version. With such a contract, users can expect that if they see a breaking change in a minor/patch release, they can open an issue and get it fixed. Whereas, if breaking changes can happen in any release, why bother even opening an issue? Or if they do, they may get really irritated when the maintainer refuses to fix it.

You have a point, though, about code being written in an infinite number of ways. I don't think there's any way to introduce a new rule that is enabled by default without it breaking some/most/all codebases, which is why that would have to be reserved for major releases. But as far as existing rules, making them more strict by default would likely be breaking, whereas introducing a stricter configuration option or loosening the default would not be breaking, if implemented correctly.

[kenyee]

It always make me wonder, what the reason for upgrading is, when you do not want to risk big code changes in your code base. If you stick to a well known version of ktlint, you will never be surprised.

Besides the kotlin version compatibility issue, there's also the IDE plugin compatibility. I.e. if the IDE flags different issues than running ktlint in CI via a gradle plugin, then it's super confusing for developers to clean everything in their IDE, then get flagged in CI for ktlint errors.
It's hard to lock the ktlint plugin to a specific version (I've done it in the past at another company, but you have to build out a bunch of infra to install it yourself basically), and it autoupdates generally (or devs will update it themselves).

[paul-dingemans]

It always make me wonder, what the reason for upgrading is, when you do not want to risk big code changes in your code base. If you stick to a well known version of ktlint, you will never be surprised.

Besides the kotlin version compatibility issue, there's also the IDE plugin compatibility. I.e. if the IDE flags different issues than running ktlint in CI via a gradle plugin, then it's super confusing for developers to clean everything in their IDE, then get flagged in CI for ktlint errors. It's hard to lock the ktlint plugin to a specific version (I've done it in the past at another company, but you have to build out a bunch of infra to install it yourself basically), and it autoupdates generally (or devs will update it themselves).

This was indeed a problem in the past (up until version 0.22.0 of the ktlint-intellij-plugin). User were forced to update the plugin whenever a new version of Intellij IDEA was released. When updating the plugin, the user was also automatically updating to a more recent version of the plugin. But honestly, most of the times, the pluging was lagging behind with most recent plugin version. Since version 0.23.0 of the plugin it has become possible to select the ktlint ruleset version (0.50.0 and above).

[kenyee]

Since version 0.23.0 of the plugin it has become possible to select the ktlint ruleset version (0.50.0 and above).

Hmm... I was looking at https://github.com/nbadal/ktlint-intellij-plugin and it looks like it's a compile time selection?
I was hoping it'd be a .editorConfig parameter so it's a dynamic configuration.

[paul-dingemans]

I am not sure what you mean with 'compile time selection'? The version is stored in file .idea/ktlint-plugin.xml. It can not be stored inside .editorconfig as this would be confusing from the perspective of the other API Consumers. For example the ktlint-gradle plugin uses the libs.versions.toml.

[kenyee]

version is stored in file .idea/ktlint-plugin.xml

ahh...I didn't see that info on the home page for the plugin.

I misread this bit:
"To support a new version (X.Y.Z) of ktlint, the following needs to be done:"
as the configuration 😂 🤦

[paul-dingemans]

Ah, this is the from the technical readme, that describes how new ruleset versions need to be added to the plugin. Basically the plugin contains multiple versions of the ktlint-standard-ruleset so that the user can actually choose between them.

[kenyee]

Makes sense. I usually put that kind of stuff into a Development.md in a repo (it's for ktlint devs instead of users).

[mgroth0]

In response to this and the threads proceeding this.

First of all, @paul-dingemans thank you for everything you've done for ktlint. This tool has provided me with the ability to format all my code in a way that meets most of my needs. You've done a huge service for the community. I also appreciate how reliable you are with fixes and implementing most suggestions, and also how you explain your reasoning behind when you reject an issue or PR.

I find the feedback here valid but do feel it got too harsh at times. We all owe volunteer maintainers gratitude and respect for their efforts. Clearly @paul-dingemans decision's weren't made lightly.

I know none of that is very constructive. I couldn't read everything that was said but I did see a lot of negative emotions flaring up and just thought we should all remember to be grateful for eachother.

That being said, I do agree it was probably a mistake to ignore all those upvotes on that issue that sparked all this. I have no stake in that issue and didn't read everything in depth so I don't mean to re-ignite anything, just saying I can see both sides.

But anyway, speaking of configurability and speaking of rejecting a PR 😂, I know that this is also risking being off topic but I have to bring up #2537. You could say its more about integratability than configurability, but I think there is some overlap in spirit. Configuration on the level of integrations instead of rule logic, you could say. I do think I understand your reasoning for closing it, but given this conversation came up I thought I'd check in. Do you still feel there is no way forward there in terms of removing all filesystem IO without compromising filepath-based rule logic? If that sort of change matches the spirit of this goal of increased configurability such that we are willing to readdress that issue, I'd be open to working on a new PR towards it (when I find the time). I would take advice first on what I should do to improve the likelihood such a PR would be approved. Original issue: #2532

[paul-dingemans]

Tnx for your appraisal. As maintainer I really value to get positive feedback every now and then.

Regarding your request #2532 / #2537 it might be best to contact maintainers of other API consumers of ktlint. As I wrote down in #2532:

I am closing the issue for now. I am willing to reopen it when it would be beneficial and requested by at least one or two other integrators like the ktlint gradle-plugin, or detekt.

[mgroth0]

I am assuming that maintainers of other API consumers of ktlint don't need this. otherwise, I wouldn't be the only one asking for it. If the only way forward would be for me to recruit others (who don't seem to need it), I'll probably drop it for now. It's not a blocking issue for me, I can still use ktlint.

[mgroth0]

And here is my much more on topic comment. I really like IntelliJ's KotlinCodeStyleSettings.ALIGN_IN_COLUMNS_CASE_BRANCH:

    when {
        transform != null        -> append(transform(element))
        element is CharSequence? -> append(element)
        element is Char          -> append(element)
        else                     -> append(element.toString())
    }

I brought this up in #2544 and #2542. Both were rejected because horizontal alignment is against official kotlin style guides. While I understand that, I don't care. In my opinion the aligned branches in the when statement above is beautiful and readable and I need it.

So on the topic of configurability, I would like to configure ktlint to allow this. As a start, I need the no-multi-spaces rule to allow for multiple spaces or tabs or whatever so my when statements get aligned. I could imagine this as a simple if statement that makes no-multi-spaces not run if it is in the whitespace between a when condition and its arrow. Then I suppose I need a new rule that actually sets the appropriate amount of whitespace for each branch.

I will probably eventually get around to this for myself anyway by copying and pasting the no-multi-spaces rule into my own custom rule. But if I could contribute that as a configuration option for no-multi-spaces too for others to use, I'd be happy to.

[paul-dingemans]

Configurarability of ktlint should not mean that everyone's personal flavor of formatting will be supported out of the box. Primarily it should give some control on topics on which the style guide is not stricly defined. In case of need, you can always duplicate ktlint rules an adapt them to your custom needs.

[eygraber]

Configurarability of ktlint should not mean that everyone's personal flavor of formatting will be supported out of the box.

Why not?

[meyertime]

Why not?

I actually agree with Paul on this one. We have to draw the line somewhere, or things will get out of hand. Supporting what the official style guide says, or different ways that it could reasonably be interpreted, makes sense to me.

As far as this style of aligning when branches, it seems like a good candidate for a custom rule.