How to run ESLint from the command line

Start by adding ESLint as a development dependency to your project. Using npm or yarn, this is a straightforward step:

npm install eslint --save-dev

or

yarn add eslint --dev

Once installed, initialize ESLint with a configuration wizard. This guides you through setting rules and environments based on your project’s needs:

npx eslint --init

This command asks questions about your coding style, framework, and environment to create a tailored .eslintrc file. If you prefer, create the configuration manually by adding a JSON or YAML file named .eslintrc.json or just .eslintrc in your project root.

Here’s a minimal example of a configuration file that targets ES6 syntax and the browser environment:

{
  "env": {
    "browser": true,
    "es6": true
  },
  "extends": "eslint:recommended",
  "rules": {
    "no-console": "warn",
    "indent": ["error", 2],
    "quotes": ["error", "single"]
  }
}

Pick rules that align with your team’s style and standards. ESLint’s power lies in its customizability, so don’t settle for defaults without understanding what each rule enforces.

If your project uses React, Vue, or Node.js, install the relevant ESLint plugins and extend their recommended configurations. For React, for example:

npm install eslint-plugin-react --save-dev

{
  "env": {
    "browser": true,
    "es6": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended"
  ],
  "plugins": [
    "react"
  ],
  "rules": {
    "react/prop-types": "off"
  }
}

Don’t forget to configure your parser options if you’re using newer JavaScript features or TypeScript.

{
  "parserOptions": {
    "ecmaVersion": 2021,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  }
}

With your configuration in place, add an npm script to run ESLint easily:

"scripts": {
  "lint": "eslint ."
}

This lets you check your entire codebase by running npm run lint. Keep your configuration close to the code and version-controlled. That way, everyone on the team shares the same standards and linting rules.

Remember, ESLint is not just for catching bugs; it enforces consistency and readability, which are prerequisites for maintainable code. Set it up early and integrate it into your development workflow to avoid drifting into messy, error-prone code.

Before moving on, ensure your editor supports ESLint integration. Many popular editors like VSCode have extensions that highlight issues in real-time, letting you fix problems as you type.

Configuring ESLint for a large or legacy codebase may require fine-tuning. You might want to disable certain rules temporarily or create overrides for specific folders. For example:

{
  "overrides": [
    {
      "files": ["legacy/**/*.js"],
      "rules": {
        "no-console": "off"
      }
    }
  ]
}

With these basics covered, you’re ready to run ESLint on your project and start refining your code quality. Next, you’ll want to run it regularly and interpret the results to make meaningful improvements to your codebase. But before that, keep your configuration tidy and avoid mixing conflicting rules, as that only creates confusion and wasted time.

ESLint’s ecosystem is vast. Beyond the core rules, consider integrating style guides like Airbnb’s or Google’s for a more opinionated, battle-tested setup. Install them via npm and extend their configs:

npm install eslint-config-airbnb --save-dev

yarn add eslint --dev

Use these presets as starting points and adjust as necessary to fit your project’s unique requirements. The goal is to have a consistent, automated check on your code style and correctness, reducing the cognitive overhead during code reviews and debugging.

Once everything is wired up, running ESLint becomes part of the build process, CI pipelines, and local development. Missing this step means missing out on catching errors early before they become costly bugs.

Setting up ESLint properly is the foundation. Without this, all your efforts to write clean, maintainable JavaScript will be incomplete. The next step is to actually run ESLint on your codebase and interpret the results, which is where the real discipline begins. But that’s a topic for the next discussion, because right now you need to make sure the tool is configured correctly and ready to guide your work.

Remember-linting isn’t about perfection; it’s about consistency and catching the common pitfalls before they spiral out of control. And ESLint, when properly configured, is the most reliable ally you can have for that mission. Now, let’s see how to execute it effectively-

Running ESLint on your codebase

To run ESLint on your codebase, you can execute the command directly in your terminal. This will scan all JavaScript files in your project and output any linting errors or warnings:

npx eslint .

This command instructs ESLint to check every file in the current directory and its subdirectories. You can specify particular files or directories if you want to limit the scope:

npx eslint src/yourFile.js

By default, ESLint will display errors and warnings in the console, but you can customize the output format. For example, to get a more readable format, you can use:

npx eslint . --format stylish

ESLint supports multiple formats, including JSON, HTML, and more. Choose a format that suits your needs for integration with other tools or for reporting purposes. If you prefer to save the output to a file, you can redirect the output like this:

npx eslint . --format json > eslint-results.json

After running ESLint, you’ll get a list of issues, including the file name, line number, and a description of the problem. Each issue will be categorized as either an error or a warning. Pay attention to the errors, as they indicate problems that must be addressed for the code to function correctly.

To fix issues, you can address them manually or use ESLint’s automatic fix feature. For many common problems, ESLint can fix them for you. Use the following command to enable this feature:

npx eslint . --fix

This command will automatically correct fixable issues and save the changes directly to the files. However, exercise caution; not all issues can be automatically fixed, and you should review the changes made by ESLint to ensure they align with your coding style and intentions.

