ESLint as a Replacement for JSHint and JSCS
If you and your fellow engineers are going to make a serious go at writing robust Javascript applications, you should use both a linter and some form of code style enforcement during the development process. This is true for any loosely typed language, really, but Javascript lets you get away with so very much more, and is so very finicky in some environments, that the extra guide-rails are more of a necessary than a nice to have feature. Sooner or later you will be sorry, annoyed, and put to extra work if you don't use them.
JSHint is a popular linter that covers functional issues, while JSCS covers code style. This means two separate packages, two separate configurations, and two separate processes to run when linting code. Fortunately both can be replaced with ESLint, which covers both function and style, and can be easily extended with new rules if you find that something is missing.
Installing ESLint
Assuming you have Node.js installed, globally install the ESLint executable:
sudo npm install -g eslint
Setting Up ESLint with Sublime Text 3
If using Sublime Text 3, you can install Package Control followed by the SublimeLinter and SublimeLinter-contrib-eslint packages.
ESLint Integration with Development Tools
Most of the popular open Javascript task and testing frameworks integrate with ESLint in simple and useful ways, including Grunt, Gulp, webpack, and so forth.
Configure Behavior with .eslintrc Files
The most flexible way to configure the behavior of ESLint is to place .eslintrc files into your project directories. Unlike JSHint, linting rules not specified are inherited from .eslintrc files in higher level directories, which makes things very much more convenient. Typically you will add rules incrementally as needed in lower directories, for test environments, for example, or when a single project has Node.js and browser code in different directories.
ESLint is fairly opinionated, with most of its rules turned on and given baseline configurations by default. Since these defaults roughly conform to the way in which most professionals write Javascript these days, .eslintrc files can be short and to the point, which is a refreshing change after working with JSCS.
As an example, the following is a good starting point for the top level directory in a Node.js project:
{ "env": { "node": true }, "rules": { "brace-style": [2, "stroustrup", { "allowSingleLine": true }], "consistent-return": 0, "curly": 2, "eqeqeq": 2, "indent": [2, 2, { "SwitchCase": 1 }], "key-spacing": [2, { "beforeColon": false, "afterColon": true }], "no-multiple-empty-lines": 2, "no-throw-literal": 2, "no-underscore-dangle": 0, "no-unused-vars": [2, { "vars": "all", "args": "none" }], "no-use-before-define": [2, "nofunc"], "object-curly-spacing": [2, "always"], "quote-props": [2, "as-needed"], "quotes": [2, "single"], "radix": 2, "space-after-keywords": [2, "always"], "space-before-blocks": [2, "always"], "space-in-parens": [2, "never"], "space-unary-ops": [2, { "words": true, "nonwords": false }], "strict": [2, "never"], "wrap-iife": [2, "inside"] } }