lint-staged vs standard
Which should you use? A side-by-side look at what each one does, who it suits, what it costs, how hard it is to set up, and where each falls short.
Open source · MIT
Runs formatters and linters only on the git files you are about to commit.
Open source · MIT
A JavaScript style guide with a linter and auto-fixer that needs no config files.
The short answer
Choose lint-staged if you need…
- 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
Choose standard if you need…
- JavaScript projects where the team wants consistent style without debating rules
- Node.js developers who want a quick, zero-config check in their package.json test script
- Open source projects that want clear, automated style expectations for contributors
- Developers who want to avoid managing .eslintrc files
Side-by-side
| lint-staged | standard | |
|---|---|---|
| Type | Dev tool | Dev tool |
| Price | Free and open source | Free and open source |
| Licence | MIT | MIT |
| GitHub stars | 14.8k | 29.4k |
| Setup difficulty | Intermediate | Beginner |
| How you get it | Install with a package manager | Install with a package manager |
| Main language | JavaScript | JavaScript |
| Last code update | 5 days ago | 16 months ago |
What each one is
lint-staged
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.
standard
Standard is a JavaScript style guide enforced by a linter, which is a tool that checks code for formatting problems and common programmer mistakes. Running standard --fix will automatically correct many style issues. It is designed so you do not need to write or maintain a configuration file.
Best for
lint-staged
- 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
standard
- JavaScript projects where the team wants consistent style without debating rules
- Node.js developers who want a quick, zero-config check in their package.json test script
- Open source projects that want clear, automated style expectations for contributors
- Developers who want to avoid managing .eslintrc files
Strengths
lint-staged
- 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
standard
- No configuration files to create or maintain
- Automatic fixing via standard --fix saves review time
- Widely used and actively maintained, with about 29,000 GitHub stars and a recent push in July 2025
Not ideal for
lint-staged
- 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
standard
- Teams that want to customize many style rules, since the README stresses there is no configuration (reason: the style is fixed by design)
- Projects that prefer Prettier-style formatting specifically, since the README only compares to Prettier in a linked talk and does not describe it as a replacement (reason: different approach)
- Developers who need the linter to check non-JavaScript languages (reason: it targets JavaScript files by default: **/*.js and **/*.jsx)
Trade-offs
lint-staged
- 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
standard
- Style rules are fixed, so you cannot easily adjust them to personal or team preferences
- Requires Node.js and npm to be installed first
- The README is truncated here, so details on supported syntax and newer language features are unclear
Getting started
lint-staged
Install as a dev dependency
npm install --save-dev lint-stagedstandard
Install globally as a command line program
npm install standard --globalInstall locally for a single project
npm install standard --save-devFrequently asked questions
What is the difference between lint-staged and standard?
lint-staged: Runs formatters and linters only on the git files you are about to commit. standard: A JavaScript style guide with a linter and auto-fixer that needs no config files. lint-staged suits javascript or node.js projects that already use tools like eslint or prettier, while standard suits javascript projects where the team wants consistent style without debating rules.
Are lint-staged and standard free?
lint-staged: Free and open source. standard: Free and open source.
Which is easier to set up, lint-staged or standard?
standard is easier to get started with (rated beginner); lint-staged is rated intermediate and usually needs more setup.
Is lint-staged or standard more popular?
standard has more GitHub stars (29.4k) than lint-staged (14.8k). Popularity isn't the same as fit — check which one matches your use case above.
What are other alternatives to lint-staged and standard?
Other options people compare them with include Husky, pre-commit, ESLint, Prettier, RuboCop.
Keep comparing
Built from our catalogue entries for both products: open-source details come from each project's README (AI-assisted, refreshed weekly) and GitHub data; AI-tool details are editorial. Spotted something wrong? Let us know from either product's page.