node package manager
Don’t reinvent the wheel. Reuse code within your team. Create a free org »



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 🌈🐰

build status coverage status dependency status npm



$ npm install -g jade-lint


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


  • -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.


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


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 %

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


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.



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


Type: Array

Default: [ "node_modules/**" ]

Disables style checking for specified paths declared with glob patterns.


Type: Array

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

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


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.