[Request] use constants for linter error levels

My team has forked this project a couple times because linting rules are mostly 2/error instead of 1/warning, so it obscures genuine errors.

Something like this:

<Foo b={} a={} /> // props sorted wrong

Should not have the same severity as a critical bug! This adds a ton of mental overhead to every line when red dots are popping up everywhere: “will this code throw an error or is there some minor formatting issue?”

Needing to be so precious with every line slows down development when you may just be testing some additions or wading into third party code.

Doubly with autofix enabled, Atom currently fixes a ton of formatting inconsistencies on save, I can safely ignore some warnings now.

However, I understand your logic in #853 – when you need to enforce absolute consistency in your team, saying “you can’t proceed without fixing this niggle” is important. I would argue that should go in a commit hook or similar, but…

why not use a custom constant to define the error levels? This would allow the linting logic to be more flexible:

{ rule: airbnb.ERROR }

[ljharb]

The M&M clause is a very apt analogy, yes 😃

Things that might be obscuring errors, are themselves errors. I totally understand there are occasionally workflows where fast iteration matters more than correctness/style, but those aren’t the majority, and it’s better to inconvenience those people, and risk that they’re slower, then to risk that the majority has more brittle code.

One concern I’ve heard about the env var approach is ease of configurability in editors, which is where most people would probably prefer the flexibility. Those interested in this configurability can help by commenting with ways that demonstrate how to configure env vars for linting in popular editors/IDEs 😃

[braco]

@ljharb: thanks for the discussion.

The logic you’re using in that first link is a bit like the brown M&M test – if you suck at this part, you probably suck at other parts. That’s a good rule of thumb, but that could also be enforced by rejecting PR/pushes with any warnings, among other things. In the meantime, rephrasing “warning, this might be obscuring an error” as “this is an error” is an extreme style in itself and broadly impacts everyone that uses this popular and thoughtful ruleset. (My team doesn’t check up any code with linter warnings, for example, but the in-editor distinction is kept)

Formatting is of utmost importance, but there is a difference between “this should be fixed” and “this code will not compile”. It’s easy to come up with some silly examples, like errors from a trailing space inside a comment block sitting next to errors from a missing comma inside an object init. I guess there’s probably an argument in here for a protected eslint level or editor differentiation for compile errors…

Regarding saving to preemptively autofix formatting: it doesn’t fix everything yet, and if you’ve got some form of hot reload/autobuild going, you may be loading a critically broken script. That’s why I would scan for red-dot errors first.

I think much of this comes down to workflow preferences, and the constant would go a long way into making the package more flexible. Thanks for considering, and for all your output here in general.