🚫💩 lint-staged

Run linters against staged git files and don't let :poop: slip into your code base!

Why

Linting makes more sense when run before committing your code. By doing so you can ensure no errors go into the repository and enforce code style. But running a lint process on a whole project is slow and linting results can be irrelevant. Ultimately you only want to lint files that will be committed.

This project contains a script that will run arbitrary shell tasks with a list of staged files as an argument, filtered by a specified glob pattern.

Installation and setup

The fastest way to start using lint-staged is to run following command in your terminal:

npx mrm lint-staged

It will install and configure husky and lint-staged depending on code quality tools from package.json dependencies so please make sure you install (npm install --save-dev) and configure all code quality tools like Prettier, ESlint prior that.

Don't forget to commit changes to package.json to share this setup with your team!

Now change a few files, git add or git add --patch some of them to your commit and try to git commit them.

See examples and configuration for more information.

Changelog

See Releases

Command line flags

$ npx lint-staged --help
Usage: lint-staged [options]

Options:
  -V, --version        output the version number
  -c, --config [path]  Path to configuration file
  -r, --relative       Pass relative filepaths to tasks
  -x, --shell          Skip parsing of tasks for better shell support
  -q, --quiet          Disable lint-staged’s own console output
  -d, --debug          Enable debug mode
  -h, --help           output usage information

--config [path]: This can be used to manually specify the lint-staged config file location. However, if the specified file cannot be found, it will error out instead of performing the usual search. You may pass a npm package name for configuration also.
--relative: By default filepaths will be passed to the linter tasks as absolute. This flag makes them relative to process.cwd() (where lint-staged runs).
--shell: By default linter commands will be parsed for speed and security. This has the side-effect that regular shell scripts might not work as expected. You can skip parsing of commands with this option.
--quiet: By default lint-staged will print progress status to console while running linters. Use this flag to supress all output, except for linter scripts.
--debug: Enabling the debug mode does the following:
- lint-staged uses the debug module internally to log information about staged files, commands being executed, location of binaries, etc. Debug logs, which are automatically enabled by passing the flag, can also be enabled by setting the environment variable $DEBUG to lint-staged*.
- Use the verbose renderer for listr.

Configuration

Starting with v3.1 you can now use different ways of configuring it:

lint-staged object in your package.json
.lintstagedrc file in JSON or YML format
lint-staged.config.js file in JS format
Pass a configuration file using the --config or -c flag

See cosmiconfig for more details on what formats are supported.

Configuration should be an object where each value is a command to run and its key is a glob pattern to use for this command. This package uses micromatch for glob patterns.

`package.json` example:

{
  "lint-staged": {
    "*": "your-cmd"
  }
}

`.lintstagedrc` example

{
  "*": "your-cmd"
}

This config will execute your-cmd with the list of currently staged files passed as arguments.

So, considering you did git add file1.ext file2.ext, lint-staged will run the following command:

your-cmd file1.ext file2.ext

Filtering files

