ESLint offers three settings for any given rule: error, warn, and off. The error setting will make ESLint fail if it encounters any violations of t...
For further actions, you may consider blocking this person and/or reporting abuse
I like to use warnings in my projects for rules that are fine to break during development (e.g.
no-console,no-unused-vars), but not in build. I use--max-warnings 0option in build script. It looks something like this:I find this really handy. The warnings do not block me during development and debugging. But they show me where the code is incomplete and where my debug logs are. It's easy to find these places and clean them up. Then, with zero warnings tolerance, the debug code will never get into production.
Also, I use a pre-commit git hook to lint with zero warnings. This way these things never even leave my local computer.
eslint shouldn't stop your dev hot module reload loop anyway?
I don't agree.
A
warnis simply an acknowledgement of a code style that may be dubious but should be allowed if the circumstance merits it.There is a benefit to having a distinction between
do notandought not.imho,
eslint-disable-next-lineis the noisy anti-pattern here.This is confusing, because
eslint-disable-next-line+ a comment explaining why is exactly what you do when something "should be allowed if the circumstance merits it"IMO, if you let warnings slide, you just end up with a lot of warnings. If no one pays attention to the warnings, they're just noise with no signal. So either fix them, or remove them.
Like others mentioned, try using
--max-warnings 0in CI builds. You can still do whatever the heck you want locally, but no warnings / errors make it into your build. It's so refreshing working on projects where there's no warnings or errors.Only thing where I could think of warn as usable is migrating a large codebase from one code style to another while having many contributions going on.
And it is a very important case, as this or similar kind of things happens quite a lot in the enterprise world. Business priorities cannot be easily neglected.
Love it! Someone else commented on this post suggesting to look into a tool called Betterer, and I think this is exactly what you're looking for. I had never heard of it before, but I poked around their docs this morning, and it looks like you can set rules that certain conditions should get bigger (more tests, higher coverage, etc.) or smaller (fewer ESLint rule violations, fewer TODO comments, etc.), and you can set dates for when goals must be met. Seems promising!
phenomnomnominal.github.io/bettere...
You might want to check out betterer which allows you to set rules on things like warnings as well and then trigger CI to fail if the number of warnings crosses some threshold.
The problem with having very strict linting is that it might slow down the team at a time where it might not be appropriate. In practice a policy of "no warnings" means that people see improvement work as being inherantly high-effort / low-reward and the refactoring piles up.
Thanks for sharing! I had never heard of Betterer before, but I spent some time this morning looking through their docs. It looks neat!
True, a rule should either pass or fail.
In all my projects I always configure ESLint to error only, no warnings. In my mind it's either a problem or it isn't. It's either an error that needs to be fixed or it's not an error.
This phrases should be emphasized 😅
Just like you said, I think that 'warn' setting is useful for introducing new rules in some old/big codebase. In most cases it's good to clean up the warnings and change the rule to 'error' ASAP. 🙂
That's actually quite an awesome idea.
I would say developers ignoring linter warnings is an antipattern, not the linter proving the warning option :)
ESLint errors are an Anti-Pattern. They should be enforced only on build or merge request, not on dev environment. No one cares about a missing space when you're fixing a bug. Preventing running the app due to eslint errors is ridiculous.
Except for your first sentence, I think we’re all agreed with you here. ESLint is typically run in a pre-commit or pre-push git hook or in the CI pipeline before allowing you to merge. It’s not something you would want blocking you from building or running locally.
sorry no.
using eslint as your auto formatter will save you all that time later on.
To me, Eslint is an anti-pattern, as I prefer TypeScript.
Seems like an odd comment, no? TypeScript is great for type checking, and ESLint is great for enforcing best practices or agreed-upon coding styles/preferences. They're complementary tools, not competing tools that replace one another.
Most TypeScript projects use ESLint. The TypeScript core team even abandoned TSLint in favor of supporting ESLint with TypeScript projects.
This! IMO ESlint is a must. I can't really work anymore in a large team (3+ devs) without eslint + prettier.
Unless it's a 6 months project and I never have to touch the code again :)
Ts doesn't replace eslint
Has nothing to do with eslint
Largely I agree, but on the other hand it can also be a little annoying if eslint makes your build fail even though it would "technically" compile without problems if there was no eslint rule... Dependency arrays in React come to mind for example... Although while not technically breaking, it does make your code perform unexpectedly, so in that sense I agree its good to have en eslint error there...
I'd go further and make the build fail if you didn't comment on why you didn't include all dependencies.
There's another eslint rule for react that prevents you from using fat arrow functions for useEffect. Instead you're expected to provide a named function whose name explains what's going on.
I use "warn" for rules that have fixes that will be dealt with at commit using a hook, or at fix at save