How to use ESLint with Airbnb style guide

Getting ESLint configured with Airbnb’s style guide is one of those things that feels like a chore until you realize how much it saves you on code reviews. Airbnb’s rules are pretty strict but well thought out, catching both style and some semantic gotchas.

First step is to install the base ESLint and Airbnb config packages. You’ll want to grab the main eslint, the Airbnb config itself, and some peer dependencies it relies on. The easiest way is to run this in your project root:

npm install --save-dev eslint eslint-config-airbnb eslint-plugin-import eslint-plugin-react eslint-plugin-jsx-a11y

That pulls in ESLint plus Airbnb’s config and the plugins for import management, React, and accessibility that Airbnb’s rules depend on.

Once installed, create or update your .eslintrc.json or .eslintrc.js file to extend Airbnb’s base rules. A minimal config looks like this:

{
  "extends": "airbnb",
  "env": {
    "browser": true,
    "node": true,
    "es6": true
  },
  "parserOptions": {
    "ecmaVersion": 2020,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  }
}

This says: use Airbnb’s full style guide, allow browser and Node globals, enable ES6+ syntax, and support JSX if you’re working with React.

If you want a quick smoke test, run ESLint on a file with npx eslint yourfile.js. You’ll see the kind of issues Airbnb flags right away. It’s a good way to get a sense of what rules you’ll be dealing with.

For projects without React, you can switch to eslint-config-airbnb-base instead, which is the same style guide minus React and JSX-specific rules:

npm install --save-dev eslint-config-airbnb-base eslint-plugin-import

Then your config becomes:

{
  "extends": "airbnb-base",
  "env": {
    "node": true,
    "es6": true
  },
  "parserOptions": {
    "ecmaVersion": 2020,
    "sourceType": "module"
  }
}

That keeps you in Airbnb’s world but avoids pulling unnecessary React plugins and rules. It’s leaner and faster if you’re doing backend or vanilla JS projects.

Because Airbnb’s guide is opinionated, you’ll probably want to customize some rules to fit your team’s preferences or legacy code quirks. But start with the strict baseline, then loosen selectively rather than trying to build up from nothing. ESLint’s overrides feature is also handy for applying different rules to test files, scripts, or legacy folders.

Remember to add an ESLint script to your package.json so you and your CI system can run it consistently:

"scripts": {
  "lint": "eslint . --ext .js,.jsx"
}

Now you just run npm run lint to check your entire codebase. Catching style issues early is way less painful than in code reviews or production.

In case your editor supports it, install the ESLint plugin for real-time feedback as you type. It’s a huge productivity boost.

That’s the essentials to get Airbnb style locked in with ESLint. Next up, you’ll want to explore customizing those rules to fit your project’s unique needs, because no rule set out of the box fits perfectly across all teams and codebases. It’s about striking the right balance between consistency and developer freedom so your code stays readable and maintainable without driving everyone nuts.

For instance, if your team prefers single quotes over double quotes, Airbnb defaults to double quotes, so you’d override that rule:

{
  "extends": "airbnb",
  "rules": {
    "quotes": ["error", "single"]
  }
}

This tells ESLint to enforce single quotes and treat violations as errors. Similarly, if you want to allow console statements for debugging:

{
  "extends": "airbnb",
  "rules": {
    "no-console": "off"
  }
}

This disables the rule that otherwise flags any console usage.

Dealing with line length is another common tweak. Airbnb enforces 100 characters max by default, but you might want 120 or 80 depending on your editor window setup:

{
  "extends": "airbnb",
  "rules": {
    "max-len": ["error", { "code": 120 }]
  }
}

Once you start tailoring rules, you can create a shared config for your org or project to keep everyone aligned and make onboarding new developers smoother.

Remember, ESLint configs are JSON or JavaScript objects. You can use comments, variables, and functions if you choose .eslintrc.js format, which gives you more flexibility for complex setups. Here’s a quick example that dynamically adjusts rules based on environment variables:

module.exports = {
  extends: 'airbnb',
  rules: {
    'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'off',
  },
};

This disables debugger statements in production builds but allows them during development. Little tricks like this keep your linting strict where it counts and flexible where you need it.

Keep in mind that ESLint rules often come in three flavors: off, warn, and error. Use warn to flag issues without breaking builds, or error to enforce hard stops. It’s good practice to start with warn on new rules and graduate to error when your codebase stabilizes.

With Airbnb’s style guide and ESLint combined, you get a powerful safety net that helps catch potential bugs, enforces style consistency, and nudges you toward best practices without being overly verbose or subjective. It’s not about rigid conformity but about having a shared language your entire team speaks fluently.