Linter commands work on a subset of all staged files, defined by a glob pattern. `lint-staged´ uses micromatch for matching files with the following rules:

If the glob pattern contains no slashes (/), micromatch's matchBase option will enabled, so globs match a file's basename regardless of directory:
- "*.js" will match all JS files, like /test.js and /foo/bar/test.js
- "!(*test).js". will match all JS files, except those ending in test.js, so foo.js but not foo.test.js
If the glob pattern does contain a slash (/), it will match for paths as well:
- "./*.js" will match all JS files in the git repo root, so /test.js but not /foo/bar/test.js
- "foo/**/\*.js" will match all JS files inside the/foodirectory, so/foo/bar/test.jsbut not/test.js

When matching, lint-staged will do the following

Resolve the git root automatically, no configuration needed.
Pick the staged files which are present inside the project directory.
Filter them using the specified glob patterns.
Pass absolute paths to the linters as arguments.

NOTE: lint-staged will pass absolute paths to the linters to avoid any confusion in case they're executed in a different working directory (i.e. when your .git directory isn't the same as your package.json directory).

Also see How to use lint-staged in a multi package monorepo?

Ignoring files

The concept of lint-staged is to run configured linter (or other) tasks on files that are staged in git. lint-staged will always pass a list of all staged files to the task, and ignoring any files should be configured in the task itself.

Consider a project that uses prettier to keep code format consistent across all files. The project also stores minified 3rd-party vendor libraries in the vendor/ directory. To keep prettier from throwing errors on these files, the vendor directory should be added to prettier's ignore configuration, the .prettierignore file. Running npx prettier . will ignore the entire vendor directory, throwing no errors. When lint-staged is added to the project and configured to run prettier, all modified and staged files in the vendor directory will be ignored by prettier, even though it receives them as input.

In advanced scenarios, where it is impossible to configure the linter task itself to ignore files, but some staged files should still be ignored by lint-staged, it is possible to filter filepaths before passing them to tasks by using the function syntax. See Example: Ignore files from match.

What commands are supported?

Supported are any executables installed locally or globally via npm as well as any executable from your $PATH.

Using globally installed scripts is discouraged, since lint-staged may not work for someone who doesn’t have it installed.

lint-staged uses execa to locate locally installed scripts. So in your .lintstagedrc you can write:

{
  "*.js": "eslint --fix"
}

Pass arguments to your commands separated by space as you would do in the shell. See examples below.

Starting from v2.0.0 sequences of commands are supported. Pass an array of commands instead of a single one and they will run sequentially. This is useful for running autoformatting tools like eslint --fix or stylefmt but can be used for any arbitrary sequences.

Using JS functions to customize linter commands

When supplying configuration in JS format it is possible to define the linter command as a function which receives an array of staged filenames/paths and returns the complete linter command as a string. It is also possible to return an array of complete command strings, for example when the linter command supports only a single file input.

type LinterFn = (filenames: string[]) => string | string[]

Example: Wrap filenames in single quotes and run once per file

// .lintstagedrc.js
module.exports = {
  '**/*.js?(x)': filenames => filenames.map(filename => `prettier --write '${filename}'`)
}

Example: Run `tsc` on changes to TypeScript files, but do not pass any filename arguments

// lint-staged.config.js
module.exports = {
  '**/*.ts?(x)': () => 'tsc -p tsconfig.json --noEmit'
}

Example: Run eslint on entire repo if more than 10 staged files

// .lintstagedrc.js
module.exports = {
  '**/*.js?(x)': filenames => (filenames.length > 10 ? 'eslint .' : `eslint ${filenames.join(' ')}`)
}

Example: Use your own globs

// lint-staged.config.js
const micromatch = require('micromatch')
module.exports = {
  '*': allFiles => {
    const match = micromatch(allFiles, ['*.js', '*.ts'])
    return match.map(file => `eslint ${file}`)
  }
}

Example: Ignore files from match

If for some reason you want to ignore files from the glob match, you can use micromatch.not():

// lint-staged.config.js
const micromatch = require('micromatch')
module.exports = {
  '*.js': files => {
    // from `files` filter those _NOT_ matching `*test.js`
    const match = micromatch.not(files, '*test.js')
    return match.map(file => `eslint ${file}`)
  }
}

Please note that for most cases, globs can achieve the same effect. For the above example, a matching glob would be !(*test).js.

Example: Use relative paths for commands

const path = require('path')
module.exports = {
  '*.ts': absolutePaths => {
    const cwd = process.cwd()
    const relativePaths = absolutePaths.map(file => path.relative(cwd, file))
    return `ng lint myProjectName --files ${relativePaths.join(' ')}`
  }
}

Reformatting the code

Tools like Prettier, ESLint/TSLint, or stylelint can reformat your code according to an appropriate config by running prettier --write/eslint --fix/tslint --fix/stylelint --fix. Lint-staged will automatically add any modifications to the commit as long as there are no errors.

{
  "*.js": "prettier --write"
}

Prior to version 10, tasks had to manually include git add as the final step. This behavior has been integrated into lint-staged itself in order to prevent race conditions with multiple tasks editing the same files. If lint-staged detects git add in task configurations, it will show a warning in the console. Please remove git add from your configuration after upgrading.

Examples

All examples assuming you’ve already set up lint-staged and husky in the package.json.

{
  "name": "My project",
  "version": "0.1.0",
  "scripts": {
    "my-custom-script": "linter --arg1 --arg2"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {}
}

Note we don’t pass a path as an argument for the runners. This is important since lint-staged will do this for you.

ESLint with default parameters for `.js` and `.jsx` running as a pre-commit hook

{
  "*.{js,jsx}": "eslint"
}

Automatically fix code style with `--fix` and add to commit

{
  "*.js": "eslint --fix"
}

This will run eslint --fix and automatically add changes to the commit.

Reuse npm script

If you wish to reuse a npm script defined in your package.json:

{
  "*.js": "npm run my-custom-script --"
}

The following is equivalent:

{
  "*.js": "linter --arg1 --arg2"
}

Use environment variables with linting commands

Linting commands do not support the shell convention of expanding environment variables. To enable the convention yourself, use a tool like cross-env.

For example, here is jest running on all .js files with the NODE_ENV variable being set to "test":

{
  "*.js": ["cross-env NODE_ENV=test jest --bail --findRelatedTests"]
}

Automatically fix code style with `prettier` for javascript + flow, typescript, markdown or html

{
  "*.{js,jsx}": "prettier --write"
}

{
  "*.{ts,tsx}": "prettier --write"
}

{
  "*.{md,html}": "prettier --write"
}

Stylelint for CSS with defaults and for SCSS with SCSS syntax

{
  "*.css": "stylelint",
  "*.scss": "stylelint --syntax=scss"
}

Run PostCSS sorting and Stylelint to check

{
  "*.scss": "postcss --config path/to/your/config --replace", "stylelint"
}

Minify the images

{
  "*.{png,jpeg,jpg,gif,svg}": "imagemin-lint-staged"
}

<summary>More about imagemin-lint-staged</summary>

imagemin-lint-staged is a CLI tool designed for lint-staged usage with sensible defaults.

See more on this blog post for benefits of this approach.

Typecheck your staged files with flow

{
  "*.{js,jsx}": "flow focus-check"
}

Frequently Asked Questions

Can I use `lint-staged` via node?

Yes!

const lintStaged = require('lint-staged')

try {
  const success = await lintStaged()
  console.log(success ? 'Linting was successful!' : 'Linting failed!')
} catch (e) {
  // Failed to load configuration
  console.error(e)
}

Parameters to lintStaged are equivalent to their CLI counterparts:

const success = await lintStaged({
  configPath: './path/to/configuration/file',
  maxArgLength: null,
  relative: false,
  shell: false,
  quiet: false,
  debug: false
})

You can also pass config directly with config option:

const success = await lintStaged({
  config: {
    '*.js': 'eslint --fix'
  },
  maxArgLength: null,
  relative: false,
  shell: false,
  quiet: false,
  debug: false
})

The maxArgLength option configures chunking of tasks into multiple parts that are run one after the other. This is to avoid issues on Windows platforms where the maximum length of the command line argument string is limited to 8192 characters. Lint-staged might generate a very long argument string when there are many staged files. This option is set automatically from the cli, but not via the Node.js API by default.

Using with JetBrains IDEs (WebStorm, PyCharm, IntelliJ IDEA, RubyMine, etc.)

Update: The latest version of JetBrains IDEs now support running hooks as you would expect.

When using the IDE's GUI to commit changes with the precommit hook, you might see inconsistencies in the IDE and command line. This is known issue at JetBrains so if you want this fixed, please vote for it on YouTrack.

Until the issue is resolved in the IDE, you can use the following config to work around it:

husky v1.x

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "post-commit": "git update-index --again"
    }
  }
}

husky v0.x

{
  "scripts": {
    "precommit": "lint-staged",
    "postcommit": "git update-index --again"
  }
}

Thanks to this comment for the fix!

How to use `lint-staged` in a multi package monorepo?

Starting with v5.0, lint-staged automatically resolves the git root without any additional configuration. You configure lint-staged as you normally would if your project root and git root were the same directory.

If you wish to use lint-staged in a multi package monorepo, it is recommended to install husky in the root package.json. lerna can be used to execute the precommit script in all sub-packages.

Example repo: sudo-suhas/lint-staged-multi-pkg.

Can I lint files outside of the current project folder?

tl;dr: Yes, but the pattern should start with ../.

By default, lint-staged executes linters only on the files present inside the project folder(where lint-staged is installed and run from). So this question is relevant only when the project folder is a child folder inside the git repo. In certain project setups, it might be desirable to bypass this restriction. See #425, #487 for more context.

lint-staged provides an escape hatch for the same(>= v7.3.0). For patterns that start with ../, all the staged files are allowed to match against the pattern. Note that patterns like *.js, **/*.js will still only match the project files and not any of the files in parent or sibling directories.

Example repo: sudo-suhas/lint-staged-django-react-demo.

Current Tags

11.3.0-beta.2 ... beta (3 years ago)
15.2.10 ... latest (2 months ago)
13.1.4 ... next (2 years ago)

🚫💩 lint-staged

Why

Related blogs posts and talks

Installation and setup

Changelog

Command line flags

Configuration

`package.json` example:

`.lintstagedrc` example

Filtering files

Ignoring files

What commands are supported?

Using JS functions to customize linter commands

Example: Wrap filenames in single quotes and run once per file

Example: Run `tsc` on changes to TypeScript files, but do not pass any filename arguments

Example: Run eslint on entire repo if more than 10 staged files

Example: Use your own globs

Example: Ignore files from match

Example: Use relative paths for commands

Reformatting the code

Examples

ESLint with default parameters for `.js` and `.jsx` running as a pre-commit hook

Automatically fix code style with `--fix` and add to commit

Reuse npm script

Use environment variables with linting commands

Automatically fix code style with `prettier` for javascript + flow, typescript, markdown or html

Stylelint for CSS with defaults and for SCSS with SCSS syntax

Run PostCSS sorting and Stylelint to check

Minify the images

Typecheck your staged files with flow

Frequently Asked Questions

Can I use `lint-staged` via node?

Using with JetBrains IDEs (WebStorm, PyCharm, IntelliJ IDEA, RubyMine, etc.)

How to use `lint-staged` in a multi package monorepo?

Can I lint files outside of the current project folder?

Current Tags

250 Versions

🚫💩 lint-staged

Why

Related blogs posts and talks

Installation and setup

Changelog

Command line flags

Configuration

package.json example:

.lintstagedrc example

Filtering files

Ignoring files

What commands are supported?

Using JS functions to customize linter commands

Example: Wrap filenames in single quotes and run once per file

Example: Run tsc on changes to TypeScript files, but do not pass any filename arguments

Example: Run eslint on entire repo if more than 10 staged files

Example: Use your own globs

Example: Ignore files from match

Example: Use relative paths for commands

Reformatting the code

Examples

ESLint with default parameters for *.js and *.jsx running as a pre-commit hook

Automatically fix code style with --fix and add to commit

Reuse npm script

Use environment variables with linting commands

Automatically fix code style with prettier for javascript + flow, typescript, markdown or html

Stylelint for CSS with defaults and for SCSS with SCSS syntax

Run PostCSS sorting and Stylelint to check

Minify the images

Typecheck your staged files with flow

Frequently Asked Questions

Can I use lint-staged via node?

Using with JetBrains IDEs (WebStorm, PyCharm, IntelliJ IDEA, RubyMine, etc.)

How to use lint-staged in a multi package monorepo?

Can I lint files outside of the current project folder?

Current Tags

250 Versions

`package.json` example:

`.lintstagedrc` example

Example: Run `tsc` on changes to TypeScript files, but do not pass any filename arguments

ESLint with default parameters for `.js` and `.jsx` running as a pre-commit hook

Automatically fix code style with `--fix` and add to commit

Automatically fix code style with `prettier` for javascript + flow, typescript, markdown or html

Can I use `lint-staged` via node?

How to use `lint-staged` in a multi package monorepo?