🚫💩 lint-staged

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

1npm install --save-dev lint-staged # requires further setup

$ git commit

✔ Backed up original state in git stash (5bda95f)
❯ Running tasks for staged files...
  ❯ packages/frontend/.lintstagedrc.json — 1 file
    ↓ *.js — no files [SKIPPED]
    ❯ *.{json,md} — 1 file
      ⠹ prettier --write
  ↓ packages/backend/.lintstagedrc.json — 2 files
    ❯ *.js — 2 files
      ⠼ eslint --fix
    ↓ *.{json,md} — no files [SKIPPED]
◼ Applying modifications from tasks...
◼ Cleaning up temporary files...

Table of Contents

• Why
• Installation and setup
• Changelog
• Command line flags
• Configuration
• Filtering files
• What commands are supported?
• Running multiple commands in a sequence
• Using JS configuration files
• Reformatting the code
• Examples
• Frequently Asked Questions

Why

Code quality tasks like formatters and linters make 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 task on a whole project can be slow, and opinionated tasks such as linting can sometimes produce irrelevant results. Ultimately you only want to check 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.

Related blog posts and talks

• Introductory Medium post - Andrey Okonetchnikov, 2016
• Running Jest Tests Before Each Git Commit - Ben McCormick, 2017
• AgentConf presentation - Andrey Okonetchnikov, 2018
• SurviveJS interview - Juho Vepsäläinen and Andrey Okonetchnikov, 2018
• Prettier your CSharp with dotnet-format and lint-staged

If you've written one, please submit a PR with the link to it!

Installation and setup

To install lint-staged in the recommended way, you need to:

1. Install lint-staged itself:
   • npm install --save-dev lint-staged
2. Set up the pre-commit git hook to run lint-staged
   • Husky is a popular choice for configuring git hooks
   • Read more about git hooks here
3. Install some tools like ESLint or Prettier
4. Configure lint-staged to run code checkers and other tasks:
   • for example: { "*.js": "eslint" } to run ESLint for all staged JS files
   • See Configuration for more info

Don't forget to commit changes to package.json and .husky 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.

[!CAUTION]
Lint-staged runs git operations affecting the files in your repository. By default lint-staged creates a git stash as a backup of the original state before running any configured tasks to help prevent data loss.

Changelog

See Releases.

Migration

For breaking changes, see MIGRATION.md.

Command line flags

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

Options:
  -V, --version                      output the version number
  --allow-empty                      allow empty commits when tasks revert all staged changes (default: false)
  -p, --concurrent <number|boolean>  the number of tasks to run concurrently, or false for serial (default: true)
  -c, --config [path]                path to configuration file, or - to read from stdin
  --cwd [path]                       run all tasks in specific directory, instead of the current
  -d, --debug                        print additional debug information (default: false)
  --diff [string]                    override the default "--staged" flag of "git diff" to get list of files. Implies
                                     "--no-stash".
  --diff-filter [string]             override the default "--diff-filter=ACMR" flag of "git diff" to get list of files
  --max-arg-length [number]          maximum length of the command-line argument string (default: 0)
  --no-revert                        do not revert to original state in case of errors.
  --no-stash                         disable the backup stash. Implies "--no-revert".
  --no-hide-partially-staged         disable hiding unstaged changes from partially staged files
  -q, --quiet                        disable lint-staged’s own console output (default: false)
  -r, --relative                     pass relative filepaths to tasks (default: false)
  -v, --verbose                      show task output even when tasks succeed; by default only failed output is
                                     shown (default: false)
  -h, --help                         display help for command

Any lost modifications can be restored from a git stash:

  > git stash list
  stash@{0}: automatic lint-staged backup
  > git stash apply --index stash@{0}

• --allow-empty: By default, when tasks undo all staged changes, lint-staged will exit with an error and abort the commit. Use this flag to allow creating empty git commits.
• --concurrent [number|boolean]: Controls the concurrency of tasks being run by lint-staged. NOTE: This does NOT affect the concurrency of subtasks (they will always be run sequentially). Possible values are:
  • false: Run all tasks serially
  • true (default) : Infinite concurrency. Runs as many tasks in parallel as possible.
  • {number}: Run the specified number of tasks in parallel, where 1 is equivalent to false.
