exports at the top of the file

Logan Smyth loganfsmyth at gmail.com
Tue Jun 7 04:58:26 UTC 2016


>
> ```js
> 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.

```js
> 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.


On Mon, Jun 6, 2016 at 9:39 PM, Raul-Sebastian Mihăilă <
raul.mihaila at gmail.com> wrote:

> 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,
>
> ```js
> 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 (
> https://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.
>
> ```js
> 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? Thanks!
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160606/2987ca6b/attachment.html>


More information about the es-discuss mailing list