Discuss
  • exports at the top of the file

exports at the top of the file

# Raul-Sebastian Mihăilă (8 years ago)

Douglas Crockford said that eventually JSLint would require exports at the top of the file. However I think there are some issues.

If my understanding is correct,

export default myConst;
const myConst = {};

would throw because when the export is evaluated, in step 2 of the Evaluation algorithm applied to the ExportDeclaration: export default AssignmentExpression; production ( tc39.github.io/ecma262/#sec-exports-runtime-semantics-evaluation), the value of the assignment expression is retrieved, which should cause an error because the binding has not yet been initialized.

I'm not sure what should happen if myConst was exported with an ExportClause.

export {myConst};
const myConst = {};

In this case, the Evaluation algorithm just returns a normal completion. But I think that it depends on when myConst is indirectly accessed in the importing modules. If it's accessed before const myConst is evaluated, then I believe it would be uninitialized and would throw. Otherwise, it would work.

Is my understanding correct?

# Logan Smyth (8 years ago)
export default myConst;
const myConst = {};

would throw because when the export is evaluated

Correct, if you wanted to export myConst as the default without that issue, you'd want to do

export {myConst as default};
const myConst = {};

to declaratively expose the binding under the default name, without requiring the value be available at the time.

The key thing to remember with exports is that they are all processed before the JS has even begin executing, and as you saw, are no-ops at execution time, aside from export default myConst which is essentially sugar for

const _hiddenBinding = myConst;
export {_hiddenBinding as default};

where the fact that a default binding exists is known at parse time. Only the value of the export is assigned at evaluation time.

> export {myConst};
> const myConst = {};
> ```


This is not an issue. Export declarations define mappings of module-local
binding names, to publicly exposed export names, and that is all, they do
not access the value in any way on their own. It's possible that if you had
some circular dependencies in your code, something could access `myConst`
before it had been initialized, and that would result in a TDZ error the
same way any other attempt to access the value would.
# Ben Newman (8 years ago)

Is it possible that Crock meant export declarations should be restricted to the top level of the file? In other words, they can't be nested in conditional blocks or inside functions, but they can appear anywhere in the outermost scope of the module?

If so, that's effectively what ECMAScript 2015 already requires: www.ecma-international.org/ecma-262/6.0/index.html#sec-modules (note that StatementListItem can never produce additionalExportDeclaration symbols).

All export declarations define some number of exported symbol names (even export defaultdeclarations, where the name is "default"). Some export declarations also declare local variables, functions, or classes, or evaluate default expressions. It's important to keep in mind that the definition of exported symbols is conceptually hoisted to the beginning of the module, while the initialization of local entities happens wherever it normally would (function declarations are also hoisted, but variables and classes are not, and of course default expressions must be evaluated in their original position, for the reasons mentioned by Logan S.).

In other words, for export declarations that only define exported symbols (e.g. export { a, b as c }), it doesn't really matter where they appear in the file, because (thanks to hoisting) it's as if you wrote them at the beginning of the file, anyway.

That's my understanding, at least :)

Ben

# Raul-Sebastian Mihăilă (8 years ago)

I don't think it was related to nesting. Anyway, I wrote to him something similar to what I wrote here and later he agreed. Thanks for confirming.