• --config [path]: Manually specify a path to a config file or npm package name. Note: when used, lint-staged won't perform the config file search and will print an error if the specified file cannot be found. If '-' is provided as the filename then the config will be read from stdin, allowing piping in the config like cat my-config.json | npx lint-staged --config -.
• --cwd [path]: By default tasks run in the current working directory. Use the --cwd some/directory to override this. The path can be absolute or relative to the current working directory.
• --debug: Run in debug mode. When set, it does the following:
  • uses debug internally to log additional 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*.
  • uses verbose renderer for listr2; this causes serial, uncoloured output to the terminal, instead of the default (beautified, dynamic) output. (the verbose renderer can also be activated by setting the TERM=dumb or NODE_ENV=test environment variables)
• --diff: By default tasks are filtered against all files staged in git, generated from git diff --staged. This option allows you to override the --staged flag with arbitrary revisions. For example to get a list of changed files between two branches, use --diff="branch1...branch2". You can also read more from about git diff and gitrevisions. This option also implies --no-stash.
• --diff-filter: By default only files that are added, copied, modified, or renamed are included. Use this flag to override the default ACMR value with something else: added (A), copied (C), deleted (D), modified (M), renamed (R), type changed (T), unmerged (U), unknown (X), or pairing broken (B). See also the git diff docs for --diff-filter.
• --max-arg-length: long commands (a lot of files) are automatically split into multiple chunks when it detects the current shell cannot handle them. Use this flag to override the maximum length of the generated command string.
• --no-stash: By default a backup stash will be created before running the tasks, and all task modifications will be reverted in case of an error. This option will disable creating the stash, and instead leave all modifications in the index when aborting the commit.
• --no-hide-partially-staged: By default, unstaged changes from partially staged files will be hidden and applied back after running tasks. This option will disable this behavior, causing those changes to also be committed.
• --quiet: Suppress all CLI output, except from tasks.
• --relative: Pass filepaths relative to process.cwd() (where lint-staged runs) to tasks. Default is false.
• --no-revert: By default all task modifications will be reverted in case of an error. This option will disable the behavior, and apply task modifications to the index before aborting the commit.
• --verbose: Show task output even when tasks succeed. By default only failed output is shown.

Configuration

Lint-staged can be configured in many ways:

• lint-staged object in your package.json, or package.yaml
• .lintstagedrc file in JSON or YML format, or you can be explicit with the file extension:
  • .lintstagedrc.json
  • .lintstagedrc.yaml
  • .lintstagedrc.yml
• .lintstagedrc.mjs or lint-staged.config.mjs file in ESM format
  • the default export value should be a configuration: export default { ... }
• .lintstagedrc.cjs or lint-staged.config.cjs file in CommonJS format
  • the exports value should be a configuration: module.exports = { ... }
• lint-staged.config.js or .lintstagedrc.js in either ESM or CommonJS format, depending on whether your project's package.json contains the "type": "module" option or not.
• Pass a configuration file using the --config or -c flag

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. JavaScript files can also export advanced configuration as a function. See Using JS configuration files for more info.

You can also place multiple configuration files in different directories inside a project. For a given staged file, the closest configuration file will always be used. See "How to use lint-staged in a multi-package monorepo?" for more info and an example.

package.json example:

1{
2  "lint-staged": {
3    "*": "your-cmd"
4  }
5}

.lintstagedrc example

1{
2  "*": "your-cmd"
3}

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

TypeScript

Lint-staged provides TypeScript types for the configuration and main Node.js API. You can use the JSDoc syntax in your JS configuration files:

1/**
2 * @filename: lint-staged.config.js
3 * @type {import('lint-staged').Configuration}
4 */
5export default {
6  '*': 'prettier --write',
7}

