By definition (wikipedia),
“A linter is any tool that flags suspicious usage in software written in any computer language”
And the definition continues…
In summary, a linter gives you:
- It prevents bugs (some of them critical).
- Makes your code safer and better.
- Helps you learning better code.
- Maintain code quality. In some cases, like ESLint also can maintain a certain code style.
- Saves you a lot of time.
Why I use ESLint over others?
Actually, for my requirements and necessities, the best option now a day is ESLint. But doesn’t mean ESLint should be the best one for you and your necessities. There are others like JSLint, JSHint or JSCS (actually JSCS is merged with ESLint).
Since 2014, I discovered ESLint, and it fits perfectly to my necessities, better than any other. To me the pluggability is the key to match with many different approaches and workflows, the description of the ESLint says:
I think, the best way is to integrate it with a build system (webpack in my case) as part of your workflow.
Gives the project consistency making the developers agnostic on how to run ESLint, having it always as a parachute (because every time you build your code ESLint will lint it).
When you are used to this approach, trust me, doesn’t want other.
I also recommend configuring ESLint over the configuration file (
.eslintrc), is very clear where the rules are setted.
Several pieces of information can be setted on that file, I will spotlight the most important to me:
- Environment: which environment your script will be run.
- Plugins: ESLint support third-party plugins.
- And obviously rules.