Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normative: Add export * as ns from "mod” to Export production and Module Semantic #1174

Merged
merged 1 commit into from Oct 2, 2019

Conversation

@spectranaut
Copy link

@spectranaut spectranaut commented Apr 17, 2018

This PR adds export * as ns from "mod" updates from tc39/proposal-export-ns-from to the spec as part of the July 27, 2017 notes. This PR replaces and expands this PR: #1005

To see an updated diff of the new spec changes, you can look here: https://spectranaut.github.io/proposal-export-ns-from

Tests partially complete.

Closes #1005.

@spectranaut spectranaut changed the title Add export * as ns from "mod” to Export production and Module Semantic Normative: Add export * as ns from "mod” to Export production and Module Semantic Apr 17, 2018
spec.html Outdated Show resolved Hide resolved
spec.html Outdated Show resolved Hide resolved
@spectranaut
Copy link
Author

@spectranaut spectranaut commented Apr 18, 2018

I updated table 38 based on the modifications made for export * as namespace but would like if someone review/read for clarity and word choice - I feel awkward editing editorial text: https://spectranaut.github.io/proposal-export-ns-from/#table-38

@ljharb ljharb requested review from jdalton, bterlson and bmeck Apr 18, 2018
@leobalter
Copy link
Member

@leobalter leobalter commented Apr 18, 2018

Looks good to me, if you want to bikeshed over the new additions:

- A List of ExportEntry records derived from the code of this module that correspond to reexported imports that occur within the module or direct exports from an export * as namespace.
+ A List of ExportEntry records derived from the code of this module that correspond to reexported imports that occur within the module or exports from export * as namespace declarations.
- A List of ExportEntry records derived from the code of this module that correspond to export * declarations (but not export * as namespace declarations) that occur within the module.
+ A List of ExportEntry records derived from the code of this module that correspond to export * declarations that occur within the module except from export * as namespace declarations.

@spectranaut
Copy link
Author

@spectranaut spectranaut commented Apr 20, 2018

@ljharb -- you might want to "re-review", I changed how export * as namespace declarations ResolveBinding records are made. I removed the [[isNamespace]] I added and instead the [[BindingName]] is "*namespace*" in these scenarios (as there is actually no binding for the namespace). I tried to update more editorial text to make it clear.

you can see the updated pretty diff here: https://spectranaut.github.io/proposal-export-ns-from/#sec-module-namespace-exotic-objects

ljharb
ljharb approved these changes Apr 27, 2018
@ljharb
Copy link
Member

@ljharb ljharb commented Jun 28, 2018

@spectranaut would you mind rebasing this? it'd also be great if we could add this to the agenda for july, now that its tests are merged.

@leobalter
Copy link
Member

@leobalter leobalter commented Sep 27, 2018

Expressing that we have consensus to move forward on this feature but we are waiting on vms to implement this feature before it's merged. Similar to the stage 3 process. Test262 tests are already available, and I'll be happy to point them.

@spectranaut
Copy link
Author

@spectranaut spectranaut commented Oct 5, 2018

Rebased, @ljharb :)

wincent added a commit to liferay/liferay-npm-tools that referenced this issue Oct 4, 2019
This enables the `@babel/plugin-proposal-export-namespace-from` plugin:

https://babeljs.io/docs/en/next/babel-plugin-proposal-export-namespace-from.html

Which allows Babel to process:

    export * as X from './x';

This is proposal is at Stage 4:

    https://github.com/tc39/proposal-export-ns-from

and got merged into ECMA-262 already:

    tc39/ecma262#1174

Without this, we can write the above example as:

    import * as X from './x';
    export {X};

which is ok, but obviously not as nice. Example commit where I'm
employing exactly that workaround:

    wincent/liferay-portal@f41f93d
jmdyck added a commit to jmdyck/ecma262 that referenced this issue Oct 5, 2019
PR tc39#1174 introduced the nonterminal 'ExportFromClause',
but didn't reference it from Annex A.
jmdyck added a commit to jmdyck/ecma262 that referenced this issue Oct 5, 2019
PR tc39#1174 introduced the nonterminal 'ExportFromClause',
but didn't reference it from Annex A.
ljharb added a commit to jmdyck/ecma262 that referenced this issue Oct 6, 2019
 - Add a subscript R: Since _intValue_ is to be treated as a mathematical value, we should be comparing it to a mathematical zero.
 - Reinstate 'sec-static-semantics-elisionwidth' as an oldid; tc39#1124 removed the element-id 'sec-static-semantics-elisionwidth'
 - Reinstate 'sec-synchronizeeventset' as an oldid; tc39#1692 removed the element-id 'sec-synchronizeeventset'.
 - Reference 'ExportFromClause' from Annex A; tc39#1174 introduced the nonterminal 'ExportFromClause', but didn't reference it from Annex A.
 - Put asterisks around 'true' (from tc39#1716)
 - Fix typo "_eventRecords_" -> "_eventsRecord_" (from tc39#1692)
KFlash added a commit to meriyah/meriyah that referenced this issue Nov 5, 2019
gnomesysadmins pushed a commit to GNOME/gtksourceview that referenced this issue Jan 17, 2020
This was not considered a "proposal" but is still new syntax for ES2020.

References:
* tc39/ecma262#1174
* https://github.com/tc39/proposal-export-ns-from
@jugglinmike jugglinmike mentioned this pull request Jul 2, 2020
7 tasks
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jul 16, 2020
Add support for `export * as ns from "a";` syntax. This was added in
ECMAScript 2020.

One wrinkle in the implementation is that the parser decides whether to use a
lexical vs indirect binding before module linking. Instead, we reserve a
hidden environment slot called "*namespace*" for each module that can be
referenced by indirect binding maps as needed.

Spec is a needs-consensus PR at tc39/ecma262#1174

Depends on D80984

Differential Revision: https://phabricator.services.mozilla.com/D80777
xeonchen pushed a commit to xeonchen/gecko that referenced this issue Jul 17, 2020
Add support for `export * as ns from "a";` syntax. This was added in
ECMAScript 2020.

One wrinkle in the implementation is that the parser decides whether to use a
lexical vs indirect binding before module linking. Instead, we reserve a
hidden environment slot called "*namespace*" for each module that can be
referenced by indirect binding maps as needed.

Spec is a needs-consensus PR at tc39/ecma262#1174

Depends on D80984

Differential Revision: https://phabricator.services.mozilla.com/D80777
Copy link

@hiramtibbit hiramtibbit left a comment

A

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet