Support string module name and export * as #1336
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR we implement the support of ES2022 string module names and ES2020
export * as ns
. These two features are highly related so it end up in a single PR.Summary
.quote
is introduced toAST_SymbolImportForeign
,AST_SymbolExportForeign
andAST_SymbolExport
. It will be"
or'
if the module name is a string, otherwise it isundefined
. I am not sure if we want to stick with theAST_Symbol
prefix now that it can be a string, too. Anyway I will wait for more feedback before any drastic AST changeas_symbol_or_string
to handleexport * as "f-oo"
import { * as foo }
andimport { "*" as foo }
Limitation
The parser currently do not validate that module names should be a valid UTF16 string (no lone surrogate). It seems good to me since our parser is already a bit loose: cases like
export { * as foo } from "x"
will not throw.Fixes #1137
Fixes #1231