It's also possible to use the .ts file extension for the configuration if your Node.js version supports it. The --experimental-strip-types flag was introduced in Node.js v22.6.0 and unflagged in v23.6.0, enabling Node.js to execute TypeScript files without additional configuration.

1export NODE_OPTIONS="--experimental-strip-types"
2
3npx lint-staged --config lint-staged.config.ts

Task concurrency

By default lint-staged will run configured tasks concurrently. This means that for every glob, all the commands will be started at the same time. With the following config, both eslint and prettier will run at the same time:

1{
2  "*.ts": "eslint",
3  "*.md": "prettier --list-different"
4}

This is typically not a problem since the globs do not overlap, and the commands do not make changes to the files, but only report possible errors (aborting the git commit). If you want to run multiple commands for the same set of files, you can use the array syntax to make sure commands are run in order. In the following example, prettier will run for both globs, and in addition eslint will run for *.ts files after it. Both sets of commands (for each glob) are still started at the same time (but do not overlap).

1{
2  "*.ts": ["prettier --list-different", "eslint"],
3  "*.md": "prettier --list-different"
4}

Pay extra attention when the configured globs overlap, and tasks make edits to files. For example, in this configuration prettier and eslint might try to make changes to the same *.ts file at the same time, causing a race condition:

1{
2  "*": "prettier --write",
3  "*.ts": "eslint --fix"
4}

You can solve it using the negation pattern and the array syntax:

1{
2  "!(*.ts)": "prettier --write",
3  "*.ts": ["eslint --fix", "prettier --write"]
4}

Another example in which tasks make edits to files and globs match multiple files but don't overlap:

1{
2  "*.css": ["stylelint --fix", "prettier --write"],
3  "*.{js,jsx}": ["eslint --fix", "prettier --write"],
4  "!(*.css|*.js|*.jsx)": ["prettier --write"]
5}

Or, if necessary, you can limit the concurrency using --concurrent <number> or disable it entirely with --concurrent false.

Filtering files

Task 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 be 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
  • "!(*.css|*.js)" will match all files except CSS and JS files
• 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 /foo directory, so /foo/bar/test.js but 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 tasks as arguments.

