JavaScript Style Guide
MIT License

In the, section 1.2, there is a typo/mistake in the line:

console.log(foo[0], bar[0]); // => 9, 9

It should display:

console.log(foo[0], bar[0]); // => 1, 9

So is there any intention to revisit the standing on Iterators and Generators? I'm mostly instrested specifically in revisiting the advice given in 11.2 Don’t use generators for now.

Reason for asking

  1. The reasons why are based off thoughts and usage that is more then 7+ years old now
  2. Browsers and transpilers have come along way over the last 7+ years
  3. With New APIs and Objects
    Examples where methods on the objects return an iterator and not an array:
    - Map.entries()
    - Set.entries()


The second section of the guide is "References", which is a prescription to use "const" over "var". This section showcases a "bad" code example and a "good" code example. So far, so good.

The first section of the guide is "Types", which, as far as I can tell, doesn't offer any prescriptions at all. It is simply educating the reader on the how variables work in the JavaScript programming language. Furthermore, the section does not show any "bad" code examples or "good" code examples.

Is there a particular reason that this section is included in the style guide? It seems notably out of place - every other section seems to impart a specific coding prescription. There is a time and a place to teach JavaScript newbies the basics on how the language works, and it doesn't seem like it should be in a style guide.

Eslint announced a new config spec.

스크린샷 2022-09-09 오후 10 07 49

According to eslint's official blog, though backward compatibility was taken care of, not all shareable configs continue to work with the new config system.

Are eslint-config-airbnb-base and eslint-config-airbnb compatible with the new config?


Just a question: Why do you allow empty reject on the prefer-promise-reject-errors rule?
I've seen no comment or reason 🤔 is it for legacy reason? 🤔

// require using Error objects as Promise rejection reasons
'prefer-promise-reject-errors': ['error', { allowEmptyReject: true }],

Thanks for any information you can give me regarding best practices.


I have problem after installing eslint-config-airbnb. In output of ESLint I have error:
Failed to load plugin 'jsx-a11y' declared in 'frontend/.eslintrc » eslint-config-airbnb » /Users/user/Documents/GitHub/app/frontend/node_modules/eslint-config-airbnb/rules/react-a11y.js': Cannot find module 'eslint-plugin-jsx-a11y'

Here's my package.json devDependecies:
"devDependencies": { "eslint": "^6.1.0", "eslint-config-airbnb": "^18.0.1", "eslint-config-prettier": "^6.1.0", "eslint-plugin-import": "^2.18.2", "eslint-plugin-jsx-a11y": "^6.2.3", "eslint-plugin-react": "^7.14.3", "eslint-plugin-react-hooks": "^1.7.0", "husky": "^3.0.4", "lint-staged": "^9.2.3", "prettier": "^1.18.2", "pretty-quick": "^1.11.1" }
Summary - ESLint is not working on my project. Project was created with create-react-app.

The current configuration of react/jsx-no-bind allows to use arrow functions as event handlers (and ignores the use of bind in DOM components too):


However, here's what the style guide has to say bout this:


  1. I agree with the guide's argument and belive that it would be best to update the rule configuration to match it. Using arrow function to initialize an event handler creates a brand new function on each render same as bind() does, which can lead to unnecessary re-renders.

  2. To be honest, I'd even turn ignoreDOMComponents to false too — it is unclear why DOM components deserve a different treatment. I'd say the reasoning from the style guide fully applies to them too.

  3. If, however, there is some reasoning behind these exceptions — then the style guide should probably reflect it.

When I read this sentence, I thought like this:

// bad: freedom spacing (hard to read)
obj[foo ]
obj[ 'foo']
const x = {[ b ]: a}
obj[foo[ bar ]]

// good: forced to spacing inside brackets (easy to read)
obj[ foo ]
obj[ 'foo' ]
const x = { [ b ]: a }
obj[ foo[ bar ] ]

