{"action":"opened","issue":{"url":"https://api.github.com/repos/eslint/eslint/issues/6659","repository_url":"https://api.github.com/repos/eslint/eslint","labels_url":"https://api.github.com/repos/eslint/eslint/issues/6659/labels{/name}","comments_url":"https://api.github.com/repos/eslint/eslint/issues/6659/comments","events_url":"https://api.github.com/repos/eslint/eslint/issues/6659/events","html_url":"https://github.com/eslint/eslint/issues/6659","id":165213612,"number":6659,"title":"no-use-before-define: don't report violation when the definition is in the parent scope of the usage","user":{"login":"camjackson","id":1930451,"avatar_url":"https://avatars.githubusercontent.com/u/1930451?v=3","gravatar_id":"","url":"https://api.github.com/users/camjackson","html_url":"https://github.com/camjackson","followers_url":"https://api.github.com/users/camjackson/followers","following_url":"https://api.github.com/users/camjackson/following{/other_user}","gists_url":"https://api.github.com/users/camjackson/gists{/gist_id}","starred_url":"https://api.github.com/users/camjackson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/camjackson/subscriptions","organizations_url":"https://api.github.com/users/camjackson/orgs","repos_url":"https://api.github.com/users/camjackson/repos","events_url":"https://api.github.com/users/camjackson/events{/privacy}","received_events_url":"https://api.github.com/users/camjackson/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/eslint/eslint/labels/triage","name":"triage","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-07-13T00:49:18Z","updated_at":"2016-07-13T00:49:19Z","closed_at":null,"body":"Currently using 2.10.2 with eslint-config-airbrn + a few tweaks.\r\n\r\n`no-use-before-define` is a great rule, and I definitely want to keep using it, in order to prevent code from relying on hoisting like this:\r\n\r\n```\r\nconst fivePlusOne = addOne(5);\r\n\r\nconst addOne = (x) => {\r\n  return x+1;\r\n}\r\n```\r\n\r\nHowever, to me there's a big difference between the above code, where the usage and definition are in the same scope, and the below code, where the scopes are different.\r\n\r\n```\r\nexport const addOne = (x) => {\r\n  return add(x, 1); // I want this to not violate the rule\r\n}\r\n\r\nconst add = (x, y) => {\r\n  return x + y;\r\n}\r\n```\r\n\r\nThe usage of `add` in the above code is before the definition in terms of which line they're written on. But in terms of order of execution, the definition happens when the module is loaded, but the usage isn't until the exported function is called. So it's safe regardless of hoisting.\r\n\r\nI don't want to turn this rule off, because I want to prevent the kind of hoisting shown in the first example. But to me it's much more natural to define functions in the order that they're called. With the way the rule works at the moment, I'd either need to turn my modules upside down, or ignore the rule."}}
{"actor":{"display_login":"camjackson"}}