An easy way to improve code quality is linting code for formatting issues, syntax typos and inconsistencies. For example, you may have accidentally left a 

 statement that prints environment variables during development. Or you may have forgotten a semi-colon during a quick bug fix. Regardless, identifying and resolving these mistakes not only reduces the amount of time and resources spent on quality assurance and control, but also reassures developers of the code's functionality.

 for CSS/SCSS/Sass/Less/SugarSS. While coding, you may have the linting tool running in watch mode within a terminal to monitor and report errors and warnings whenever you edit and save a file. This can become quite distracting, especially if you are focused more on adding new features to the application code before a tight deadline and you cannot afford to switch back-and-forth between the terminal and code editor. 

Suppose you correct a problem and later on, you decide to scrap the code that you just fixed. Unfortunately, you wasted time on fixing a non-existent problem. Ideally, you should run the linter after you finish coding, but you may forget to run the linter and immediately commit the changes (with the mistakes).

 automatically runs the linter against files staged for commit. This lets you continue working on the application code without any interruptions, and once you are done with the code, you can stage the modified files and run the linter before committing them. You can configure 

 to run a specific linter command against files that match a glob pattern. For JavaScript files (

), you may select ESLint as the linter to run against those files. For CSS files (

), you may select stylelint as the linter to run against those files. 

If any files fail to pass, then they are not committed to the remote repository! Before the files can be committed, you must first resolve the errors raised by the linter. For projects with many contributors, linting enforces the project's coding conventions despite each contributor having their own set of opinions and conventions.

Below, I'm going to show you how to integrate 

 lints all files, not just staged files. As your project grows, linting every file, even those that have not been recently modified and previously passed all the linting rules, becomes inefficient and increases development time from redundant linting. 

 Git hook. Nevertheless, each library allows you to run any number of custom scripts defined in 

, is invoked by an event, such as executing the 

To get started, check that your project already has ESLint, stylelint or Prettier configured (either via a 

). Otherwise, the following error message is shown during the installation of 

Cannot add lint-staged: only eslint, stylelint, prettier or custom rules are supported.

, run the following command within the root directory of your project:

 is a command line tool for automating and managing project configurations.

If you are prompted with the following message, then press 

Need to install the following packages:
  mrm@2
Ok to proceed? (y)

{
  "lint-staged": {
    "*.js": "eslint --cache --fix"
  }
}

