-
Notifications
You must be signed in to change notification settings - Fork 892
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
Conversation
Inspired by the equivalent Babylon method: https://github.com/babel/babylon/blob/22741a8068d436a54811fc77ae7f60b7e6404a79/src/tokenizer/index.js#L87-L98 Functionally equivalent to the LooseParser method of the same name: https://github.com/ternjs/acorn/blob/1ecf4f737df99592372e517a8f7d09a6c125bc9f/src/loose/tokenize.js#L107
As proposed here: https://github.com/leebyron/ecmascript-export-default-from https://github.com/leebyron/ecmascript-export-ns-from These extensions are enabled only when options.exportExtensions is truthy.
As proposed here: https://github.com/leebyron/ecmascript-export-default-from https://github.com/leebyron/ecmascript-export-ns-from These extensions are enabled only when options.exportExtensions is truthy.
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)
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. |
Ok, that's fair. I'll keep rebasing this branch periodically until these proposals reach stage 4. |
👌 They're currently stage 1. I have high hopes they'll advance since they aren't super controversial. |
Perhaps @leebyron would like to offload some of his championship responsibilities? 😉 |
Now that export-ns-from has TC39 consensus we should revisit this in acorn. Update: Opened #742. |
I still see 'stage 1' on the proposal? |
@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. |
All right, but stage 3 is still not stage 4 |
This pull requests adds support for parsing two new
export ... from
syntaxes:as proposed here, and
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 existingexport
syntax.cc @jdalton @RReverser