no-use-before-define false positive with binding exports

[Jessidhia]

Tell us about your environment

• ESLint Version: 3.12.2
• Node Version: 7.2.0
• npm Version: (yarn) 0.18.1

What parser (default, Babel-ESLint, etc.) are you using?

babel-eslint

Please show your full configuration:

// too big, relevant part
module.exports = {
  parser: 'babel-eslint',
  parserOptions: {
    sourceType: 'module'
  },
  rules: {
    'no-use-before-define': ['error', {functions: false, classes: false}]
  }
}

What did you do? Please include the actual source code causing the issue.

export { group as default }
const group = new Set()

What did you expect to happen?

No warnings.

What actually happened? Please include the actual, raw output from ESLint.

   1:10  error  'group' was used before it was defined       no-use-before-define

---

Binding exports do not read the variable, so they do not cause TDZ errors.

Note that, when circular imports are involved, it is possible to cause a TDZ error by accessing an export whose binding is still in TDZ, but that would happen regardless of the position of the export binding.

Also note that only binding exports should not be errors. export default should error as it is a value*, not a binding:

export default Group // ReferenceError
class Group {}

[*]: it is a binding when exporting FunctionDeclaration or ClassDeclaration, but those are already correctly handled, in the export default case, by the rule with the appropriate options.

[mysticatea]

I confirmed it from the spec. ExportDeclarations seem to do nothing at runtime if the following cases.
But I want other eyes since I don't have confidence (especially static behaviors).

ExportDeclaration:
　　export * FromClause;
　　export ExportClause FromClause;
　　export ExportClause;

Return NormalCompletion(empty).

https://www.ecma-international.org/ecma-262/7.0/#sec-exports-runtime-semantics-evaluation

[not-an-aardvark]

@ljharb Do you happen to know the correct behavior for this?

[ljharb]

My initial impression was that the last example should work just fine. However, I think @Kovensky is correct - export default takes a value, not a binding, and since class Group {} hoists a binding under TDZ, export default Group would indeed trigger a reference error. However, export { Group } at the top would not, because that exports the binding, and it's only upon unpacking that binding that the TDZ error would occur.

I can't speak to the spec text since grammar stuff isn't my specialty, but this is now my intuition having thought it through.

[not-an-aardvark]

Closing this issue since the consensus in the PR was that the current default behavior is correct.