lint-staged
Runs formatters and linters only on the git files you are about to commit.
- Stars
- 14.8k
- Forks
- 479
- Licence
- MIT
- Language
- JavaScript
- Last update
- 6 days ago
- Type
- Dev tool
What it is
lint-staged is a JavaScript tool that runs tasks such as formatters and linters against the files staged in git. It is typically hooked into the pre-commit step so that problems in those files are caught before the commit is made. The README says this avoids the slowness of checking a whole project and the noise of checking files you are not committing.
- Run Prettier on staged JSON and Markdown files before each commit
- Run ESLint on staged JavaScript files before they enter the repository
- Run Stylelint on staged stylesheet files
- Use --all in CI to run tasks across all tracked files
Great for
- JavaScript or Node.js projects that already use tools like ESLint or Prettier
- Teams that want consistent code style enforced at commit time
- Developers who want fast pre-commit checks limited to changed files
- Projects using git hooks, such as through Husky
Not ideal for
- Projects that do not use git, since the tool works on staged git files
- People who only want to check files without automatic edits; the README points to lint-staged.sh as a simpler alternative for that case
- Teams unwilling to set up git hooks and config, since the README says extra setup is required
How to get it
- 1
Install with a package manager
You'll need: Node.js · npm · git
Install as a dev dependency
npm install --save-dev lint-staged - 2
Run it
- Install lint-staged with npm install --save-dev lint-staged.
- Set up a pre-commit git hook to run lint-staged, for example with Husky, as the README suggests.
- Add a configuration such as { "*.js": "eslint" } to package.json.
- Stage some files with git add and run git commit to see the tasks run.
- 3
Get the most out of it
- Use the --concurrent flag to control how many tasks run in parallel
- Use --continue-on-error to run all tasks even if one fails
- Use --verbose to see task output even when tasks succeed
- Use --relative if your tasks need relative file paths
Downloads
Strengths
- Only checks files that are about to be committed, so it stays quick on large projects
- Configuration is a small mapping from file patterns to commands
- Widely used, with about 14.7k GitHub stars and an MIT license
Trade-offs
- The README says it needs further setup before it does anything useful after installation
- By default it creates a git stash backup, and the README warns that git operations affect your repository
- Behavior depends on the tools you configure, so results vary by project
How it compares
| Project | Stars | Type | Level | Updated | Best for |
|---|---|---|---|---|---|
| lint-staged (this) | 14.8k | Dev tool | intermediate | 6 days ago | JavaScript or Node.js projects that already use tools like ESLint or Prettier |
| husky | 35.4k | Dev tool | beginner | 8 months ago | JavaScript or Node.js projects that want shared pre-commit checks |
| pre-commit | 15.7k | Dev tool | intermediate | 17 days ago | Teams that want consistent code checks run on every commit |
| standard | 29.4k | Dev tool | beginner | 1.3 years ago | JavaScript projects where the team wants consistent style without debating rules |
| eslint | 27.6k | Dev tool | intermediate | 4 days ago | JavaScript developers who want automatic checks on their code |
| front-end-guide | 15.2k | Learning resource | beginner | 3.4 years ago | Back end engineers joining a team that works on web apps |
Stats synced from GitHub. The assessment above was drafted with AI from the project's README on 2026-10-29 and may miss recent changes — check the README before relying on a command. MIT licence: free to use, modify and distribute, including commercially, as long as you keep the copyright notice.