NOTE: lint-staged will pass absolute paths to the tasks 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 tasks (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:

1{
2  "*.js": "eslint --fix"
3}

This will result in lint-staged running eslint --fix file-1.js file-2.js, when you have staged files file-1.js, file-2.js and README.md.

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

Running multiple commands in a sequence

You can run multiple commands in a sequence on every glob. To do so, pass an array of commands instead of a single one. This is useful for running autoformatting tools like eslint --fix or stylefmt but can be used for any arbitrary sequences.

For example:

1{
2  "*.js": ["eslint", "prettier --write"]
3}

going to execute eslint and if it exits with 0 code, it will execute prettier --write on all staged *.js files.

This will result in lint-staged running eslint file-1.js file-2.js, when you have staged files file-1.js, file-2.js and README.md, and if it passes, prettier --write file-1.js file-2.js.

Using JS configuration files

Writing the configuration file in JavaScript is the most powerful way to configure lint-staged (lint-staged.config.js, similar, or passed via --config). From the configuration file, you can export either a single function or an object.

If the exports value is a function, it will receive an array of all staged filenames. You can then build your own matchers for the files and return a command string or an array of command strings. These strings are considered complete and should include the filename arguments, if wanted.

If the exports value is an object, its keys should be glob matches (like in the normal non-js config format). The values can either be like in the normal config or individual functions like described above. Instead of receiving all matched files, the functions in the exported object will only receive the staged files matching the corresponding glob key.

To summarize, by default lint-staged automatically adds the list of matched staged files to your command, but when building the command using JS functions it is expected to do this manually. For example:

1export default {
2  '*.js': (stagedFiles) => [`eslint .`, `prettier --write ${stagedFiles.join(' ')}`],
3}

This will result in lint-staged first running eslint . (matching all files), and if it passes, prettier --write file-1.js file-2.js, when you have staged files file-1.js, file-2.js and README.md.

JavaScript Functions

You can also configure lint-staged to run a JavaScript/Node.js script directly, passing the list of staged files as an argument:

1export default {
2  '*.js': {
3    title: 'Log staged JS files to console',
4    task: async (files) => {
5      console.log('Staged JS files:', files)
6    },
7  },
8}

Example: Export a function to build your own matchers

1// lint-staged.config.js
2import micromatch from 'micromatch'
3
4export default (allStagedFiles) => {
5  const shFiles = micromatch(allStagedFiles, ['**/src/**/*.sh'])
6  if (shFiles.length) {
7    return `printf '%s\n' "Script files aren't allowed in src directory" >&2`
8  }
9  const codeFiles = micromatch(allStagedFiles, ['**/*.js', '**/*.ts'])
10  const docFiles = micromatch(allStagedFiles, ['**/*.md'])
11  return [`eslint ${codeFiles.join(' ')}`, `mdl ${docFiles.join(' ')}`]
12}

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

1// .lintstagedrc.js
2export default {
3  '**/*.js?(x)': (filenames) => filenames.map((filename) => `prettier --write '${filename}'`),
4}

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

1// lint-staged.config.js
2export default {
3  '**/*.ts?(x)': () => 'tsc -p tsconfig.json --noEmit',
4}

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

1// .lintstagedrc.js
2export default {
3  '**/*.js?(x)': (filenames) =>
4    filenames.length > 10 ? 'eslint .' : `eslint ${filenames.join(' ')}`,
5}

Example: Use your own globs

1// lint-staged.config.js
2import micromatch from 'micromatch'
3
4export default {
5  '*': (allFiles) => {
6    const codeFiles = micromatch(allFiles, ['**/*.js', '**/*.ts'])
7    const docFiles = micromatch(allFiles, ['**/*.md'])
8    return [`eslint ${codeFiles.join(' ')}`, `mdl ${docFiles.join(' ')}`]
9  },
10}

Example: Ignore files from match

1// lint-staged.config.js
2import micromatch from 'micromatch'
3
4export default {
5  '*.js': (files) => {
6    // from `files` filter those _NOT_ matching `*test.js`
7    const match = micromatch.not(files, '*test.js')
8    return `eslint ${match.join(' ')}`
9  },
10}

Example: Use relative paths for commands

1import path from 'path'
2
3export default {
4  '*.ts': (absolutePaths) => {
5    const cwd = process.cwd()
6    const relativePaths = absolutePaths.map((file) => path.relative(cwd, file))
7    return `ng lint myProjectName --files ${relativePaths.join(' ')}`
8  },
9}

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.

1{
2  "*.js": "prettier --write"
3}

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 assume you've already set up lint-staged in the package.json file and husky in its own config file.

1{
2  "name": "My project",
3  "version": "0.1.0",
4  "scripts": {
5    "my-custom-script": "linter --arg1 --arg2"
6  },
7  "lint-staged": {}
8}

In .husky/pre-commit

1# .husky/pre-commit
2
3npx 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

1{
2  "*.{js,jsx}": "eslint"
3}

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

1{
2  "*.js": "eslint --fix"
3}

Reuse npm script

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

1{
2  "*.js": "linter --arg1 --arg2"
3}

Use environment variables with task commands

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

Automatically fix code style with prettier for any format Prettier supports

1{
2  "*": "prettier --ignore-unknown --write"
3}

Automatically fix code style with prettier for JavaScript, TypeScript, Markdown, HTML, or CSS

1{
2  "*.{js,jsx,ts,tsx,md,html,css}": "prettier --write"
3}

Stylelint for CSS with defaults and for SCSS with SCSS syntax

1{
2  "*.css": "stylelint",
3  "*.scss": "stylelint --syntax=scss"
4}

Run PostCSS sorting and Stylelint to check

1{
2  "*.scss": ["postcss --config path/to/your/config --replace", "stylelint"]
3}

Minify the images

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

Typecheck your staged files with flow

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

Integrate with Next.js

1// .lintstagedrc.js
2// See https://nextjs.org/docs/basic-features/eslint#lint-staged for details
3
4const path = require('path')
5
6const buildEslintCommand = (filenames) =>
7  `next lint --fix --file ${filenames.map((f) => path.relative(process.cwd(), f)).join(' --file ')}`
8
9module.exports = {
10  '*.{js,jsx,ts,tsx}': [buildEslintCommand],
11}

Frequently Asked Questions

The output of commit hook looks weird (no colors, duplicate lines, verbose output on Windows, …)

1# .husky/pre-commit
2
3if sh -c ": >/dev/tty" >/dev/null 2>/dev/null; then exec >/dev/tty 2>&1; fi
4
5npx lint-staged

Can I use lint-staged via node?

1import lintStaged from 'lint-staged'
2
3try {
4  const success = await lintStaged()
5  console.log(success ? 'Linting was successful!' : 'Linting failed!')
6} catch (e) {
7  // Failed to load configuration
8  console.error(e)
9}

1const success = await lintStaged({
2  allowEmpty: false,
3  concurrent: true,
4  configPath: './path/to/configuration/file',
5  cwd: process.cwd(),
6  debug: false,
7  maxArgLength: null,
8  quiet: false,
9  relative: false,
10  stash: true,
11  verbose: false,
12})

1const success = await lintStaged({
2  allowEmpty: false,
3  concurrent: true,
4  config: { '*.js': 'eslint --fix' },
5  cwd: process.cwd(),
6  debug: false,
7  maxArgLength: null,
8  quiet: false,
9  relative: false,
10  stash: true,
11  verbose: false,
12})

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

1{
2  "husky": {
3    "hooks": {
4      "pre-commit": "lint-staged",
5      "post-commit": "git update-index --again"
6    }
7  }
8}

1{
2  "scripts": {
3    "precommit": "lint-staged",
4    "postcommit": "git update-index --again"
5  }
6}

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

1// ./.lintstagedrc.json
2{ "*.md": "prettier --write" }

1// ./packages/frontend/.lintstagedrc.json
2{ "*.js": "eslint --fix" }

1import baseConfig from '../.lintstagedrc.js'
2
3export default {
4  ...baseConfig,
5  '*.js': 'eslint --fix',
6}

Can I lint files outside of the current project folder?

Can I run lint-staged in CI, or when there are no staged files?

git diff --diff-filter=ACMR --name-only main...my-branch

npx lint-staged --diff="main...my-branch"

Can I use lint-staged with ng lint

How can I ignore files from .eslintignore?

1import { CLIEngine } from 'eslint'
2
3export default {
4  '*.js': (files) => {
5    const cli = new CLIEngine({})
6    return 'eslint --max-warnings=0 ' + files.filter((file) => !cli.isPathIgnored(file)).join(' ')
7  },
8}

1import { ESLint } from 'eslint'
2
3const removeIgnoredFiles = async (files) => {
4  const eslint = new ESLint()
5  const isIgnored = await Promise.all(
6    files.map((file) => {
7      return eslint.isPathIgnored(file)
8    })
9  )
10  const filteredFiles = files.filter((_, i) => !isIgnored[i])
11  return filteredFiles.join(' ')
12}
13
14export default {
15  '**/*.{ts,tsx,js,jsx}': async (files) => {
16    const filesToLint = await removeIgnoredFiles(files)
17    return [`eslint --max-warnings=0 ${filesToLint}`]
18  },
19}

1{
2  "*.js": "eslint --max-warnings=0 --no-warn-ignored"
3}

How can I resolve TypeScript (tsc) ignoring tsconfig.json when lint-staged runs via Husky hooks?

1// package.json
2
3"lint-staged": {
4    "*.{ts,tsx}":[
5      "tsc --noEmit",
6      "prettier --write"
7    ]
8  }

1// lint-staged.config.js
2module.exports = {
3  '*.{ts,tsx}': [() => 'tsc --noEmit', 'prettier --write'],
4}