lint-staged/lint-staged

lint-staged is a small command-line program for JavaScript projects that runs code-quality tasks like formatters and linters only against the files a developer has staged for the next git commit. The README's pitch is that running tools across an entire project is slow and noisy, while what you actually care about right before committing is just the files about to enter the repository. Lint-staged narrows the scope to those files so the checks finish quickly and complain only about changes you made. The install path described in the README has four steps. First, add the package as a dev dependency with npm install --save-dev lint-staged. Second, set up a pre-commit git hook that calls lint-staged. The README recommends Husky, a popular helper for configuring git hooks, and links to the git documentation. Third, install the tools you want to run, such as ESLint for finding JavaScript problems or Prettier for formatting. Fourth, write a small piece of configuration that maps file patterns to commands, the README's example, {"*.js": "eslint"}, tells lint-staged to run ESLint on every staged JavaScript file. The configuration and Husky setup go into source control so the rest of the team gets the same checks. A sample run is shown near the top. When git commit is invoked, lint-staged first stashes a backup of the original state so any failed task can be undone safely. It then walks the configured patterns, applying prettier --write to staged JSON and Markdown files and eslint --fix to staged JS files, while skipping patterns that have no matching files. After the tasks finish, it updates the git index and cleans up temporary files. The README marks this stash-and-restore behavior as a caution, since lint-staged is modifying the repository on the user's behalf. A long list of command-line flags follows. Notable ones include --allow-empty for cases where the tasks themselves undo all staged changes, --concurrent for controlling whether tasks run in parallel or one at a time, --config for pointing at a non-default config file or even piping config in through standard input, --diff and --diff-filter for overriding which files git reports as staged, --fail-on-changes to make the program exit with a failure when tasks edit tracked files, and --debug for verbose logs that include staged file lists, commands, and binary locations. The README also lists older blog posts and conference talks about lint-staged, points to a separate MIGRATION.md for breaking changes, and mentions a simpler shell-only variant called lint-staged.sh for people who want to check staged files without auto-fixing them. The full README is longer than what was shown.