Put an enum here so that we can support https://github.com/tc39/proposal-asset-references in the future. See also https://github.com/tc39/proposal-import-reflection#dynamic-import.

currently type-aware imports use importKind to specify this.
I.e.

import type foo from 'foo' has importKind: 'type'
import typeof foo from 'foo' has importKind: 'typeof'

Should we align with these or introduce a new property entirely?
Do we foresee cases where you might do import type module foo from 'foo'?

I though about importKind, currently Babel specifies importKind: "value" for non-type imports. If we put importKind: "module" here, we should either add importKind: "value" to vanilla import declarations. But since the addition here is not backward-compatible, we have to recognize importKind: undefined | null, too.

'import type module foo from 'foo'

I don't think it is valid. I have gone ahead and banned this production in Babel.

We could spec that importKind: null | undefined is the same as importKind: 'value' for backwards compat.

The asset reference spec currently is asset Foo from "foo"; without import - would we use the ImportDeclaration node for it or wouldn't it live as its own, separate node?

The asset reference spec currently is asset Foo from "foo"; without import - would we use the ImportDeclaration node for it or wouldn't it live as its own, separate node?

Yes, you are right. Though authors of import reflection suggest that proposal reuse the import reflection syntax:

import asset x from "<specifier>";
await import("<specifier>", { reflect: "asset" });

Anyway both proposals are still early so we could change the AST if the syntax change.

Although import type module foo from 'foo' makes no sense, import typeof module Foo from './foo.wasm' potentially works. In this case Foo can be the type of webassembly modules. If we are going with importKind: "module", we also rule out the possibility that import typeof module might be a thing.

@nzakas Any opinion?

It seems like reflection is a cleaner solution to the problem than importKind is at this point. I’m not a fan of null|undefined being equivalent to “value”.

The "reflection" word is likely to be removed from the proposal, since there have been concerns about the assimmetry between import module x from "y" and import("y", { reflect: "module" }). It's quite possible that the proposal will instead be import module x from "y" and import("y", { module: true }).

What do you think about removing it from the AST too, and using something like this?

extend interface ImportDeclaration {
    module: boolean
}

This PR is introducing an enum attribute which can either have a specific value or be absent: that's two possible states - a boolean.

If TC39 will start working again on the asset references proposal and if it's updated to use the import asset ... syntax, we can then either:

• add an asset: boolean, specifying that asset and module cannot both be true;
• change the ast back to use reflection: "module" | "asset" | null - it's a "real enum" with multiple possible values, and it makes now sense to have it string-based.

@nicolo-ribaudo Thanks for the insider info. I will update the AST accordingly.