Deutsche Version: http://de.slideshare.net/mischah/js-linting
Subtitle: JS Syntax Checking and Validation
Session from 3rd Webmontag Kassel.
Answers the question: »What is this linting thing all about?« and introduces tools like JSLint, JSHint and ESLint.
2. Michael Kühnel
- Doing web stuff since Netscape 4.7
- Frontend Developer at Micromata
- Twitter: @mkuehnel
- Website: www.michael-kuehnel.de
3. History
The (subjectively) »most important« Tools:
- JSLint (Release 2002)*
- JSHint (Initial release 2010)
- ESLint (Initial release 2013)
*JSLint only made it into this list for historical reasons.
5. 1. Same purpose - Quality
inspection
Syntax Checker and Validator (JavaScript und JSON)
6. Quality inspection
Syntax errors which will occur in the browser e.g.
- trailing comma in object literals
- Missing or unnecessary semicolons
- Lack of closing brackets
- Any kind of typing errors
7. Quality inspection
Prevention of logical errors / structural problems ➡️
Increment of maintainability e.g.
- Detection of unreachable code
- Globale variables by accident
- Unused parameters
- etc.
9. 2. Same functionality
A. Finds errors
B. Describes the problem
C. Pointing to the position in code (line number)
10. 3. Same language – same
environments
- Written in JavaScript:
- Browser
- node.js / Rhino
- JS based build tools (Grunt, gulp etc.)
- Editor Plugins
11. 4. Doesn’t guarantee error-
free code
But reduce the potential sources of error by usage in
a convenient place within your Workflow:
- Everytime you save a file
- as pre-commit hook
- within the build Process
12. There is no error-free code
btw. 😎
Additional recommendations to ensure code quality
within your team:
- Unit-Tests
- Functional Tests
- Code Reviews
14. JSLint
- Author: JavaScript Guru Douglas Crockford
(»Inventor of JSON«, Developer of JSMin)
- Quote from Crockford: »JavaScript is a sloppy
language, but inside it there is an elegant, better
language.«
- Intention: Enforcing the »Good Parts« of JavaScript
- http://jslint.com
16. JSHint
- Author: Anton Kovalyov
- Intention: A more flexible linting tool
- http://jshint.com
17. Main differences to JSLint:
- Community Driven (133 contributors)
- Test coverage of the source code (Unit-Tests)
- Less opinionated (http://anton.kovalyov.net/p/why-jshint)
- More Options (configurable)
- Support for ECMAScript 6
- Configuration via JavaScript comments or text files
(Recommendation .jshintrc ➡️ Team standard + »inheritance«)
JSHint ≠ JSLint
18. - Enforcing Options
- e.g. 'maxparams' lets you set the max number of formal
parameters allowed per function.
- Relaxing Options
- e.g. 'loopfunc' - suppresses warnings about functions inside of
loops.
- Environment options - pre-defined global variables for specific
environments
- e.g. 'jquery' - suppresses warnings about the usage of '$' und
'jQuery'.
JSHint - Options
19. Available as:
- Plugin for almost every editor/IDE
- Task for Grunt/gulp
- etc. See http://jshint.com/install
- Just for a quick test if it suits your needs: on the
website of JSHint
JSHint for all of you
20. Plans for the next major release (3.0)
- Remove all style-related options and warnings.
- If it makes sense they should be moved into
optional plugins.
- Build a foundation for plugins
See http://www.jshint.com/blog/jshint-3-plans/
JSHint - The future
23. ESLint
- Creator: Nicholas C. Zakas
- Intention:
- More flexible/ pluggable linting tool.
- Initially compatible to JSHint - in terms of
available options
- http://eslint.org
24. ESLint ≠ JSHint
Main differences to JSHint:
- API for plugging in your own rules
- Every rule is a plugin (even the default rules)
- Every rule can be able to be turned off or on!
- More rules than JSHint
- Ever rule can be set to be a warning or error individually
- Config files in JSON Format or YAML
- »More beautiful« linting reports in your terminal 😘
25. ESLint - Options
- Environments
- (browser/node/amd/mocha).
- An environment defines both global variables that are
predefined as well as which rules should be on or off by default.
- Globals
- Defining own globals so that ESLint will not warn about their
usage.
- Rules
- Activating rules and define the error-level individually.
26. ESLint - Overview of the
rules
1. Possible Errors:
- e.g. 'no-dupe-keys' – disallow duplicate keys when creating object literals
2. Best Practices:
- They either prescribe a better way of doing something or help you avoid
footguns.
- e.g. 'wrap-iife' – require immediate function invocation to be wrapped in
parentheses.
3. Strict Mode:
- These rules relate to using strict mode (ECMAScript5).
- e.g. 'no-extra-strict' – disallow unnecessary use of "use strict"; when already in
strict mode.
27. ESLint - Overview of the
rules
4. Variables:
- These rules have to do with variable declarations
- e.g. 'no-shadow' - disallow declaration of variables already declared in the
outer scope.
5. Node.js:
- These rules are specific to JavaScript running on Node.js
- e.g. 'no-process-exit' - disallow process.exit()
6. Stylistic Issues:
- These rules are purely matters of style and are quite subjective
- e.g. 'no-new-object' - disallow use of the Object constructor
28. Conclusion
ESLint – The way to go 🔥 – despite the early version (0.4.2)
- Huge set of rules with the most flexible configuration
- future-proof in terms of »style related warnings«
- Pluggability (e.g. company-specific rules to enforce coding
guidelines)
- Probably gathering the most contributors in the near future.
- The eco-system is ready: Even available as module for less know
JS build tools like Broccoli. Siehe http://eslint.org/docs/
integrations