Anytime a JavaScript file is staged for a commit, 

 tells ESLint to only check changed files, and 

 tells ESLint to automatically fix problems when possible.

 property is added to the `lint-staged object.

{
  "lint-staged": {
    "*.{js,css,md}": "prettier --write"
  }
}

Anytime a JavaScript, CSS or Markdown file is staged for a commit, 

 runs Prettier to properly format the contents of the files. This ensures the files are formatted, even if a contributor does not have the Prettier plugin installed on their IDE to automatically format the files when saved. 

Suppose you want the staged JavaScript files to pass unit tests written with the 

. Adding a new script is relatively straight-forward. Just update the value of the 

 key to an array that contains a list of scripts to run against the staged JavaScript files. 

 option allows the test suite to pass even if there are no test files present and you plan to add unit tests in the future.

These scripts run in sequence from the first listed item to the last listed item. If a single command fails, then the entire commit is rejected.

 to your own JavaScript libraries. You can also check out our new course, 

The newline Guide to Creating React Libraries from Scratch

where we teach you everything you need to know to succeed in creating a library. 

<h1 data-node-type="titlePlaceholder" class="titlePlaceholder">Linting Staged Git Files with <code>lint-staged</code></h1><p>An easy way to improve code quality is linting code for formatting issues, syntax typos and inconsistencies. For example, you may have accidentally left a <code>console.log</code> statement that prints environment variables during development. Or you may have forgotten a semi-colon during a quick bug fix. Regardless, identifying and resolving these mistakes not only reduces the amount of time and resources spent on quality assurance and control, but also reassures developers of the code's functionality.</p><p>Popular linting tools include <a href="https://eslint.org/" rel="noopener noreferrer nofollow">ESLint</a> for JavaScript/TypeScript and <a href="https://stylelint.io/" rel="noopener noreferrer nofollow">stylelint</a> for CSS/SCSS/Sass/Less/SugarSS. While coding, you may have the linting tool running in watch mode within a terminal to monitor and report errors and warnings whenever you edit and save a file. This can become quite distracting, especially if you are focused more on adding new features to the application code before a tight deadline and you cannot afford to switch back-and-forth between the terminal and code editor. </p><p>Suppose you correct a problem and later on, you decide to scrap the code that you just fixed. Unfortunately, you wasted time on fixing a non-existent problem. Ideally, you should run the linter after you finish coding, but you may forget to run the linter and immediately commit the changes (with the mistakes).</p><p>With <strong><code><a href="https://github.com/okonet/lint-staged" rel="noopener noreferrer nofollow">lint-staged</a></code></strong>, executing the command <code>git commit</code> automatically runs the linter against files staged for commit. This lets you continue working on the application code without any interruptions, and once you are done with the code, you can stage the modified files and run the linter before committing them. You can configure <code>lint-staged</code> to run a specific linter command against files that match a glob pattern. For JavaScript files (<code>*.js</code>), you may select ESLint as the linter to run against those files. For CSS files (<code>*.css</code>), you may select stylelint as the linter to run against those files. </p><p>If any files fail to pass, then they are not committed to the remote repository! Before the files can be committed, you must first resolve the errors raised by the linter. For projects with many contributors, linting enforces the project's coding conventions despite each contributor having their own set of opinions and conventions.</p><p>Below, I'm going to show you how to integrate <code>lint-staged</code> into your project.</p><h2 class="heading-anchor-text" id="how-does-lint-staged-differ-from-pre-commit-and-husky?"><span>How Does <code>lint-staged</code> Differ From <code>pre-commit</code> and <code>Husky</code>?</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#how-does-lint-staged-differ-from-pre-commit-and-husky?">#</a></h2><p>Unlike <code>lint-staged</code>, <code><a href="https://github.com/observing/pre-commit" rel="noopener noreferrer nofollow">pre-commit</a></code> and <code><a href="https://typicode.github.io/husky/" rel="noopener noreferrer nofollow">Husky</a></code> lints all files, not just staged files. As your project grows, linting every file, even those that have not been recently modified and previously passed all the linting rules, becomes inefficient and increases development time from redundant linting. </p><p>Husky supports all Git hooks, whereas <code>pre-commit</code> and <code>lint-staged</code> only support the <code>pre-commit</code> Git hook. Nevertheless, each library allows you to run any number of custom scripts defined in <code>package.json</code> when a hook, such as <code>pre-commit</code>, is invoked by an event, such as executing the <code>git commit</code> command.</p><p><code>lint-staged</code> uses Husky under-the-hood.</p><h2 class="heading-anchor-text" id="installation"><span>Installation</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#installation">#</a></h2><p>To get started, check that your project already has ESLint, stylelint or Prettier configured (either via a <code>.xxxrc</code> configuration file or a key inside <code>package.json</code>). Otherwise, the following error message is shown during the installation of <code>lint-staged</code>.  </p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-1NbmHjJqsTGy1WdenvfuJ" id="cm-1NbmHjJqsTGy1WdenvfuJ">Cannot add lint-staged: only eslint, stylelint, prettier or custom rules are supported.</textarea><p>To install <code>lint-staged</code>, run the following command within the root directory of your project:</p><textarea data-iscodemirror="true" data-mode="text/x-sh" data-uniqueid="cm-NH-rSthJVr4bvWfnCgBYI" id="cm-NH-rSthJVr4bvWfnCgBYI">$ npx mrm@2 lint-staged</textarea><p><em>Note</em>: <code><a href="https://www.npmjs.com/package/mrm" rel="noopener noreferrer nofollow">mrm</a></code> is a command line tool for automating and managing project configurations.</p><p>If you are prompted with the following message, then press <code>y</code> to proceed with the installation:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-xZh0pehOo1zGVEevqzSvS" id="cm-xZh0pehOo1zGVEevqzSvS">Need to install the following packages:
  mrm@2
Ok to proceed? (y)</textarea><p>This command...</p><ul><li><p>Creates a <code>./husky</code> directory.</p></li><li><p>Adds the <code>husky</code> and <code>lint-staged</code> packages to <code>package.json</code> as dev. dependencies.</p></li><li><p>Adds a <code>lint-staged</code> property to <code>package.json</code>. </p></li></ul><p>If <code>lint-staged</code> finds a <code>.eslintrc.js</code> configuration file, then a <code>*.js</code> property is added to the <code>lint-staged</code> object.</p><p>(<code>package.json</code>)</p><textarea data-iscodemirror="true" data-mode="application/json" data-uniqueid="cm-e4bP3bDkqwz0WIlOQhmym" id="cm-e4bP3bDkqwz0WIlOQhmym">{
  "lint-staged": {
    "*.js": "eslint --cache --fix"
  }
}</textarea><p>Anytime a JavaScript file is staged for a commit, <code>lint-staged</code> runs the ESLint linter with the <code>--cache</code> and <code>--fix</code> options. <code>--cache</code> tells ESLint to only check changed files, and <code>--fix</code> tells ESLint to automatically fix problems when possible.</p><p>If <code>lint-staged</code> finds a <code>.prettierrc</code> configuration file, then a <code>*.{js,css,md}</code> property is added to the `lint-staged object.</p><p>(<code>package.json</code>)</p><textarea data-iscodemirror="true" data-mode="application/json" data-uniqueid="cm-7xfPV1TlwDPY7aZ2fSAAs" id="cm-7xfPV1TlwDPY7aZ2fSAAs">{
  "lint-staged": {
    "*.{js,css,md}": "prettier --write"
  }
}</textarea><p>Anytime a JavaScript, CSS or Markdown file is staged for a commit, <code>lint-staged</code> runs Prettier to properly format the contents of the files. This ensures the files are formatted, even if a contributor does not have the Prettier plugin installed on their IDE to automatically format the files when saved. </p><h2 class="heading-anchor-text" id="adding-new-scripts"><span>Adding New Scripts</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#adding-new-scripts">#</a></h2><p>Suppose you want the staged JavaScript files to pass unit tests written with the <a href="https://jestjs.io/" rel="noopener noreferrer nofollow">Jest testing framework</a>. Adding a new script is relatively straight-forward. Just update the value of the <code>*.js</code> key to an array that contains a list of scripts to run against the staged JavaScript files. </p><p>Let's run the tests with the <code>jest --passWithNoTests</code> command. The <code>--passWithNoTests</code> option allows the test suite to pass even if there are no test files present and you plan to add unit tests in the future.</p><p>(<code>package.json</code>)</p><textarea data-iscodemirror="true" data-mode="application/json" data-uniqueid="cm-_yYdjrrevw_NAlWpI86Ax" id="cm-_yYdjrrevw_NAlWpI86Ax">{
  "lint-staged": {
    "*.js": [
      "eslint --cache --fix",
      "jest --passWithNoTests"
    ]
  }
}</textarea><p>These scripts run in sequence from the first listed item to the last listed item. If a single command fails, then the entire commit is rejected.</p><h2 class="heading-anchor-text" id="next-steps"><span>Next Steps</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#next-steps">#</a></h2><p>Try integrating <code>lint-staged</code> to your own JavaScript libraries.&nbsp;You can also check out our new course, <em><a href="https://www.newline.co/courses/creating-react-libraries-from-scratch" rel="noopener noreferrer nofollow">The newline Guide to Creating React Libraries from Scratch</a>, </em>where we teach you everything you need to know to succeed in creating a library.&nbsp;</p><figure class="photo figure-position-inline"><a href="https://www.newline.co/courses/creating-react-libraries-from-scratch" contenteditable="true"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20210921150112892_Course%20Card%20%285%29%20%282%29%20%281%29.png" attachmentid="667826c6-9d44-4a38-b21f-c73a45bd7181" contenteditable="false" data-width="1920" data-height="1080"></a><div></div></figure><p></p><h2 class="heading-anchor-text" id="sources"><span>Sources</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#sources">#</a></h2><ul><li><p><code><a href="https://github.com/okonet/lint-staged" rel="noopener noreferrer nofollow">lint-staged</a></code><a href="https://github.com/okonet/lint-staged" rel="noopener noreferrer nofollow"> Documentation</a></p></li></ul><p></p>

AUTHOR

Ken Chan

An easy way to improve code quality is linting code for formatting issues, syntax typos and inconsistencies. For example, you may have accidentally left a console.log statement that prints environment variables during development. Or you may have forgotten a semi-colon during a quick bug fix.…

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Free Tools

Linting Staged Git Files with lint-staged

Responses (0)

Free AI Career Tools

AI Job Listings

ATS Resume Checker

Startup Perks

Masterclasses

Tutorials

Fullstack React with TypeScript