Incorporating ESLint into your development workflow is crucial. Consider running it as part of your pre-commit hooks using a tool like Husky. This ensures that your code meets the defined standards before it gets pushed to the repository:

npx husky add .husky/pre-commit "npx eslint ."

This way, any code that doesn’t comply with your ESLint rules will be blocked from committing, preserving the integrity of your codebase. Additionally, you can integrate ESLint into your CI/CD pipeline to enforce linting on every push or pull request. This acts as a safety net, catching issues early in the development process.

As you run ESLint regularly, you may encounter various errors. Understanding these errors is the next step. ESLint provides detailed messages, often including suggestions for how to fix the problem. For instance, if you see an error about a missing semicolon, it will guide you to the line in question and indicate the expected syntax:

error  Missing semicolon  semi

These messages are essential for learning and improving your coding skills. Take the time to read and comprehend them. Over time, you’ll notice patterns in your coding mistakes, which can inform your coding practices. The goal is to not only fix the errors but also to learn from them to avoid repeating them in the future.

Addressing linting errors promptly is a key practice in maintaining a clean codebase. Ignoring them can lead to technical debt, making your code harder to read and maintain over time. Strive to resolve issues as they arise rather than letting them accumulate. This proactive approach will save you from larger problems down the line.

As you become more familiar with ESLint, consider customizing your rules further. You can create your own rules or modify existing ones to better fit your team’s coding style. ESLint is flexible, and its configuration allows for a wide range of adjustments tailored to your specific project needs. For example, if your team prefers a different indentation style, you can adjust the rules accordingly:

"rules": {
  "indent": ["error", 4]
}

As you refine your ESLint configuration, keep in mind that the objective is to foster a collaborative environment where everyone adheres to the same standards. This consistency not only enhances code quality but also improves team dynamics and productivity. When everyone is on the same page, it leads to smoother code reviews and fewer integration issues. The next step is to dive deeper into understanding specific errors and how to resolve them effectively…

Understanding and fixing ESLint errors

When ESLint reports errors, it provides a rule name and a message describing the violation. Understanding these messages is crucial to fixing the issues correctly. Let’s break down a typical ESLint error message:

src/app.js
  10:5  error  Unexpected console statement  no-console

This tells you the file (src/app.js), the line and column number (10:5), the severity (error), the problem description (Unexpected console statement), and the rule that was violated (no-console).

Knowing the rule name is important because it allows you to look up the rule’s documentation on the ESLint website. Each rule page explains the intent, provides examples of incorrect and correct code, and sometimes offers configuration options. This knowledge helps you decide whether to fix the code, adjust the rule, or disable it in specific cases.

Fixing errors usually involves changing your code to comply with the rules. For example, the no-console rule warns against using console.log statements in production code. To fix this, remove or replace them with proper logging mechanisms:

function fetchData() {
  // Bad: console.log('Fetching data...');
  // Good:
  logger.info('Fetching data...');
}

Sometimes, the fix is as simple as adding a missing semicolon or correcting indentation. ESLint’s --fix option can handle many of these automatically, but it won’t fix logical errors or style choices that require human judgment.

If you encounter warnings instead of errors, you have some flexibility. Warnings don’t block your build or prevent commits, but they highlight code that may cause readability or maintainability issues. Address these warnings regularly to keep your codebase clean.

In some cases, you may need to disable or modify a rule temporarily. ESLint allows inline disabling of rules for specific lines or blocks of code. This is useful when a rule conflicts with legitimate code patterns or external libraries:

// eslint-disable-next-line no-console
console.log('Debug info');

Use this sparingly and document why you’re disabling a rule to avoid confusion later. Overusing disables defeats the purpose of linting and can lead to inconsistent code.

For bulk exceptions, you can configure ESLint overrides in your .eslintrc file to disable rules for certain files or directories:

{
  "overrides": [
    {
      "files": ["tests/**/*.js"],
      "rules": {
        "no-unused-expressions": "off"
      }
    }
  ]
}

This is particularly helpful when testing frameworks use patterns that ESLint might flag but are valid in context.

When dealing with complex errors involving newer language features, ensure your parser options are up to date. ESLint’s default parser may not understand experimental syntax or TypeScript without additional configuration:

{
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 2022,
    "sourceType": "module"
  },
  "plugins": ["@typescript-eslint"],
  "extends": [
    "plugin:@typescript-eslint/recommended"
  ]
}

This setup gives you access to TypeScript-specific linting rules and better error reporting for typed code.

When an error isn’t clear, reproduce the problem in a small isolated example and test fixes there. This approach reduces noise and helps you understand the root cause without distractions from unrelated code.

Keep your ESLint version updated. Rule behavior can change between releases, and new rules or fixes are continually added. Regular updates ensure you benefit from the latest improvements and bug fixes.

Finally, integrate ESLint feedback into your code review process. Don’t just blindly fix errors; discuss rule changes and exceptions as a team. This collective ownership of linting rules drives shared code quality and prevents conflicts down the road.