lint-staged
Lint files staged by git
Last updated 3 days ago by okonet .
MIT · Repository · Bugs · Original npm · Tarball · package.json
$ cnpm install lint-staged 
SYNC missed versions from official npm registry.

???????? lint-staged Build Status for Linux Build Status for Windows npm version Codecov

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

asciicast

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.

Related blogs posts and talks

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

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

$ ./node_modules/.bin/lint-staged --help

  Usage: lint-staged [options]


  Options:

    -V, --version        output the version number
    -c, --config [path]  Configuration file path or package
    -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.
  • --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.
    • Do not pass --silent to npm scripts.

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.

Lint-staged supports simple and advanced config formats.

Simple config format

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

Advanced config format

To extend and customise lint-staged, advanced options are available. To use these options the format should be as the following:

package.json example with ignore option:

{
  "lint-staged": {
    "linters": {
      "*.{js,scss}": ["some command", "git add"]
    },
    "ignore": ["**/dist/*.min.js"]
  }
}

Notice that the linting commands now are nested into the linters object. The following options are available for advanced configuration:

Options

  • concurrenttrue — runs linters for each glob pattern simultaneously. If you don’t want this, you can set concurrent: false
  • chunkSize — Max allowed chunk size based on number of files for glob pattern. This option is only applicable on Windows based systems to avoid command length limitations. See #147
  • globOptions{ matchBase: true, dot: true }micromatch options to customize how glob patterns match files.
  • ignore - ['**/docs/**/*.js'] - array of glob patterns to entirely ignore from any task.
  • lintersObject — keys (String) are glob patterns, values (Array<String> | String) are commands to execute.
  • subTaskConcurrency1 — Controls concurrency for processing chunks generated for each linter. This option is only applicable on Windows. Execution is not concurrent by default(see #225)
  • relativefalse — if true it will give the relative path from your package.json directory to your linter arguments.

Filtering files

It is possible to run linters for certain paths only by using glob patterns. micromatch is used to filter the staged files according to these patterns. File patterns should be specified relative to the package.json location (i.e. where lint-staged is installed).

NOTE: If you're using lint-staged<5 globs have to be relative to the git root.

{
  // .js files anywhere in the root directory of the project
  "*.js": "eslint",
  // .js files anywhere in the project
  "**/*.js": "eslint",
  // .js file in the src directory
  "src/*.js": "eslint",
  // .js file anywhere within and below the src directory
  "src/**/*.js": "eslint",
}

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?

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 is using npm-which 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.

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. After the code is reformatted, we want it to be added to the same commit. This can be done using following config:

{
  "*.js": ["prettier --write", "git add"]
}

Starting from v8, lint-staged will stash your remaining changes (not added to the index) and restore them from stash afterwards if there are partially staged files detected. This allows you to create partial commits with hunks using git add --patch. See the blog post

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", "git add"]
}

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 --", "git add"]
}

The following is equivalent:

{
  "*.js": ["linter --arg1 --arg2", "git add"]
}

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", "git add"]
}
{
  "*.{ts,tsx}": ["prettier --write", "git add"]
}
{
  "*.{md,html}": ["prettier --write", "git add"]
}

Use ng lint with angular cli >= 7.0.0

{
  "linters": {
    "*.ts": "ng lint myProjectName --files"
  },
  "relative": true
}

Stylelint for CSS with defaults and for SCSS with SCSS syntax

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

Run PostCSS sorting, add files to commit and run Stylelint to check

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

Minify the images and add files to commit

{
  "*.{png,jpeg,jpg,gif,svg}": ["imagemin-lint-staged", "git add"]
}
<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", "git add"]
}

Frequently Asked Questions

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

  • 8.0.0-beta.4                                ...           beta (8 months ago)
  • 8.2.1                                ...           latest (3 days ago)

