Repository navigation
[deferred-reexports] Add import { x, y } as ns support - #340
nicolo-ribaudo wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
For the name here I'd align with whatever the outcome of tc39/proposal-deferred-reexports#39 is (and you are welcome to share opinions :) )
There was a problem hiding this comment.
The exportsFilter, or simply filter, both look good to me.
Will import { foo as bar } as ns from "./lib" ever be a thing? If so I suggest we use ImportSpecifier for exportsFilter.
The current proposed structure serves the current proposal well, but if there is ever a proposal extending the current syntax, there is not much room to nicely extend.
There was a problem hiding this comment.
I'm looking into this again, and there are no plans for foo as bar as it has significant implementation complexity without benefits (aliasing exists to avoid conflict when importing the same name from multiple modules, which doesn't apply here). It's however good to allow extensibility just in case, and so that I can produce a nice AST in Babel's error recovery mode :)
If we want to use a node, ImportSpecifier doesn't really work: because the "local" part can be a string here (import { "str" } as ns from "x"). I could use ExportSpecifier maybe? Even though the exported property name doesn't really work. Or we introduce a new node type (NamespaceFilterSpecifier) like ImportSpecifier but that has only .imported and no .local.
Regarding the name, the proposal ended up with exports for dynamic import (import("foo", { exports: ["a", "b"] }). I think I still prefer to call the AST property exportsFilter, for clarity.
There was a problem hiding this comment.
Thank you. If future extensibility is not the plan, then I am good with the current design. As for Babel's error recovery, we could still try to parse an Importspecifier if we see as after the exportsFilter, without the specifier wrapper.
nicolo-ribaudo
changed the title
import { x, y } as ns support
Co-authored-by: Huáng Jùnliàng <jlhwung@gmail.com>
2 participants
This is adding AST for this syntax:
introduced by https://tc39.es/proposal-deferred-reexports/#sec-imports. More info is in the TC39 presentation that introduced the syntax: https://docs.google.com/presentation/d/1uYgMUqz5bZT3wwPARnyq7GrJlWFesIrmoCJA1iDH3W8/edit?slide=id.g3965d76ffd6_0_22#slide=id.g3965d76ffd6_0_22
I also need to add support for
export { x, y } as ns from "foo", however depending on the outcome of #339 I see two possible options. If we reuseImportNamespaceSpecifierforexport * as ns from "x"then there is nothing to do, otherwise if theExportAllDeclarationgets a.specifier: Identifier | Literalfield, I'd also add it toExportNamedDeclarationfor this proposal.