What rules do the community tend to override?

I’m opening this issue specifically to gather a list of the rules that those in the community feel are controversial or problematic, such that they override them, and most importantly, why.

This is not an invitation for “+1s” (those belong as reactions on individual posts), or an invitation to hear about everyone’s subjective aesthetic preferences, nor is it an indication that any of these rules necessarily will - or will not - change. I’m simply hoping to primarily gather civil, well-reasoned explanations for why certain rules are overridden, disabled, etc.

Any comments mentioning spaces vs tabs, or semicolons, will be summarily deleted 😃

We’re aware of the following:

• react/jsx-filename-extension - filed as #985. Why is it controversial? Some believe that .js files should be allowed to contain JSX. Others believe this is an app-level concern, and does not belong in a shared config (like “env” settings).
• import/no-extraneous-dependencies: in test directories, for example, it needs to be overridden to the following (note: if/when eslint allows glob-based config, then we’d set up some common test directory patterns so you wouldn’t have to do this manually) eslint-config-airbnb v13.0.0 is now released, which resolves this.

  "import/no-extraneous-dependencies": ["error", {
    "devDependencies": true,
    "optionalDependencies": false,
  }],

• camelcase: when you’re bound to the casing selected by APIs (https://github.com/airbnb/javascript/issues/1089#issuecomment-249396262, but Airbnb suffers from this too) This might also apply to new-cap and no-underscore-dangle.
• no-param-reassign: this happens frequently with a reduce where the entire operation is pure, but the reducer is not (ie, it mutates the accumulator, but the accumulator began as {} passed into the reducer). You can use Object.assign({}, accumulator, changes), or { ...accumulator, ...changes }, however. (per https://github.com/airbnb/javascript/issues/1089#issuecomment-249396262)
• no-use-before-define: some enjoy using hoisting to define helper methods at the bottom of the file. This guide discourages relying on hoisting; instead suggesting importing the helpers from another file when possible. (per https://github.com/airbnb/javascript/issues/1089#issuecomment-249396262)
• no-mixed-operators - specifically where it relates to arithmetic operators, where the PEMDAS rule applies. We’re definitely considering loosening this rule as it applies to *, /, +, and -.

Any others? I’ll update the original post with new examples as I’m made aware of them.

(Note: this does not cover env settings, like “browser”, “node”, “mocha”, etc - these are app-level concerns, and as such, your .eslintrc, tests/.eslintrc, etc should be defining them)

[jonathanong]

• arrow-body-style or whatever, because it makes converting regular functions to arrow functions difficult as it’s not fixed automatically.
• camelcase - because many times i’m bound by other APIs
• no-param-reassign - makes working with koa/express/node.js difficult
• no-plusplus - because i += 1 is annoying
• prefer-template - because it isn’t convenient 5% of the time
• consistent-return - annoying with early returns
• new-cap - bound by other APIs
• no-underscore-dangle - disallows “private” properties. bound by mongodb.
• no-use-before-define - disallows function declarations at the bottom

[chadwatson]

no-use-before-define for functions. I personally don’t like to scroll down to the bottom of a file to see what a module really does. It’s inevitable that for some modules it just makes sense to leave the helper functions in the same file. I prefer to see the declarative stuff first instead of having to scroll through the imperative stuff first.