Async module resolver

[mk-pmb]

I couldn't find any issue for "async resolver", so I think we should at least track efforts in this direction.
For node.js, a proposal is here: "Add async alternative to import.meta.resolve() with additional options"
Not sure why it isn't picked up, for me it's obviously useful, so maybe it's just the concerns about how to keep the interface compatible and future-proof. Which sounds like a task for our working group here.

[andreubotella]

My understanding was that browsers, Deno and Cloudflare Workers don't need an async module resolver, because module resolution can never block in those runtimes. The only reason module resolution is asynchronous in Node.js is because ESM loaders run in a different thread, so if there are loaders, resolution must wait for messages from the loader thread.

@nicolo-ribaudo I think the JS modules harmony effort aims to end up having something like module loaders in the language itself, right? Would those run in the same thread?

[nicolo-ribaudo]

@nicolo-ribaudo I think the JS modules harmony effort aims to end up having something like module loaders in the language itself, right? Would those run in the same thread?

Yes, but they don't deal with resolution. They are (importer,specifier)->imported mappings. Resolution remains host-defined.

[mk-pmb]

The second bulletpoint in the features requested there is

• The tool might want to specify import conditions, which are non-standard

Is that worth considering?

[andreubotella]

The second bulletpoint in the features requested there is

• The tool might want to specify import conditions, which are non-standard

Is that worth considering?

@Ethan-Arrowood Import conditions are related to runtime keys, right? Would that make sense to add?

[nicolo-ribaudo]

Fwiw, it wouldn't be unreasonable to pass a comma-separated list of import conditions as an import attribute.

[Ethan-Arrowood]

I believe so yes. I think it would be nice to include.