After talking with Anton about the possibilities available with JSHint, we both came to the conclusion that it wouldn’t be possible to do what I wanted. I really wanted an AST to evaluate for context and to be able to dynamically plug in new rules at any time, including run time.
This is ESLint
- Easy to create and incorporate new rules by inspecting the AST.
- Rules can be dynamically loaded at runtime, so if you have a company- or project-specific rule that isn’t appropriate for inclusion in the tool, you can still easily use them.
- All rules are turned on and off the same way, avoiding the confusing rule configuration used by JSLint and inherited by JSHint.
- Individual rules can be configured as warnings, errors, or disabled. Errors make ESLint return a non-zero error code while warnings have a zero exit code.
- The output format for results is also completely pluggable. There’s only one formatter now but you can easily create more. These will also eventually be able to be dynamically loaded at runtime.
How ESLint differs from JSHint
Despite similar goals, ESLint and JSHint have some very specific differences. First and foremost, JSHint uses a progressive parser, finding errors along the way. ESLint uses Esprima, so the parsing is done first and then the rules are applied. That means JSHint will print out warnings up to and including a syntax error where ESLint will show only the syntax error. This makes JSHint much better for use in editors.
ESLint is much better suited for use in build systems and as a general command line utility. It works great for pre-commit hooks.
You can help
The project is in a good enough state that I can now start asking for contributions from others. What you can do:
- Write documentation on the wiki
- Create new formatters
- Create new rules (I want to get feature parity with the important JSHint rules)
- Work on some open issues
- Anything else you want
I want the development of ESLint to be as open as possible and accept as many contributions as possible. I’ve already started a Developer Guide to help people get started, but what the project really needs is contributions from the community.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.