Getting this setup right early in a project saves hours of bike-shedding later. It also sets a solid foundation for automated tools like Prettier to pick up formatting chores, letting ESLint focus on code quality and correctness. And once you’re comfortable, you can extend Airbnb’s config with plugins for TypeScript, Jest, or other ecosystems your project uses.

Finally, don’t forget to check ESLint’s official docs for the most recent Airbnb config versions and peer dependencies. They sometimes update plugins or drop support for older Node versions, so staying current avoids headaches down the line.

Once you have the base Airbnb config wired up and running, the next logical step is to customize it to your team’s workflow and coding style preferences without losing the core benefits of a well-defined standard. That’s where the real power of ESLint shines—fine-tuning the rules instead of starting from scratch.

Here’s a quick snippet showing how to override multiple rules at once:

{
  "extends": "airbnb",
  "rules": {
    "no-console": "off",
    "comma-dangle": ["error", "never"],
    "indent": ["error", 2, { "SwitchCase": 1 }],
    "max-len": ["warn", 120]
  }
}

This disables console warnings, enforces no trailing commas, sets 2-space indentation including switch cases, and warns on lines longer than 120 characters instead of erroring out. Mixing error levels like this lets you prioritize the issues that matter most.

Don’t forget to run eslint --fix periodically to auto-correct fixable issues and keep your codebase clean. It’s a huge time saver and helps everyone stay consistent without manual intervention.

From here, you can also look into integrating ESLint with your editor via plugins for VSCode, Sublime Text, or JetBrains IDEs. Real-time linting feedback as you write code dramatically reduces the back-and-forth in code reviews and catches bugs earlier.

The process might look tedious at first, but once locked in, the Airbnb + ESLint combo feels like an extension of your brain, highlighting subtle mistakes and style slips that would otherwise sneak past until they cause bigger problems.

If you want to avoid the hassle of installing all dependencies manually, Airbnb’s config now supports a handy setup command:

{
  "extends": "airbnb",
  "env": {
    "browser": true,
    "node": true,
    "es6": true
  },
  "parserOptions": {
    "ecmaVersion": 2020,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  }
}

This installs the config plus all peer dependencies in one go, making life easier for new projects or onboarding.

With that done, your .eslintrc extends Airbnb, and you’re off to a cleaner, more consistent codebase. Next, you can dive into

Customizing ESLint rules for your project

the specifics of customizing your rules even further based on the needs of your project. For example, if your team prefers to enforce consistent spacing around operators, you can add the following rule:

{
  "extends": "airbnb",
  "rules": {
    "space-infix-ops": "error"
  }
}

This will ensure that operators like + and - have spaces on both sides, improving readability. You can also specify rules for specific contexts, such as enforcing consistent return statements in functions:

{
  "extends": "airbnb",
  "rules": {
    "consistent-return": "error"
  }
}

This rule will flag any functions that do not consistently return a value, helping to avoid unexpected behavior in your code.

Another common customization is to enforce the use of arrow functions instead of traditional function expressions, which can lead to cleaner and more concise code:

{
  "extends": "airbnb",
  "rules": {
    "prefer-arrow-callback": "error"
  }
}

By setting this rule, you enforce a consistent pattern for defining functions, especially in callbacks, which can help in maintaining a uniform style throughout your codebase.

Don’t say goodbye to the potential for performance improvements. If you have a large codebase, consider enabling the no-unused-vars rule to catch variables that are declared but never used:

{
  "extends": "airbnb",
  "rules": {
    "no-unused-vars": ["warn"]
  }
}

This can help in keeping your code clean and efficient, as unused variables can clutter your code and lead to confusion.

When working with asynchronous code, you might want to enforce the use of async/await over callbacks or promises. This can be achieved with the following rule:

{
  "extends": "airbnb",
  "rules": {
    "require-await": "error"
  }
}

This will ensure that all async functions actually contain await expressions, preventing the accidental creation of async functions that do nothing.

As you continue to refine your ESLint configuration, consider using the eslint-plugin-prettier to integrate Prettier into your linting process. This way, you can enforce formatting rules alongside linting rules:

npm install --save-dev eslint-plugin-prettier eslint-config-prettier

Then, extend your configuration like so:

{
  "extends": [
    "airbnb",
    "plugin:prettier/recommended"
  ]
}

This setup allows Prettier to manage formatting while ESLint focuses on code quality, giving you the best of both worlds.

As you adapt your ESLint rules, keep your team’s preferences and coding styles in mind. Regularly revisiting your ESLint configuration as your project evolves will help ensure that it remains relevant and effective.

Lastly, consider documenting your ESLint rules in your project’s README or a dedicated CONTRIBUTING guide. This ensures that new developers can quickly get up to speed with your coding standards and helps maintain consistency as your codebase grows.