96 Versions

  • 8.2.1                                ...           3 days ago
  • 8.2.0                                ...           10 days ago
  • 8.1.7                                ...           a month ago
  • 8.1.6                                ...           a month ago
  • 8.1.5                                ...           3 months ago
  • 8.1.4                                ...           4 months ago
  • 8.1.3                                ...           4 months ago
  • 8.1.2                                ...           4 months ago
  • 8.1.1                                ...           5 months ago
  • 8.1.0                                ...           7 months ago
  • 8.0.5                                ...           7 months ago
  • 8.0.4                                ...           8 months ago
  • 8.0.3                                ...           8 months ago
  • 8.0.2                                ...           8 months ago
  • 8.0.1                                ...           8 months ago
  • 8.0.0                                ...           8 months ago
  • 8.0.0-beta.4                                ...           8 months ago
  • 8.0.0-beta.3                                ...           8 months ago
  • 8.0.0-beta.2                                ...           9 months ago
  • 7.3.0                                ...           9 months ago
  • 8.0.0-beta.1                                ...           9 months ago
  • 8.0.0-beta.0                                ...           9 months ago
  • 7.2.2                                ...           10 months ago
  • 7.2.1                                ...           10 months ago
  • 7.2.0                                ...           a year ago
  • 7.1.3                                ...           a year ago
  • 7.1.2                                ...           a year ago
  • 7.1.1                                ...           a year ago
  • 7.1.0                                ...           a year ago
  • 7.0.5                                ...           a year ago
  • 7.0.4                                ...           a year ago
  • 7.0.3                                ...           a year ago
  • 7.0.2                                ...           a year ago
  • 7.0.1                                ...           a year ago
  • 7.0.0                                ...           a year ago
  • 6.1.1                                ...           a year ago
  • 6.1.0                                ...           a year ago
  • 6.0.1                                ...           a year ago
  • 6.0.0                                ...           2 years ago
  • 5.0.0                                ...           2 years ago
  • 4.3.0                                ...           2 years ago
  • 4.2.3                                ...           2 years ago
  • 4.2.2                                ...           2 years ago
  • 4.2.1                                ...           2 years ago
  • 4.2.0                                ...           2 years ago
  • 4.1.3                                ...           2 years ago
  • 4.1.2                                ...           2 years ago
  • 4.1.1                                ...           2 years ago
  • 4.1.0                                ...           2 years ago
  • 4.0.4                                ...           2 years ago
  • 4.0.3                                ...           2 years ago
  • 4.0.2                                ...           2 years ago
  • 4.0.1                                ...           2 years ago
  • 4.0.0                                ...           2 years ago
  • 3.6.1                                ...           2 years ago
  • 3.6.0                                ...           2 years ago
  • 3.5.1                                ...           2 years ago
  • 3.5.0                                ...           2 years ago
  • 3.4.2                                ...           2 years ago
  • 3.4.1                                ...           2 years ago
  • 3.4.0                                ...           2 years ago
  • 3.3.2                                ...           2 years ago
  • 3.3.1                                ...           2 years ago
  • 3.3.0                                ...           2 years ago
  • 3.2.9                                ...           2 years ago
  • 3.2.8                                ...           2 years ago
  • 3.2.7                                ...           2 years ago
  • 3.2.6                                ...           2 years ago
  • 3.2.5                                ...           2 years ago
  • 3.2.4                                ...           2 years ago
  • 3.2.3                                ...           3 years ago
  • 3.2.2                                ...           3 years ago
  • 3.2.1                                ...           3 years ago
  • 3.2.0                                ...           3 years ago
  • 3.1.1                                ...           3 years ago
  • 3.1.0                                ...           3 years ago
  • 4.0.0-beta-2                                ...           3 years ago
  • 4.0.0-beta-1                                ...           3 years ago
  • 3.0.3                                ...           3 years ago
  • 3.0.2                                ...           3 years ago
  • 3.0.1                                ...           3 years ago
  • 2.0.3                                ...           3 years ago
  • 3.0.0-beta1                                ...           3 years ago
  • 3.0.0                                ...           3 years ago
  • 2.0.2                                ...           3 years ago
  • 2.0.1                                ...           3 years ago
  • 2.0.0                                ...           3 years ago
  • 2.0.0-beta.1                                ...           3 years ago
  • 1.0.2                                ...           3 years ago
  • 1.0.1                                ...           3 years ago
  • 1.0.0                                ...           3 years ago
  • 0.2.2                                ...           3 years ago
  • 0.2.1                                ...           3 years ago
  • 0.2.0                                ...           3 years ago
  • 0.1.1                                ...           3 years ago
  • 0.1.0                                ...           3 years ago
Maintainers (1)
Downloads
Today 79
This Week 79
This Month 48,802
Last Day 1,185
Last Week 25,861
Last Month 103,873
Dependencies (24)
Dev Dependencies (16)
Dependents (601)

Copyright 2014 - 2016 © taobao.org |