How ImportObject works with ESM?

[xtuc]

I don't think this is an issue with the current spec but rather a convention in the tooling (but still wanted to discuss about it).

For context, here's the definition of a module import:

We can easily map that into ESM:

• module is a ES module
• name the identifier used in the ExportDeclaration of the module.

If the notion of module has the same semantics as ES Module it should be possible to include modules directly from npm as well as local files (or custom rules defined by bundlers).

Here's my issue

When using emscripten (for example) the imports of the wasm modules are using the env or global module, which can't be found using the current bundlers (since they will resolve it to an npm module, note that it's even dangerous).

While there's not reason to prevent using npm modules we should refer to local files first. I can see a few solutions for that problem:

• Bundlers could search for local files before searching on npm.
• Emscripten could use ./env and ./global instead (impacts manual usage).
• Extra linking phase that changes the name of the modules.

"Bundlers" means currently Webpack and Rollup in the future.

[lukewagner]

The current default output of Emscripten isn't really ESM-compatible; it's expecting to be instantiated manually by a containing .js glue file and so I think there would be more issues than just the naming of env. Emscripten has a lot of flags for adapting output, though; @kripken / @dschuff, is there anything at the moment that is more ESM-compatible?

[kripken]

Sounds like the context here is that ./ prefixes would make sense when the wasm imports an ES module for env/global? Makes sense to me if so.

For emscripten js output the general goal is to have the "modularize" option emit an ES module (right now it emits a function with clear imports/exports but is not ESM yet). I'm not sure how that would work with it being imported by the wasm, I don't think anyone has had time to think about that yet.

[xtuc]

Emscripten is an example, currently nobody considers that.

Also cc @dcodeIO @ballercat

[linclark]

@xtuc I see you reopened this, but I'm not sure what issue needs to be resolved here. This seems like an issue with module resolution algorithms. Is that correct? If it is, then that is an issue being handled in other WGs and would be outside of the scope for this WG.

Closing for now, but if the issue is something in scope for this proposal we can reopen.