But, it was wrong. Correct answer is this:

  • 19.16 Enforce spacing inside of computed property brackets. eslint: computed-property-spacing

    // bad
    obj[foo ]
    obj[ 'foo']
    const x = {[ b ]: a}
    obj[foo[ bar ]]
    // good
    const x = { [b]: a }

I have some possible solutions:

  1. Change the word "enforce" to "avoid".
  2. Exclude explaining about spacing in "{}" from sample code.
    (already talken in about eslint: object-curly-spacing and eslint: block-spacing)


  1. Use ESLint official sentence "Enforce consistent spacing inside computed property brackets".

Similar Issues and PRs exist already and some have been merged:


I would like to contribute by translating the guide in Greek.

The rule is set to error in the config:

'no-use-before-define': ['error', { functions: true, classes: true, variables: true }],

But there's no mention of it in the guide:

This rule should be mentioned under the Variables section.

We haven't seen Promises here in the list
Add Promises to the list.

First of all, great job on this guide, I agree with it almost 100%. All of this should really be common knowledge, but I sure as hell didn't know most of these things when I started, so kudos for writing it all down.

Now, since promises have been standardized and a lot of people have started using them, it would be nice to have a section on how to keep promise-based code readable. For instance, when chaining multiple promises together, there are at least two alternative ways to do it:

Option 1: anonymous functions

return doSomething(foo).then(function(result) {
  // ...
}).then(function(result2) {
  // ...
}).then(function(result3) {
  // ...
}).catch(function(error) {
  // ...
}).finally(function() {
  // ...

Option 2: named functions

function doThis(result) {
  // ...
function doThat(result) {
  // ...
function handleError(error) {
  // ...
function done() {
  // ...

return doSomething(foo)

The second way, while being somewhat more verbose, seems to be preferable, as the chain of tasks that the promise result travels through becomes more obvious.

I did an internal poll of our developers, and so far, option 2 seems to be ahead, although I have not heard from everyone yet. How does AirBnB deal with this, and what are your opinions?

It seems installing eslint-config-airbnb-base includes some vulnerabilities:

npm uninstall eslint-config-airbnb-base

Output: found 0 vulnerabilities

npm install eslint-config-airbnb-base

Output: 4 high severity vulnerabilities

I am facing similar issue as mentioned in #2540

whenever I run "eslint ." i am thrown "Unexpected end of JSON input"

A new JSX transform was introduced in React 17 and backported to React 16.14.0, 15.7.0, and 0.14.10, which enables people to use JSX features without having React in the scope. Obviously this will cause tons of react/react-in-jsx-scope errors in a new project (or that a project that used the codemod to remove the imports) that is using the airbnb config.

In CRA we use the following heuristic to catch if the new transform is available:

const hasJsxRuntime = (() => {
  try {
    return true;
  } catch (e) {
    return false;

My question is a) should the airbnb config use a similar heuristic or a) should the rule be disabled by default in a new major version or c) should the configuration option/issue be documented somewhere in detail as many people using the config will eventually run into it.

Since ESlint has the helpful prefer-exponentiation-operator rule it would be nice if Math.pow was removed from the no-restricted-properties definitions in rules/best-practices.js in favor of the prefer-exponentiation-operator rule.

This has the benefit to us stubborn folks who want to use the eslint-config-airbnb or eslint-config-airbnb-base packages but want to override the rule to allow the use of Math.pow. The no-restricted-properties ESlint rule can't be selectively modified, eslint/eslint#7957. It has to be completely duplicated and the desired change made in the duplicate. The Math.pow entry in no-restricted-properties doesn't really fit in with the "intent" of the other entries in the no-restricted-propertiesobjects and since theprefer-exponentiation-operator` rule exist it is a neat and tidy modification.

Thank you,

In the Resources -> 'Other Styles' section of the README, there is a link to 'Popular JavaScript Coding Conventions on GitHub'. That site shows the "current" JavaScript coding conventions by analyzing commits, however it has not been updated since July 19, 2014.