lint-staged
Advanced tools
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.
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"
}
}
}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 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 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.
Run linters against staged git files and don't let :poop: slip into your code base!
npm install --save-dev lint-staged # requires further setup
$ git commit
✔ Preparing lint-staged...
❯ Running tasks for staged files...
❯ packages/frontend/.lintstagedrc.json — 1 file
↓ *.js — no files [SKIPPED]
❯ *.{json,md} — 1 file
⠹ prettier --write
↓ packages/backend/.lintstagedrc.json — 2 files
❯ *.js — 2 files
⠼ eslint --fix
↓ *.{json,md} — no files [SKIPPED]
◼ Applying modifications from tasks...
◼ Cleaning up temporary files...
Linting makes more sense when run before committing your code. By doing so you can ensure no errors go into the 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 shell tasks with a list of staged files as an argument, filtered by a specified glob pattern.
dotnet-format and lint-stagedIf you've written one, please submit a PR with the link to it!
To install lint-staged in the recommended way, you need to:
npm install --save-dev lint-stagedpre-commit git hook to run lint-staged
{ "*.js": "eslint" } to run ESLint for all staged JS filesDon't forget to commit changes to package.json and .husky to share this setup with your team!
Now change a few files, git add or git add --patch some of them to your commit, and try to git commit them.
See examples and configuration for more information.
See Releases.
v15.0.0 lint-staged no longer supports Node.js 16. Please upgrade your Node.js version to at least 18.12.0.v14.0.0 lint-staged no longer supports Node.js 14. Please upgrade your Node.js version to at least 16.14.0.v13.0.0 lint-staged no longer supports Node.js 12. Please upgrade your Node.js version to at least 14.13.1, or 16.0.0 onward.v13.3.0 was incorrectly released including code of version v14.0.0. This means the breaking changes of v14 are also included in v13.3.0, the last v13 version releasedv12.0.0 lint-staged is a pure ESM module, so make sure your Node.js version is at least 12.20.0, 14.13.1, or 16.0.0. Read more about ESM modules from the official Node.js Documentation site here.v10.0.0 onwards any new modifications to originally staged files will be automatically added to the commit.
If your task previously contained a git add step, please remove this.
The automatic behaviour ensures there are less race-conditions,
since trying to run multiple git operations at the same time usually results in an error.v10.0.0 onwards, lint-staged uses git stashes to improve speed and provide backups while running.
Since git stashes require at least an initial commit, you shouldn't run lint-staged in an empty repo.v10.0.0 onwards, lint-staged requires Node.js version 10.13.0 or later.v10.0.0 onwards, lint-staged will abort the commit if linter tasks undo all staged changes. To allow creating an empty commit, please use the --allow-empty option.❯ npx lint-staged --help
Usage: lint-staged [options]
Options:
-V, --version output the version number
--allow-empty allow empty commits when tasks revert all staged changes (default: false)
-p, --concurrent <number|boolean> the number of tasks to run concurrently, or false for serial (default: true)
-c, --config [path] path to configuration file, or - to read from stdin
--cwd [path] run all tasks in specific directory, instead of the current
-d, --debug print additional debug information (default: false)
--diff [string] override the default "--staged" flag of "git diff" to get list of files. Implies
"--no-stash".
--diff-filter [string] override the default "--diff-filter=ACMR" flag of "git diff" to get list of files
--max-arg-length [number] maximum length of the command-line argument string (default: 0)
--no-stash disable the backup stash, and do not revert in case of errors. Implies
"--no-hide-partially-staged".
--no-hide-partially-staged disable hiding unstaged changes from partially staged files
-q, --quiet disable lint-staged’s own console output (default: false)
-r, --relative pass relative filepaths to tasks (default: false)
-x, --shell [path] skip parsing of tasks for better shell support (default: false)
-v, --verbose show task output even when tasks succeed; by default only failed output is shown
(default: false)
-h, --help display help for command
--allow-empty: By default, when linter tasks undo all staged changes, lint-staged will exit with an error and abort the commit. Use this flag to allow creating empty git commits.--concurrent [number|boolean]: Controls the concurrency of tasks being run by lint-staged. NOTE: This does NOT affect the concurrency of subtasks (they will always be run sequentially). Possible values are:
false: Run all tasks seriallytrue (default) : Infinite concurrency. Runs as many tasks in parallel as possible.{number}: Run the specified number of tasks in parallel, where 1 is equivalent to false.--config [path]: Manually specify a path to a config file or npm package name. Note: when used, lint-staged won't perform the config file search and will print an error if the specified file cannot be found. If '-' is provided as the filename then the config will be read from stdin, allowing piping in the config like cat my-config.json | npx lint-staged --config -.--cwd [path]: By default tasks run in the current working directory. Use the --cwd some/directory to override this. The path can be absolute or relative to the current working directory.--debug: Run in debug mode. When set, it does the following:
$DEBUG to lint-staged*.verbose renderer for listr2; this causes serial, uncoloured output to the terminal, instead of the default (beautified, dynamic) output.
(the verbose renderer can also be activated by setting the TERM=dumb or NODE_ENV=test environment variables)--diff: By default linters are filtered against all files staged in git, generated from git diff --staged. This option allows you to override the --staged flag with arbitrary revisions. For example to get a list of changed files between two branches, use --diff="branch1...branch2". You can also read more from about git diff and gitrevisions. This option also implies --no-stash.--diff-filter: By default only files that are added, copied, modified, or renamed are included. Use this flag to override the default ACMR value with something else: added (A), copied (C), deleted (D), modified (M), renamed (R), type changed (T), unmerged (U), unknown (X), or pairing broken (B). See also the git diff docs for --diff-filter.--max-arg-length: long commands (a lot of files) are automatically split into multiple chunks when it detects the current shell cannot handle them. Use this flag to override the maximum length of the generated command string.--no-stash: By default a backup stash will be created before running the tasks, and all task modifications will be reverted in case of an error. This option will disable creating the stash, and instead leave all modifications in the index when aborting the commit. Can be re-enabled with --stash. This option also implies --no-hide-partially-staged.--no-hide-partially-staged: By default, unstaged changes from partially staged files will be hidden. This option will disable this behavior and include all unstaged changes in partially staged files. Can be re-enabled with --hide-partially-staged--quiet: Supress all CLI output, except from tasks.--relative: Pass filepaths relative to process.cwd() (where lint-staged runs) to tasks. Default is false.--shell: By default linter commands will be parsed for speed and security. This has the side-effect that regular shell scripts might not work as expected. You can skip parsing of commands with this option. To use a specific shell, use a path like --shell "/bin/bash".--verbose: Show task output even when tasks succeed. By default only failed output is shown.Lint-staged can be configured in many ways:
lint-staged object in your package.json, or package.yaml.lintstagedrc file in JSON or YML format, or you can be explicit with the file extension:
.lintstagedrc.json.lintstagedrc.yaml.lintstagedrc.yml.lintstagedrc.mjs or lint-staged.config.mjs file in ESM format
export default { ... }.lintstagedrc.cjs or lint-staged.config.cjs file in CommonJS format
module.exports = { ... }lint-staged.config.js or .lintstagedrc.js in either ESM or CommonJS format, depending on
whether your project's package.json contains the "type": "module" option or not.--config or -c flagConfiguration 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 micromatch for glob patterns. JavaScript files can also export advanced configuration as a function. See Using JS configuration files for more info.
You can also place multiple configuration files in different directories inside a project. For a given staged file, the closest configuration file will always be used. See "How to use lint-staged in a multi-package monorepo?" for more info and an example.
package.json example:{
"lint-staged": {
"*": "your-cmd"
}
}
.lintstagedrc example{
"*": "your-cmd"
}
This config will execute your-cmd 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:
your-cmd file1.ext file2.ext
By default lint-staged will run configured tasks concurrently. This means that for every glob, all the commands will be started at the same time. With the following config, both eslint and prettier will run at the same time:
{
"*.ts": "eslint",
"*.md": "prettier --list-different"
}
This is typically not a problem since the globs do not overlap, and the commands do not make changes to the files, but only report possible errors (aborting the git commit). If you want to run multiple commands for the same set of files, you can use the array syntax to make sure commands are run in order. In the following example, prettier will run for both globs, and in addition eslint will run for *.ts files after it. Both sets of commands (for each glob) are still started at the same time (but do not overlap).
{
"*.ts": ["prettier --list-different", "eslint"],
"*.md": "prettier --list-different"
}
Pay extra attention when the configured globs overlap, and tasks make edits to files. For example, in this configuration prettier and eslint might try to make changes to the same *.ts file at the same time, causing a race condition:
{
"*": "prettier --write",
"*.ts": "eslint --fix"
}
You can solve it using the negation pattern and the array syntax:
{
"!(*.ts)": "prettier --write",
"*.ts": ["eslint --fix", "prettier --write"]
}
Another example in which tasks make edits to files and globs match multiple files but don't overlap:
{
"*.css": ["stylelint --fix", "prettier --write"],
"*.{js,jsx}": ["eslint --fix", "prettier --write"],
"!(*.css|*.js|*.jsx)": ["prettier --write"]
}
Or, if necessary, you can limit the concurrency using --concurrent <number> or disable it entirely with --concurrent false.
Linter commands work on a subset of all staged files, defined by a glob pattern. lint-staged uses micromatch for matching files with the following rules:
/), micromatch's matchBase option will be enabled, so globs match a file's basename regardless of directory:
"*.js" will match all JS files, like /test.js and /foo/bar/test.js"!(*test).js" will match all JS files, except those ending in test.js, so foo.js but not foo.test.js"!(*.css|*.js)" will match all files except CSS and JS files/), it will match for paths as well:
"./*.js" will match all JS files in the git repo root, so /test.js but not /foo/bar/test.js"foo/**/*.js" will match all JS files inside the /foo directory, so /foo/bar/test.js but not /test.jsWhen matching, lint-staged will do the following
NOTE: lint-staged will pass absolute paths to the linters to avoid any confusion in case they're executed in a different working directory (i.e. when your .git directory isn't the same as your package.json directory).
Also see How to use lint-staged in a multi-package monorepo?
The concept of lint-staged is to run configured linter tasks (or other tasks) on files that are staged in git. lint-staged will always pass a list of all staged files to the task, and ignoring any files should be configured in the task itself.
Consider a project that uses prettier to keep code format consistent across all files. The project also stores minified 3rd-party vendor libraries in the vendor/ directory. To keep prettier from throwing errors on these files, the vendor directory should be added to prettier's ignore configuration, the .prettierignore file. Running npx prettier . will ignore the entire vendor directory, throwing no errors. When lint-staged is added to the project and configured to run prettier, all modified and staged files in the vendor directory will be ignored by prettier, even though it receives them as input.
In advanced scenarios, where it is impossible to configure the linter task itself to ignore files, but some staged files should still be ignored by lint-staged, it is possible to filter filepaths before passing them to tasks by using the function syntax. See Example: Ignore files from match.
Supported are 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 uses execa to locate locally installed scripts. 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.
You can run multiple commands in a sequence on every glob. To do so, pass an array of commands instead of a single one. This is useful for running autoformatting tools like eslint --fix or stylefmt but can be used for any arbitrary sequences.
For example:
{
"*.js": ["eslint", "prettier --write"]
}
going to execute eslint and if it exits with 0 code, it will execute prettier --write on all staged *.js files.
Writing the configuration file in JavaScript is the most powerful way to configure lint-staged (lint-staged.config.js, similar, or passed via --config). From the configuration file, you can export either a single function or an object.
If the exports value is a function, it will receive an array of all staged filenames. You can then build your own matchers for the files and return a command string or an array of command strings. These strings are considered complete and should include the filename arguments, if wanted.
If the exports value is an object, its keys should be glob matches (like in the normal non-js config format). The values can either be like in the normal config or individual functions like described above. Instead of receiving all matched files, the functions in the exported object will only receive the staged files matching the corresponding glob key.
The function can also be async:
(filenames: string[]) => string | string[] | Promise<string | string[]>
// lint-staged.config.js
import micromatch from 'micromatch'
export default (allStagedFiles) => {
const shFiles = micromatch(allStagedFiles, ['**/src/**/*.sh'])
if (shFiles.length) {
return `printf '%s\n' "Script files aren't allowed in src directory" >&2`
}
const codeFiles = micromatch(allStagedFiles, ['**/*.js', '**/*.ts'])
const docFiles = micromatch(allStagedFiles, ['**/*.md'])
return [`eslint ${codeFiles.join(' ')}`, `mdl ${docFiles.join(' ')}`]
}
// .lintstagedrc.js
export default {
'**/*.js?(x)': (filenames) => filenames.map((filename) => `prettier --write '${filename}'`),
}
tsc on changes to TypeScript files, but do not pass any filename arguments// lint-staged.config.js
export default {
'**/*.ts?(x)': () => 'tsc -p tsconfig.json --noEmit',
}
// .lintstagedrc.js
export default {
'**/*.js?(x)': (filenames) =>
filenames.length > 10 ? 'eslint .' : `eslint ${filenames.join(' ')}`,
}
It's better to use the function-based configuration (seen above), if your use case is this.
// lint-staged.config.js
import micromatch from 'micromatch'
export default {
'*': (allFiles) => {
const codeFiles = micromatch(allFiles, ['**/*.js', '**/*.ts'])
const docFiles = micromatch(allFiles, ['**/*.md'])
return [`eslint ${codeFiles.join(' ')}`, `mdl ${docFiles.join(' ')}`]
},
}
If for some reason you want to ignore files from the glob match, you can use micromatch.not():
// lint-staged.config.js
import micromatch from 'micromatch'
export default {
'*.js': (files) => {
// from `files` filter those _NOT_ matching `*test.js`
const match = micromatch.not(files, '*test.js')
return `eslint ${match.join(' ')}`
},
}
Please note that for most cases, globs can achieve the same effect. For the above example, a matching glob would be !(*test).js.
import path from 'path'
export default {
'*.ts': (absolutePaths) => {
const cwd = process.cwd()
const relativePaths = absolutePaths.map((file) => path.relative(cwd, file))
return `ng lint myProjectName --files ${relativePaths.join(' ')}`
},
}
Tools like Prettier, ESLint/TSLint, or stylelint can reformat your code according to an appropriate config by running prettier --write/eslint --fix/tslint --fix/stylelint --fix. Lint-staged will automatically add any modifications to the commit as long as there are no errors.
{
"*.js": "prettier --write"
}
Prior to version 10, tasks had to manually include git add as the final step. This behavior has been integrated into lint-staged itself in order to prevent race conditions with multiple tasks editing the same files. If lint-staged detects git add in task configurations, it will show a warning in the console. Please remove git add from your configuration after upgrading.
All examples assume you've already set up lint-staged in the package.json file and husky in its own config file.
{
"name": "My project",
"version": "0.1.0",
"scripts": {
"my-custom-script": "linter --arg1 --arg2"
},
"lint-staged": {}
}
In .husky/pre-commit
# .husky/pre-commit
npx 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.
*.js and *.jsx running as a pre-commit hook{
"*.{js,jsx}": "eslint"
}
--fix and add to commit{
"*.js": "eslint --fix"
}
This will run eslint --fix and automatically add changes to the commit.
If you wish to reuse a npm script defined in your package.json:
{
"*.js": "npm run my-custom-script --"
}
The following is equivalent:
{
"*.js": "linter --arg1 --arg2"
}
Linting commands do not support the shell convention of expanding environment variables. To enable the convention yourself, use a tool like cross-env.
For example, here is jest running on all .js files with the NODE_ENV variable being set to "test":
{
"*.js": ["cross-env NODE_ENV=test jest --bail --findRelatedTests"]
}
prettier for any format Prettier supports{
"*": "prettier --ignore-unknown --write"
}
prettier for JavaScript, TypeScript, Markdown, HTML, or CSS{
"*.{js,jsx,ts,tsx,md,html,css}": "prettier --write"
}
{
"*.css": "stylelint",
"*.scss": "stylelint --syntax=scss"
}
{
"*.scss": ["postcss --config path/to/your/config --replace", "stylelint"]
}
{
"*.{png,jpeg,jpg,gif,svg}": "imagemin-lint-staged"
}
imagemin-lint-stagedimagemin-lint-staged is a CLI tool designed for lint-staged usage with sensible defaults.
See more on this blog post for benefits of this approach.
{
"*.{js,jsx}": "flow focus-check"
}
// .lintstagedrc.js
// See https://nextjs.org/docs/basic-features/eslint#lint-staged for details
const path = require('path')
const buildEslintCommand = (filenames) =>
`next lint --fix --file ${filenames.map((f) => path.relative(process.cwd(), f)).join(' --file ')}`
module.exports = {
'*.{js,jsx,ts,tsx}': [buildEslintCommand],
}
Git 2.36.0 introduced a change to hooks where they were no longer run in the original TTY. This was fixed in 2.37.0:
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.37.0.txt
- In Git 2.36 we revamped the way how hooks are invoked. One change that is end-user visible is that the output of a hook is no longer directly connected to the standard output of "git" that spawns the hook, which was noticed post release. This is getting corrected. (merge a082345372 ab/hooks-regression-fix later to maint).
If updating Git doesn't help, you can try to manually redirect the output in your Git hook; for example:
# .husky/pre-commit
if sh -c ": >/dev/tty" >/dev/null 2>/dev/null; then exec >/dev/tty 2>&1; fi
npx lint-staged
Source: https://github.com/typicode/husky/issues/968#issuecomment-1176848345
lint-staged via node?Yes!
import lintStaged from 'lint-staged'
try {
const success = await lintStaged()
console.log(success ? 'Linting was successful!' : 'Linting failed!')
} catch (e) {
// Failed to load configuration
console.error(e)
}
Parameters to lintStaged are equivalent to their CLI counterparts:
const success = await lintStaged({
allowEmpty: false,
concurrent: true,
configPath: './path/to/configuration/file',
cwd: process.cwd(),
debug: false,
maxArgLength: null,
quiet: false,
relative: false,
shell: false,
stash: true,
verbose: false,
})
You can also pass config directly with config option:
const success = await lintStaged({
allowEmpty: false,
concurrent: true,
config: { '*.js': 'eslint --fix' },
cwd: process.cwd(),
debug: false,
maxArgLength: null,
quiet: false,
relative: false,
shell: false,
stash: true,
verbose: false,
})
The maxArgLength option configures chunking of tasks into multiple parts that are run one after the other. This is to avoid issues on Windows platforms where the maximum length of the command line argument string is limited to 8192 characters. Lint-staged might generate a very long argument string when there are many staged files. This option is set automatically from the cli, but not via the Node.js API by default.
Update: The latest version of JetBrains IDEs now support running hooks as you would expect.
When using the IDE's GUI to commit changes with the precommit hook, you might see inconsistencies in the IDE and command line. This is known issue at JetBrains so if you want this fixed, please vote for it on YouTrack.
Until the issue is resolved in the IDE, you can use the following config to work around it:
husky v1.x
{
"husky": {
"hooks": {
"pre-commit": "lint-staged",
"post-commit": "git update-index --again"
}
}
}
husky v0.x
{
"scripts": {
"precommit": "lint-staged",
"postcommit": "git update-index --again"
}
}
Thanks to this comment for the fix!
lint-staged in a multi-package monorepo?Install lint-staged on the monorepo root level, and add separate configuration files in each package. When running, lint-staged will always use the configuration closest to a staged file, so having separate configuration files makes sure linters do not "leak" into other packages.
For example, in a monorepo with packages/frontend/.lintstagedrc.json and packages/backend/.lintstagedrc.json, a staged file inside packages/frontend/ will only match that configuration, and not the one in packages/backend/.
Note: lint-staged discovers the closest configuration to each staged file, even if that configuration doesn't include any matching globs. Given these example configurations:
// ./.lintstagedrc.json
{ "*.md": "prettier --write" }
// ./packages/frontend/.lintstagedrc.json
{ "*.js": "eslint --fix" }
When committing ./packages/frontend/README.md, it will not run prettier, because the configuration in the frontend/ directory is closer to the file and doesn't include it. You should treat all lint-staged configuration files as isolated and separated from each other. You can always use JS files to "extend" configurations, for example:
import baseConfig from '../.lintstagedrc.js'
export default {
...baseConfig,
'*.js': 'eslint --fix',
}
To support backwards-compatibility, monorepo features require multiple lint-staged configuration files present in the git repo. If you still want to run lint-staged in only one of the packages in a monorepo, you can either add an "empty" lint-staged configuration to the root of the repo (so that there's two configs in total), or alternatively run lint-staged with the --cwd option pointing to your package directory (for example, lint-staged --cwd packages/frontend).
tl;dr: Yes, but the pattern should start with ../.
By default, lint-staged executes linters only on the files present inside the project folder(where lint-staged is installed and run from).
So this question is relevant only when the project folder is a child folder inside the git repo.
In certain project setups, it might be desirable to bypass this restriction. See #425, #487 for more context.
lint-staged provides an escape hatch for the same(>= v7.3.0). For patterns that start with ../, all the staged files are allowed to match against the pattern.
Note that patterns like *.js, **/*.js will still only match the project files and not any of the files in parent or sibling directories.
Example repo: sudo-suhas/lint-staged-django-react-demo.
lint-staged in CI, or when there are no staged files?Lint-staged will by default run against files staged in git, and should be run during the git pre-commit hook, for example. It's also possible to override this default behaviour and run against files in a specific diff, for example all changed files between two different branches. If you want to run lint-staged in the CI, maybe you can set it up to compare the branch in a Pull Request/Merge Request to the target branch.
Try out the git diff command until you are satisfied with the result, for example:
git diff --diff-filter=ACMR --name-only master...my-branch
This will print a list of added, changed, modified, and renamed files between master and my-branch.
You can then run lint-staged against the same files with:
npx lint-staged --diff="master...my-branch"
lint-staged with ng lintYou should not use ng lint through lint-staged, because it's designed to lint an entire project. Instead, you can add ng lint to your git pre-commit hook the same way as you would run lint-staged.
See issue !951 for more details and possible workarounds.
.eslintignore?ESLint throws out warning File ignored because of a matching ignore pattern. Use "--no-ignore" to override warnings that breaks the linting process ( if you used --max-warnings=0 which is recommended ).
Based on the discussion from this issue, it was decided that using the outlined scriptis the best route to fix this.
So you can setup a .lintstagedrc.js config file to do this:
import { CLIEngine } from 'eslint'
export default {
'*.js': (files) => {
const cli = new CLIEngine({})
return 'eslint --max-warnings=0 ' + files.filter((file) => !cli.isPathIgnored(file)).join(' ')
},
}
In versions of ESLint > 7, isPathIgnored is an async function and now returns a promise. The code below can be used to reinstate the above functionality.
Since 10.5.3, any errors due to a bad ESLint config will come through to the console.
import { ESLint } from 'eslint'
const removeIgnoredFiles = async (files) => {
const eslint = new ESLint()
const isIgnored = await Promise.all(
files.map((file) => {
return eslint.isPathIgnored(file)
})
)
const filteredFiles = files.filter((_, i) => !isIgnored[i])
return filteredFiles.join(' ')
}
export default {
'**/*.{ts,tsx,js,jsx}': async (files) => {
const filesToLint = await removeIgnoredFiles(files)
return [`eslint --max-warnings=0 ${filesToLint}`]
},
}
ESLint v8.51.0 introduced --no-warn-ignored CLI flag. It suppresses the warning File ignored because of a matching ignore pattern. Use "--no-ignore" to override warning, so manually ignoring files via eslint.isPathIgnored is no longer necessary.
{
"*.js": "eslint --max-warnings=0 --no-warn-ignored"
}
NOTE: --no-warn-ignored flag is only available when Flat ESLint config is used.
15.2.8
f0480f0 Thanks @iiroj! - In the previous version the native git rev-parse --show-toplevel command was taken into use for resolving the current git repo root. This version switched the --show-toplevel flag with --show-cdup, because on Git installed via MSYS2 the former was returning absolute paths that do not work with Node.js child_process. The new flag returns a path relative to the working directory, avoiding the issue.
The GitHub Actions workflow has been updated to install Git via MSYS2, to ensure better future compatibility; using the default Git binary in the GitHub Actions runner was working correctly even with MSYS2.
FAQs
Lint files staged by git
The npm package lint-staged receives a total of 7,593,532 weekly downloads. As such, lint-staged popularity was classified as popular.
We found that lint-staged demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.
Security News
Research
Attackers are impersonating Sindre Sorhus on npm with a fake 'chalk-node' package containing a malicious backdoor to compromise developers' projects.
Security News
The npm package for the LottieFiles Player web component was hit with a supply chain attack after a software engineer's npmjs credentials were compromised.