![Understanding the Security Concerns of npm Shrinkwrap](https://cdn.sanity.io/images/cgdhsj6q/production/37156cfb4523f411022d98b3b06138985ac81496-1024x1024.webp?w=400&fit=max&auto=format)
Security News
Understanding the Security Concerns of npm Shrinkwrap
Explore the security risks of using npm shrinkwrap, the potential for outdated dependencies, and best practices for mitigating these concerns in your projects.
lint-staged
Advanced tools
Package description
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.
Readme
Run linters against staged git files and don't let :poop: slip into your code base!
lint-staged@beta
!Version 10 of lint-staged
is coming with changes that help it run faster on large git repositories and prevent loss of data during errors. Please help test the beta
version and report any inconsistencies in our GitHub Issues:
Using npm
npm install --save-dev lint-staged@beta
Using yarn
yarn add -D lint-staged@beta
lint-staged@beta
uses git stashes to hide unstaged changes while running tasks against staged files
prettier --write && git add
) is different. The current version creates a diff of these modifications, and applies it against the original state, silently ignoring any errors. The beta
version leaves modifications of staged files as-is, and then restores all hidden unstaged changes as patch. If applying the patch fails due to a merge conflict (because tasks have modified the same lines), a 3-way merge will be retried. If this also fails, the entire commit will fail and the original state will be restored.
beta
version will never skip committing any changes by tasks (due to a merge conflict), but might fail in very complex situations where unstaged changes cannot be restored cleanly. If this happens to you, we are very interested in a repeatable test scenario.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.
If you've written one, please submit a PR with the link to it!
The fastest way to start using lint-staged is to run following command in your terminal:
npx mrm lint-staged
It will install and configure husky and lint-staged depending on code quality tools from package.json
dependencies so please make sure you install (npm install --save-dev
) and configure all code quality tools like Prettier, ESlint prior that.
Don't forget to commit changes to package.json
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
$ npx lint-staged --help
Usage: lint-staged [options]
Options:
-V, --version output the version number
-c, --config [path] Path to configuration file
-r, --relative Pass relative filepaths to tasks
-x, --shell Skip parsing of tasks for better shell support
-q, --quiet Disable lint-staged’s own console output
-d, --debug Enable debug mode
-p, --concurrent [parallel tasks] The number of tasks to run concurrently, or false to run tasks sequentially
-h, --help output usage information
--config [path]
: This can be used to manually specify the lint-staged
config file location. However, if the specified file cannot be found, it will error out instead of performing the usual search. You may pass a npm package name for configuration also.--relative
: By default filepaths will be passed to the linter tasks as absolute. This flag makes them relative to process.cwd()
(where lint-staged
runs).--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.--quiet
: By default lint-staged
will print progress status to console while running linters. Use this flag to supress all output, except for linter scripts.--debug
: Enabling the debug mode does the following:
lint-staged
uses the debug module internally to log information about staged files, commands being executed, location of binaries, etc. Debug logs, which are automatically enabled by passing the flag, can also be enabled by setting the environment variable $DEBUG
to lint-staged*
.verbose
renderer for listr
.--concurrent [number | (true/false)]
: 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
.Starting with v3.1 you can now use different ways of configuring it:
lint-staged
object in your package.json
.lintstagedrc
file in JSON or YML formatlint-staged.config.js
file in JS format--config
or -c
flagSee cosmiconfig for more details on what formats are supported.
Configuration 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.
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
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 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
/
), 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.js
When 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 (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.
Starting from v2.0.0 sequences of commands are supported. Pass an array of commands instead of a single one and they will run sequentially. This is useful for running autoformatting tools like eslint --fix
or stylefmt
but can be used for any arbitrary sequences.
When supplying configuration in JS format it is possible to define the linter command as a function which receives an array of staged filenames/paths and returns the complete linter command as a string. It is also possible to return an array of complete command strings, for example when the linter command supports only a single file input.
type LinterFn = (filenames: string[]) => string | string[]
// .lintstagedrc.js
module.exports = {
'**/*.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
module.exports = {
'**/*.ts?(x)': () => 'tsc -p tsconfig.json --noEmit'
}
// .lintstagedrc.js
module.exports = {
'**/*.js?(x)': filenames => (filenames.length > 10 ? 'eslint .' : `eslint ${filenames.join(' ')}`)
}
// lint-staged.config.js
const micromatch = require('micromatch')
module.exports = {
'*': allFiles => {
const match = micromatch(allFiles, ['*.js', '*.ts'])
return match.map(file => `eslint ${file}`)
}
}
If for some reason you want to ignore files from the glob match, you can use micromatch.not()
:
// lint-staged.config.js
const micromatch = require('micromatch')
module.exports = {
'*.js': files => {
// from `files` filter those _NOT_ matching `*test.js`
const match = micromatch.not(files, '*test.js')
return match.map(file => `eslint ${file}`)
}
}
Please note that for most cases, globs can achieve the same effect. For the above example, a matching glob would be !(*test).js
.
const path = require('path')
module.exports = {
'*.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
. After the code is reformatted, we want it to be added to the same commit. This can be done using following config:
{
"*.js": ["prettier --write", "git add"]
}
Starting from v8, lint-staged will stash your remaining changes (not added to the index) and restore them from stash afterwards if there are partially staged files detected. This allows you to create partial commits with hunks using git add --patch
. See the blog post
All examples assuming you’ve already set up lint-staged and husky in the package.json
.
{
"name": "My project",
"version": "0.1.0",
"scripts": {
"my-custom-script": "linter --arg1 --arg2"
},
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"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", "git add"]
}
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 --", "git add"]
}
The following is equivalent:
{
"*.js": ["linter --arg1 --arg2", "git add"]
}
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 javascript + flow, typescript, markdown or html{
"*.{js,jsx}": ["prettier --write", "git add"]
}
{
"*.{ts,tsx}": ["prettier --write", "git add"]
}
{
"*.{md,html}": ["prettier --write", "git add"]
}
{
"*.css": "stylelint",
"*.scss": "stylelint --syntax=scss"
}
{
"*.scss": ["postcss --config path/to/your/config --replace", "stylelint", "git add"]
}
{
"*.{png,jpeg,jpg,gif,svg}": ["imagemin-lint-staged", "git add"]
}
imagemin-lint-staged
imagemin-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", "git add"]
}
lint-staged
via node?Yes!
const lintStaged = require('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({
configPath: './path/to/configuration/file',
shell: false,
quiet: false,
debug: false
})
You can also pass config directly with config
option:
const success = await lintStaged({
config: {
'*.js': 'eslint --fix'
},
shell: false,
quiet: false,
debug: false
})
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?Starting with v5.0, lint-staged
automatically resolves the git root without any additional configuration. You configure lint-staged
as you normally would if your project root and git root were the same directory.
If you wish to use lint-staged
in a multi package monorepo, it is recommended to install husky
in the root package.json.
lerna
can be used to execute the precommit
script in all sub-packages.
Example repo: sudo-suhas/lint-staged-multi-pkg.
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.
FAQs
Lint files staged by git
The npm package lint-staged receives a total of 8,773,911 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 1 open source maintainer 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
Explore the security risks of using npm shrinkwrap, the potential for outdated dependencies, and best practices for mitigating these concerns in your projects.
Security News
Node.js is taking steps towards removing Corepack from its distribution, aiming for changes in the next major release.
Security News
OpenSSF has released a guide to help package repositories adopt Trusted Publishers, which enhances security by using short-lived identity tokens for authentication, reducing the risks associated with long-lived secrets.