{"action":"created","issue":{"url":"https://api.github.com/repos/airbnb/javascript/issues/1089","repository_url":"https://api.github.com/repos/airbnb/javascript","labels_url":"https://api.github.com/repos/airbnb/javascript/issues/1089/labels{/name}","comments_url":"https://api.github.com/repos/airbnb/javascript/issues/1089/comments","events_url":"https://api.github.com/repos/airbnb/javascript/issues/1089/events","html_url":"https://github.com/airbnb/javascript/issues/1089","id":179059289,"number":1089,"title":"What rules do the community tend to override?","user":{"login":"ljharb","id":45469,"avatar_url":"https://avatars.githubusercontent.com/u/45469?v=3","gravatar_id":"","url":"https://api.github.com/users/ljharb","html_url":"https://github.com/ljharb","followers_url":"https://api.github.com/users/ljharb/followers","following_url":"https://api.github.com/users/ljharb/following{/other_user}","gists_url":"https://api.github.com/users/ljharb/gists{/gist_id}","starred_url":"https://api.github.com/users/ljharb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ljharb/subscriptions","organizations_url":"https://api.github.com/users/ljharb/orgs","repos_url":"https://api.github.com/users/ljharb/repos","events_url":"https://api.github.com/users/ljharb/events{/privacy}","received_events_url":"https://api.github.com/users/ljharb/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/airbnb/javascript/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":57,"created_at":"2016-09-25T00:17:27Z","updated_at":"2016-10-24T19:28:40Z","closed_at":null,"body":"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*.\r\n\r\nThis 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.\r\n\r\nAny comments mentioning spaces vs tabs, or semicolons, will be summarily deleted :-)\r\n\r\nWe're aware of the following:\r\n - `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).\r\n - `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](https://github.com/eslint/eslint/issues/3611), then we'd set up some common test directory patterns so you wouldn't have to do this manually)\r\n```js\r\n  \"import/no-extraneous-dependencies\": [\"error\", {\r\n    \"devDependencies\": true,\r\n    \"optionalDependencies\": false,\r\n  }],\r\n```\r\n - `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`.\r\n - `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)\r\n - `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)\r\n - `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 `-`.\r\n\r\nAny others? I'll update the original post with new examples as I'm made aware of them.\r\n\r\n(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)"},"comment":{"url":"https://api.github.com/repos/airbnb/javascript/issues/comments/255840639","html_url":"https://github.com/airbnb/javascript/issues/1089#issuecomment-255840639","issue_url":"https://api.github.com/repos/airbnb/javascript/issues/1089","id":255840639,"user":{"login":"mglidden","id":1319930,"avatar_url":"https://avatars.githubusercontent.com/u/1319930?v=3","gravatar_id":"","url":"https://api.github.com/users/mglidden","html_url":"https://github.com/mglidden","followers_url":"https://api.github.com/users/mglidden/followers","following_url":"https://api.github.com/users/mglidden/following{/other_user}","gists_url":"https://api.github.com/users/mglidden/gists{/gist_id}","starred_url":"https://api.github.com/users/mglidden/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mglidden/subscriptions","organizations_url":"https://api.github.com/users/mglidden/orgs","repos_url":"https://api.github.com/users/mglidden/repos","events_url":"https://api.github.com/users/mglidden/events{/privacy}","received_events_url":"https://api.github.com/users/mglidden/received_events","type":"User","site_admin":false},"created_at":"2016-10-24T19:28:40Z","updated_at":"2016-10-24T19:28:40Z","body":"In addition to a few subjective ones, we also disable:\r\n\r\n`class-methods-use-this`: Let's say you have classes A and B, which both inherit from the same class. Class B might not use `this`, but can't be static because A needs `this`. This is a common enough pattern for us that we turned it off.\r\n\r\n`arrow-body-style`: The current setting allows one to write both of these functions:\r\n```\r\nconst fn1 = (list, arg) => (\r\n  _.find(list, { foo: arg })\r\n);\r\nconst fn2 = (list, arg) => {\r\n  _.find(list, { foo: arg });\r\n};\r\n```\r\n`fn1` returns the value, while `fn2` doesn't. The similarity is confusing, so we don't want to allow functions in the style of `fn1` (specifically, multi-line implicit returns – single line are much more obvious). ESLint can't enforce this, so we just manually watch for it."}}
{"actor":{"display_login":"mglidden"}}