Note: the easiest way to use a preset is with the preset option described below.
- Airbnb — https://github.com/airbnb/javascript
- Crockford — http://javascript.crockford.com/code.html
- Google — https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
- Grunt — http://gruntjs.com/contributing#syntax
- jQuery — https://contribute.jquery.org/style-guide/js/
- MDCS — https://github.com/mrdoob/three.js/wiki/Mr.doob's-Code-Style™
- node-style-guide - https://github.com/felixge/node-style-guide
- Wikimedia — https://www.mediawiki.org/wiki/Manual:Coding_conventions/JavaScript
- Wordpress — https://make.wordpress.org/core/handbook/coding-standards/javascript/
- Yandex — https://github.com/yandex/codestyle/blob/master/javascript.md
You can specifically disable any preset rule by creating a .jscsrc config file and assigning it to null, like so:
{
"preset": "jquery",
"requireCurlyBraces": null
}- Atom plugin: https://atom.io/packages/linter-jscs
- Brackets Extension: https://github.com/globexdesigns/brackets-jscs
- Grunt task: https://github.com/jscs-dev/grunt-jscs/
- Gulp task: https://github.com/jscs-dev/gulp-jscs/
- Overcommit Git pre-commit hook manager: https://github.com/brigade/overcommit/
- SublimeText 3 Plugin: https://github.com/SublimeLinter/SublimeLinter-jscs/
- Syntastic VIM Plugin: https://github.com/scrooloose/syntastic/.../syntax_checkers/javascript/jscs.vim/
- Web Essentials for Visual Studio 2013: https://github.com/madskristensen/WebEssentials2013/
- IntelliJ IDEA, RubyMine, WebStorm, PhpStorm, PyCharm plugin: https://github.com/idok/jscs-plugin
- A TeamCity reporter: https://github.com/wurmr/jscs-teamcity-reporter
- JSDoc rules extension: https://github.com/jscs-dev/jscs-jsdoc
jscs can be installed using npm:
npm install jscs -g
To run jscs, you can use the following command from the project root:
jscs path[ path[...]]
You can also pipe input into jscs:
cat myfile.js | jscs
Some CLI options can be put in your .jscsrc as well (such as esnext).
Will apply fixes to all supported style rules. (Currently whitespace rules, EOF rule, and validateIndentation)
jscs path[ path[...]] --fix
Presents a walkthrough that allows you to generate a JSCS configuration by choosing a preset and handling violated rules.
jscs --auto-configure path
path can be a file or directory to check the presets against
Allows to define path to the config file.
jscs path[ path[...]] --config=./.config.json
If there is no --config option specified, jscs it will consequentially search for jscsConfig option in package.json file then for .jscsrc (which is a just JSON with comments) and .jscs.json files in the current working directory then in nearest ancestor until it hits the system root.
If defined will use predefined rules for specific code style.
jscs path[ path[...]] --preset=jquery
In order to add/remove preset rules you will need to create a .jscsrc config file.
jscs itself provides six reporters: checkstyle, console, inline, inlinesingle, junit and text.
jscs path[ path[...]] --reporter=console
But you also can specify your own reporter, since this flag accepts relative or absolute paths too.
jscs path[ path[...]] --reporter=./some-dir/my-reporter.js
Attempts to parse your code as ES6 using the harmony version of the esprima parser. Please note that this is currently experimental, and will improve over time.
Attempts to parse your code with a custom Esprima version.
jscs path[ path[...]] --esprima=esprima-fb
The path to a module that determines whether or not an error should be reported.
jscs path[ path[...]] --error-filter=path/to/my/module.js
Clean output without colors.
Set the maximum number of errors to report
Outputs usage information.
Prepends the name of the offending rule to all error messages.
Outputs version of jscs.
Paths to load plugins. See the wiki page for more details about the Plugin API
Values: Array of NPM package names or paths
"plugins": ["jscs-plugin", "./lib/project-jscs-plugin"]Path to load additional rules
Type: Array
Values: Array of file matching patterns
"additionalRules": ["project-rules/*.js"]Extends defined rules with preset rules.
Type: String
Values: "airbnb", "crockford", "google", "jquery", "mdcs", "node-style-guide", "wikimedia", wordpress, "yandex"
"preset": "jquery"You can specifically disable any preset rule by assigning it to null, like so:
{
"preset": "jquery",
"requireCurlyBraces": null
}Disables style checking for specified paths declared with glob patterns.
Type: Array
Values: Array of file matching patterns
"excludeFiles": ["node_modules/**", "src/!(bar|foo)"]Changes the set of file extensions that will be processed.
Type: Array or String or "*"
Values: A single file extension or an Array of file extensions, beginning with a .. The matching is case insensitive. If "*" is provided, all files regardless of extension will match.
"fileExtensions": [".js", ".jsx"]"fileExtensions": [".js"]Set the maximum number of errors to report
Type: Number
Default: Infinity
"maxErrors": 10Attempts to parse your code as ES6 using the harmony version of the esprima parser.
Type: Boolean
Value: true
"esnext": truePrepends the name of the offending rule to all error messages.
Type: Boolean
Default: false
"verbose": trueCustom options to be passed to esprima.parse(code, options)
Type: Object
Default: { "tolerant": true }
"esprimaOptions": { "tolerant": true }A filter function that determines whether or not to report an error. This will be called for every found error.
Type: String
"errorFilter": "path/to/my/filter.js"See how to define an error filter.
You can specifically disable any rule by ommitting it from your .jscsrc config or by assigning it to null, like so:
{
"preset": "jquery",
"requireCurlyBraces": null
}You can disable and re-enable rules inline with two special comments: // jscs:disable and // jscs:enable. Spacing in these comments is fairly lenient. All of the following are equivalent:
/* jscs: enable */
// jscs: enableYou can use them to disable rules in several ways.
Simply using // jscs:disable or // jscs:enable will disable all rules.
var a = b;
// jscs:disable
var c = d; // all errors on this line will be ignored
// jscs:enable
var e = f; // all errors on this line will be reportedIncluding a comma separated list of rules to modify after // jscs:disable or // jscs:enable will modify only those rules.
// jscs:disable requireCurlyBraces
if (x) y(); // all errors from requireCurlyBraces on this line will be ignored
// jscs:enable requireCurlyBraces
if (z) a(); // all errors, including from requireCurlyBraces, on this line will be reportedYou can enable all rules after disabling a specific rule, and that rule becomes re-enabled as well.
// jscs:disable requireCurlyBraces
if (x) y(); // all errors from requireCurlyBraces on this line will be ignored
// jscs:enable
if (z) a(); // all errors, even from requireCurlyBraces, will be reportedYou can disable multiple rules at once and progressively re-enable them.
// jscs:disable requireCurlyBraces, requireDotNotation
if (x['a']) y(); // all errors from requireCurlyBraces OR requireDotNotation on this line will be ignored
// jscs:enable requireCurlyBraces
if (z['a']) a(); // all errors from requireDotNotation, but not requireCurlyBraces, will be ignored
// jscs:enable requireDotNotation
if (z['a']) a(); // all errors will be reportedWe recommend installing JSCS via NPM using ^, or ~ if you want more stable releases.
Semver (http://semver.org/) dictates that breaking changes be major version bumps. In the context of a linting tool, a bug fix that causes more errors to be reported can be interpreted as a breaking change. However, that would require major version bumps to occur more often than can be desirable. Therefore, as a compromise, we will only release bug fixes that cause more errors to be reported in minor versions.
Below you fill find our versioning strategy, and what you can expect to come out of a new JSCS release.
- Patch release:
- A bug fix in a rule that causes JSCS to report less errors.
- Docs, refactoring and other "invisible" changes for user;
- Minor release:
- Any preset changes.
- A bug fix in a rule that causes JSCS to report more errors.
- New rules or new options for existing rules that don't change existing behavior.
- Modifying rules so they report less errors, and don't cause build failures.
- Major release:
- Purposefully modifying existing rules so that they report more errors or change the meaning of a rule.
- Any architectural changes that could cause builds to fail.