Run linters against staged git files and don't let 💩 slip into your code base!
Linting makes more sense when running before committing your code. By doing that you can ensure no errors are going into 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 npm and shell tasks with a list of staged files as an argument, filtered by a specified glob pattern.
If you've written one, please submit a PR with the link to it!
npm install --save-dev lint-staged husky
- Install and setup your linters just like you would do normally. Add appropriate
.eslintrc
,.stylelintrc
, etc. - Update your
package.json
like this:
{
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"*.js": ["eslint --fix", "git add"]
}
}
Now change a few files, git add
some of them to your commit and try to git commit
them.
See examples and configuration below.
I recommend using husky to manage git hooks but you can use any other tool.
Starting with v3.1 you can now use different ways of configuring it:
lint-staged
object in yourpackage.json
.lintstagedrc
file in JSON or YML formatlint-staged.config.js
file in JS format
See cosmiconfig for more details on what formats are supported.
Lint-staged supports simple and advanced config formats.
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 minimatch for glob patterns.
{
"scripts": {
"my-task": "your-command",
},
"lint-staged": {
"*": "my-task"
}
}
{
"*": "my-task"
}
This config will execute npm run my-task
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:
npm run my-task -- file1.ext file2.ext
To set options and keep lint-staged extensible, advanced format can be used. This should hold linters object in linters
property.
linters
—Object
— keys (String
) are glob patterns, values (Array<String> | String
) are commands to execute.gitDir
— Sets the relative path to the.git
root. Useful when yourpackage.json
is located in a subdirectory. See working from a subdirectoryconcurrent
— true — runs linters for each glob pattern simultaneously. If you don’t want this, you can setconcurrent: false
verbose
— false — runs lint-staged in verbose mode. Whentrue
it will use https://github.com/SamVerschueren/listr-verbose-renderer.
It is possible to run linters for certain paths only by using minimatch patterns. The paths used for filtering via minimatch are relative to the directory that contains the .git
directory. The paths passed to the linters are absolute to avoid confusion in case they're executed with a different working directory, as would be the case when using the gitDir
option.
{
// .js files anywhere in 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",
}
Supported are both local npm scripts (npm run-script
), or 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 you don't need to add { "eslint": "eslint" }
to the scripts
section of your package.json
. 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.
Tools like ESLint or stylefmt can reformat your code according to an appropriate config by running eslint --fix
. After the code is reformatted, we want it to be added to the same commit. This can be done using following config:
{
"*.js": ["eslint --fix", "git add"]
}
Starting from v3.1, lint-staged will stash you remaining changes (not added to the index) and restore them from stash afterwards. This allows you to create partial commits with hunks using This is still not resolvedgit add --patch
.
If your package.json
is located in a subdirectory of the git root directory, you can use gitDir
relative path to point there in order to make lint-staged work.
{
"gitDir": "../",
"linters":{
"*": "my-task"
}
}
All examples assuming you’ve already set up lint-staged and husky in the package.json
.
{
"name": "My project",
"version": "0.1.0",
"scripts": {
"precommit": "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. Please don’t reuse your tasks with paths from package.json.
{
"*.{js,jsx}": "eslint"
}
{
"*.js": ["eslint --fix", "git add"]
}
This will run eslint --fix
and automatically add changes to the commit. Please note, that it doesn’t work well with committing hunks (git add -p
).
{
"*.css": "stylelint",
"*.scss": "stylelint --syntax=scss"
}
{
"*.scss": ["stylefmt", "stylelint --syntax scss", "git add"]
}
{
"*.scss": [
"postcss --config path/to/your/config --replace",
"stylelint",
"git add"
]
}