jade-lint

Jade-Lint

An unopinionated and configurable linter and style checker for Jade

v2 under active development. Watch this space as issues are fixed, and the rules roll in :rainbow::rabbit:

CLI

Installation

$ npm install -g jade-lint

Usage

$ jade-lint [options] <file ...>

Options

• -h, --help: output usage information
• -V, --version: output the version number
• -c, --config <path>: configuration file path
• -r, --reporter <reporter>: error reporter; console - default, inline

Editor integration

Sublime Text 3

If you use SublimeLinter 3 with Sublime Text 3, you can install the SublimeLinter-jade-lint plugin using Package Control.

Atom

If you use Atom, you can install the linter-jade package.

Vim

jade-lint is part of syntastic.

If you are using vim-plug to manage your Vim plugins (recommended), you can do:

" In your ~/.vimrc
Plug 'scrooloose/syntastic'
" Then run these commands
:source %
:PlugInstall

Then to turn the jade-linter on, you will need this line in your .vimrc.

let g:syntastic_jade_checkers = ['jade_lint']

Build system integration

Gulp

If you're using Gulp as your build system, you can use gulp-jade-lint for easier integration.

Configuration file

Options and rules can be specified in a .jade-lintrc or .jade-lint.json file, or via adding a "jadeLintConfig" option to package.json.

Options

preset

Type: string

Values: "clock"

Presets are pre-defined sets of rules. You can specifically disable any preset rule by assigning it to null, like so:

{ "preset": "clock"
, "disallowIdLiterals": null
}

excludeFiles

Type: Array

Default: [ "node_modules/**" ]

Disables style checking for specified paths declared with glob patterns.

additionalRules

Type: Array

Array of file path matching patterns to load additional rules from, e.g.:

{ "additionalRules": [ "project-rules/*.js" ]
}

Rules

List of available rules

You can specifically disable any rule by omitting it from your .jade-lintrc config file or by assigning it to null, like so:

{ "disallowBlockExpansion": null
}

Some rules, if enabled at the same time, would be contradictory to one another, such as:

{ "disallowSpaceAfterCodeOperator": true
, "requireSpaceAfterCodeOperator": true
}

In this case requireSpaceAfterCodeOperator is treated as null, and ignored.