Skip to main content

How to Ignore the node_modules Directory in ESLint in JavaScript

When you run ESLint, its job is to analyze and lint all the JavaScript or TypeScript files it can find. However, you almost never want ESLint to check the files inside your node_modules directory. These are third-party libraries, and linting them is unnecessary, slows down the process, and can produce a huge amount of irrelevant warnings.

This guide will teach you the standard and most effective methods for telling ESLint to ignore the node_modules folder, as well as other directories like your build output (dist or build).

The Core Problem: Linting Third-Party Code

By default, ESLint is designed to ignore the node_modules directory. However, depending on how your lint script is configured in package.json or how you invoke the eslint command, you might accidentally override this default behavior.

A common example is a lint script that explicitly tells ESLint where to look:

// In package.json
"scripts": {
"lint": "eslint '**/*.{js,jsx,ts,tsx}'"
}

This kind of glob pattern can inadvertently cause ESLint to traverse into node_modules. To prevent this, you should explicitly tell ESLint which folders to ignore.

The most common and robust way to manage ignored files is with a dedicated .eslintignore file. This file works just like a .gitignore file: any file or directory path you add to it will be skipped by ESLint.

Solution:

  1. In the root directory of your project (the same level as package.json), create a file named .eslintignore.
  2. Add the names of the directories you want to ignore, each on a new line.

.eslintignore:

# Ignore all node_modules folders, including nested ones
node_modules/

# Ignore build output folders
build/
dist/
out/
note

This is the recommended best practice because it keeps your ignore rules separate from your ESLint rule configuration, and it's a pattern familiar to anyone who has used Git.

Solution 2: Using ignorePatterns in Your ESLint Config

An alternative method is to specify your ignore patterns directly within your main ESLint configuration file (e.g., .eslintrc.js or .eslintrc.json). This can be useful for keeping all your configuration in a single file.

Solution: add an ignorePatterns key to your ESLint configuration. This key takes an array of glob patterns to ignore.

In .eslintrc.js:

module.exports = {
// ... other ESLint config
ignorePatterns: [
'node_modules/',
'build/',
'dist/',
'out/',
],
};

In .eslintrc.json:

{
"ignorePatterns": [
"node_modules/",
"build/",
"dist/",
"out/"
]
}
note

Patterns specified in a .eslintignore file will take precedence over the ignorePatterns property.

Why is node_modules Sometimes Not Ignored by Default?

ESLint's default behavior is to ignore node_modules. This can be overridden in a few situations:

  • Explicit lint commands: As shown earlier, a glob pattern in your package.json script can force ESLint to look everywhere.
  • Negated patterns: If your .eslintignore file contains a negated pattern (e.g., !**/*.js), it can override the default ignore and cause node_modules to be included. If you have such patterns, ensure they are specific enough not to include node_modules.
  • Using --no-ignore: If the eslint command is run with the --no-ignore flag, it will disregard all ignore rules.

In all these cases, creating a .eslintignore file is the most reliable way to enforce the correct behavior.

Conclusion

Ignoring the node_modules directory is essential for a fast and clean linting process.

  • The recommended best practice is to create a .eslintignore file in your project's root and add node_modules/ to it. You should also add your build output directories (build/, dist/, etc.).
  • An alternative is to use the ignorePatterns property in your .eslintrc.js or .eslintrc.json configuration file.

By explicitly ignoring these directories, you ensure that ESLint focuses only on the code you've written, providing a faster and more relevant analysis.