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

Support parsing ExportDefaultSpecifier and ExportNamespaceSpecifier #541

Closed

Conversation

benjamn
Copy link

@benjamn benjamn commented Apr 24, 2017

This pull requests adds support for parsing two new export ... from syntaxes:

// New ExportNamespaceSpecifier syntax:
export * as ns from "module"

// Equivalent to:
import * as _ns$0 from "module"
export { _ns$0 as ns }

as proposed here, and

// New ExportDefaultSpecifier syntax:
export def from "module"

// Equivalent to:
import _def$0 from "module"
export { _def$0 as def }

// Also equivalent to:
export { default as def } from "module"

as proposed here.

Note that the _foo$0 identifiers above are meant as unique temporary variables that are no longer necessary with the new syntax.

Babylon also parses these syntaxes, so you may want to examine Babylon's output in ASTExplorer to compare it with the tests included in this pull request.

The proposals are not especially controversial, and are unlikely to change as far as the parser is concerned. However, the proposals are not yet final, so it seemed like a good idea to keep them behind the options.exportExtensions flag, even though these changes should be backwards-compatible with all existing export syntax.

cc @jdalton @RReverser

@benjamn
Copy link
Author

benjamn commented Apr 24, 2017

Here's the Babylon version of this functionality, for reference.

This is equivalent to

  import * as _temp$0 from "module"
  export { _temp$0 as default }

Related Babylon issue:
babel/babylon#469 (comment)
@marijnh
Copy link
Member

marijnh commented Apr 24, 2017

Hi. Please implement and distribute this as a plugin until the proposal gets to a later stage. To avoid the headache of tracking changing proposals, we're not putting anything in the main distribution until it reaches stage 4.

@marijnh marijnh closed this Apr 24, 2017
@benjamn
Copy link
Author

benjamn commented Apr 24, 2017

Ok, that's fair. I'll keep rebasing this branch periodically until these proposals reach stage 4.

@jdalton
Copy link
Contributor

jdalton commented Apr 24, 2017

👌 They're currently stage 1. I have high hopes they'll advance since they aren't super controversial.

@benjamn
Copy link
Author

benjamn commented Apr 24, 2017

Perhaps @leebyron would like to offload some of his championship responsibilities? 😉

@jdalton
Copy link
Contributor

jdalton commented Oct 5, 2018

Now that export-ns-from has TC39 consensus we should revisit this in acorn.

Update:

Opened #742.

@marijnh
Copy link
Member

marijnh commented Oct 5, 2018

I still see 'stage 1' on the proposal?

@jdalton
Copy link
Contributor

jdalton commented Oct 5, 2018

@marijnh That is incorrect. Reviewing the notes from the Sept TC39 meeting consensus was established on a Stage 3 manner, which will then be merged once implementations are there.

@marijnh
Copy link
Member

marijnh commented Oct 5, 2018

All right, but stage 3 is still not stage 4

@jdalton
Copy link
Contributor

jdalton commented Oct 5, 2018

@marijnh Could we please move comments to #742.

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

Successfully merging this pull request may close these issues.

3 participants