Feature Request: Mark rules as warnings

[Karn]

In cases where rules are slowly being adopted into a large codebase, it would be valuable to mark certain rules (in a fashion similar to disabled-rules) which produces a warning message as opposed to an outright failure.

[mateuszkwiecinski]

Thanks for reporting the issue and sharing the context 👍

A baseline feature would most probably be more useful in your case: #167, where you'd lock current offences and forbid adding new ones. Am I seeing it right?

From an implementation perspective, adding such feature would probably be fairly straightforward, at a cost of a complex configuration and maintenance, so I'm tad hesitant if it's worth the effort 👀

On a personal note, I can share my experience that warnings are usually ignored by developers (especially in larger teams), which makes me believe such a feature wouldn't effectively make it easier to adopt new rules. In my cases, the most effective way was to disable "challenging" rules, and enable them gradually, one by one, across the whole Gradle module or codebase. Most of ktlitnt rules support autocorrection mode, and running formatKotlin addresses most of the offences automatically.

[jeremymailen]

We do have a flag to control whether findings fail the build or not.
In the anti-bikeshedding spirit, I'm hesitant to introduce fine grain control of baselining and warn vs error -- unless of course ktlint supported in in their underlying feature set, which they don't. Agree with @mateuszkwiecinski that if I had to adopt on an existing project I'd either take the hit of a big conflict producing autofix PR or I'd put it non-build-failing mode for a few weeks while teams fixed the findings piecemeal.

[mateuszkwiecinski]

Huh, actually, you may be able to work around the issue by

1. configuring the plugin to ignore the certain rules using KotlinterExtension#disabledRules property
2. having a custom task that has all rules enabled, but set the tasks' ignoreFailures flag to true.

With such a setup, you'd have a task that fails with "known" offences, and you could have warnings for new rules, as you wanted initially. It's not ideal: if a "known" rule fails the other task would also fail, but it should fit your case, at least partially 👀

[jeremymailen]

In our next release we'll be fully delegating rule configuration to ktlint and the .editorconfig file, so any fine grain control of rules would need to be done there I believe.

[jeremymailen]

Going ahead and closing as I believe the most effective way to achieve this would be to disable the rule not yet adopted in .editorconfig and then re-enable them one by one as you wish to fix them.