Why run linters only on staged files instead of the whole project?

lint-staged passes each command only the file paths that are actually staged for commit, so a pre-commit hook stays fast (seconds, not minutes) even on a large codebase, and a commit isn't blocked by pre-existing lint issues in files you didn't touch.

What's the difference between the .lintstagedrc.json and package.json output?

Both are read identically by the lint-staged CLI; .lintstagedrc.json is a separate file some teams prefer to keep config files out of package.json, while the package.json block adds a top-level "lint-staged" key to the manifest you already have, keeping fewer files at the project root.

Why is each glob mapped to an array of commands instead of one?

lint-staged runs every command in the array, in order, against the matched staged files, letting you chain multiple checks (e.g. eslint --fix then prettier --write) on the same file set within one glob entry.

How does this interact with a Husky pre-commit hook?

This config alone does nothing until something invokes the `lint-staged` (or `npx lint-staged`) command; the Husky Config Generator's pre-commit hook is exactly that trigger.

lint-staged Config Generator - .lintstagedrc.json Builder

Overview

Introduction

Running a full ESLint or Prettier pass on every commit gets slow as a codebase grows, and lint-staged solves this by only running commands against the files that are actually staged, but its glob-to-commands mapping needs to be assembled correctly per file type.

This tool generates a valid lint-staged config, either as its own .lintstagedrc.json or as a package.json block, from simple glob-pattern-to-command rows.

What Is lint-staged Config Generator?

A lint-staged config generator mapping glob patterns (like *.{js,ts,tsx}) to arrays of commands (eslint --fix, prettier --write, a targeted test command) that run only against matching staged files.

Output is chosen between a standalone .lintstagedrc.json file or a package.json "lint-staged" block, both read identically by the lint-staged CLI.

How lint-staged Config Generator Works

Each glob row you fill in becomes a key in the config object, mapped to an array built from that row's non-empty command entries, and rows with an empty glob or no commands are dropped before serialization.

The resulting object is serialized as formatted JSON, either standalone (.lintstagedrc.json) or nested one level under a top-level "lint-staged" key (package.json block), depending on your output target choice.

When To Use lint-staged Config Generator

Use it when setting up lint-staged for the first time and you want to run ESLint and Prettier (and maybe a test command) only against staged files in a pre-commit hook.

It's also useful for adding a new file-type rule (say, a *.css glob running stylelint) to an existing lint-staged setup without hand-editing JSON.

Often used alongside Husky Git Hooks Generator, ESLint Flat Config Generator and Prettier Config Generator.

Features

Advantages

Supports chaining multiple commands per glob, so a single file type (e.g. *.ts) can run both eslint --fix and prettier --write in one pass.
Lets you choose between a standalone .lintstagedrc.json and a package.json block depending on your team's file-organization preference.
Drops incomplete rows (empty glob or no commands) automatically, so a half-filled form never produces an invalid or empty config entry.

Limitations

Doesn't validate that the glob patterns are syntactically meaningful beyond checking they're non-empty; a typo'd glob will still be accepted.
Doesn't wire itself into a git hook; it needs to be invoked by something, typically a Husky pre-commit hook running `npx lint-staged`.

Examples

ESLint + Prettier on TS/TSX, Prettier only on JSON/Markdown

Input

rules: [{glob: "*.{ts,tsx}", commands: ["eslint --fix", "prettier --write"]}, {glob: "*.{json,md}", commands: ["prettier --write"]}]

Output

{
  "*.{ts,tsx}": [
    "eslint --fix",
    "prettier --write"
  ],
  "*.{json,md}": [
    "prettier --write"
  ]
}

Best Practices & Notes

Best Practices

Run eslint --fix before prettier --write in the same command array, so ESLint's auto-fixes are applied before Prettier does its final formatting pass.
Scope test commands narrowly (e.g. a command that only runs tests related to changed files) rather than a full test suite, to keep pre-commit hooks fast.
Keep lint-staged's rules and your ESLint/Prettier configs' own file-type coverage in sync, so lint-staged doesn't silently skip a file type your linters otherwise cover.

Developer Notes

lint-staged internally uses micromatch for glob matching against the list of staged files reported by git, and runs each glob's command array sequentially against just those matched paths (passed as CLI arguments), not the whole working tree; this is what keeps pre-commit runs proportional to what actually changed rather than the size of the whole project. Both the .lintstagedrc.json and package.json "lint-staged" output shapes are read by the same lint-staged config-loading logic (cosmiconfig), so there's no functional difference beyond file location.

lint-staged Config Generator Use Cases

Setting up fast, staged-file-only linting and formatting in a pre-commit hook
Adding a new file-type rule (e.g. stylelint for CSS) to an existing lint-staged setup
Choosing between a standalone .lintstagedrc.json and a package.json block based on team file-organization preference

Common Mistakes

Running a full-project lint or test command inside lint-staged instead of one scoped to staged files, defeating the performance benefit lint-staged is meant to provide.
Forgetting that lint-staged's commands run against staged files as CLI arguments, so a command that ignores its arguments (and just runs against the whole project) won't behave as expected.

Tips

Use the Husky Config Generator to add a pre-commit hook running `npx lint-staged`, since this config alone doesn't trigger anything without a hook invoking it.

lint-staged Config Generator