lint-staged

What is lint-staged?

The lint-staged npm package is used to run linters on staged git files. It allows you to run specific commands before committing, ensuring that only clean, linted code gets committed to your repository. This helps in maintaining code quality and reducing the chances of committing code with errors or that doesn't adhere to the project's coding standards.

What are lint-staged's main functionalities?

Running linters on staged files

This configuration in package.json will run ESLint on staged JavaScript files and Stylelint on staged CSS files, automatically fixing any fixable issues.

"lint-staged": {
  "*.js": "eslint --fix",
  "*.css": "stylelint --fix"
}

Running custom scripts

This configuration will run markdownlint-cli2 on staged Markdown files to ensure they meet the project's markdown style requirements.

"lint-staged": {
  "*.md": "npx markdownlint-cli2"
}

Using with pre-commit hooks

This configuration sets up Husky to run lint-staged as a pre-commit hook, ensuring that the linters are run automatically before each commit.

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
}

Other packages similar to lint-staged

pretty-quick

pretty-quick is an npm package that runs Prettier on your changed files. It is similar to lint-staged but is specifically focused on formatting with Prettier rather than running arbitrary linters or tasks.

husky

Husky can be used to manage Git hooks and can run tasks on commit, push, and more. While it doesn't run linters on staged files by itself, it is often used in conjunction with lint-staged to trigger linters before a commit.

lefthook

Lefthook is a fast and powerful Git hooks manager for Node.js, Ruby, or any other type of projects. It can run linters and custom scripts similar to lint-staged, but it also provides additional features like parallel task execution and support for multiple programming languages.

README

lint-staged

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

Why

Read the Medium post

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.

Related blogs posts

• Running Jest Tests Before Each Git Commit

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

Installation & Setup

1. npm install --save-dev lint-staged
2. Install and setup your linters just like you would do normally. Add appropriate .eslintrc and .stylelintrc, etc., configs (see ESLint and Stylelint docs if you need help here).
3. Add { "lint-staged": "lint-staged" } to scripts section of package.json.
4. Add "lint-staged": { "*.js": "eslint" } to package.json (see configuration).
5. npm install --save-dev pre-commit ¹.
6. Add "pre-commit": "lint-staged" to package.json (top level, not the scripts section).

¹ I recommend using pre-commit or husky to manage git hooks but you can use whatever you want.

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

See examples below.

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

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 minimatch for glob patterns.

package.json example:

{
  "scripts": {
    "my-task": "your-command",
  },
  "lint-staged": {
    "*": "my-task"
  }
}

.lintstagedrc example

{
	"*": "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

Advanced config format

To set options and keep lint-staged extensible, advanced format can be used. This should hold linters object in linters property.

Options

• 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 your package.json is located in a sub-directory. See working from a sub-directory
• concurrent — true — runs linters for each glob pattern simultaneously. If you don’t want this, you can set concurrent: false
• verbose — false — runs lint-staged in verbose mode. When true it will use https://github.com/SamVerschueren/listr-verbose-renderer.

Filtering files

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",
}

What commands are supported?

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 auto-formatting tools like eslint --fix or stylefmt but can be used for any arbitrary sequences.

Re-formatting the code

Tools like ESLint or stylefmt can re-format your code according to an appropriate config by running eslint --fix. After the code is re-formatted, 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 git add --patch. This is still not resolved

Working from a sub-directory

If your package.json is located in a sub-directory 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"
    }
}

Examples

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

{
  "name": "My project",
  "version": "0.1.0",
  "scripts": {
    "lint-staged": "lint-staged"
  },
  "pre-commit": "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.

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. Please note, that it doesn’t work well with committing hunks (git add -p).

Stylelint for CSS with defaults and for SCSS with SCSS syntax

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

Automatically fix SCSS style with stylefmt and add to commit

{
	"*.scss": ["stylefmt", "stylelint --syntax scss", "git add"]
}

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

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

Changelog

v3.4.0 - 13 Mar 2017

Features

• Display a message if there are no files that match a pattern. (#139) (b0204ee4, closes #135)