Should I treat additional linter restrictions as breaking backwards compatibility?

Question

I'm maintaing a linter library, so this it's basically a set of rules checked against some code one can pass to it. Say, we have rule A which checks some set of cases.

Now imagine that some commit extends this set - by extend I mean that the cardinality of set is bigger but non of "old" members is gone, we've just added some new members.

Regarding the semantic versioning approach, how should I increase minor or major version? The question boils down to should I consider changes of this kind as backwards compatible?

Answer 1

Because it's normal to use linters as part of continuous integration checks, I would say it's correct to think of adding new enabled-by-default linter rules as a potentially breaking change.

Whether it actually is a breaking change depends on how you expect your linter to be used. Or in semver terms, what you defined as your "public API".

• If your linter is meant to be used with a config file that enumerates every single rule that should be enabled, then it's reasonable to say that the behavior without a config file has no backwards compatibility guarantees and you can do whatever you want even in patch and minor versions.

• If your linter is meant to be used with a config file that enables and disables rules, but does not enumerate the complete set of enabled rules, then any new rules you add in a patch or minor version should be disabled by default.

• If your linter has no config file at all and can only be configured via comments in the source code, then any new rules you add in a patch or minor version definitely have to be disabled by default.

For example, one of the linters my team uses at work in our CI setup is JSCS (which fits under the second bullet point), and based on their changelog, they're cool with adding new rules in minor versions, but those new rules are disabled by default (especially since some of them are specific to ES6). They also change their "presets" in minor versions, which are essentially alternative sets of defaults. Since you have to go out of your way to enable a preset, and they'd be a pretty useless feature if they could never ever change once added, it's reasonable to not provide any backwards compatibility guarantee for them.