[Feature Request] Support building for both UMD/ESM about emscripten

[sbc100]

How hard do you think it would be to make a module that works in both of these environments? Is it worth adding yet anther setting or should we just try to make the ES6 output UMD compatible?

Out of interest what is the platform you are targeting that requires UMD compat?

[fs-eire]

How hard do you think it would be to make a module that works in both of these environments? Is it worth adding yet anther setting or should we just try to make the ES6 output UMD compatible?

Out of interest what is the platform you are targeting that requires UMD compat?

I don't think the idea that one module supporting both UMD and ESM can work, because reference to import (eg. import.meta.url) will cause an syntax error if not in ESM.

The reason why I want to distribute a UMD bundle is because of bundler compatibility. There are 2 reasons:

• A ESM module can import a CJS module and bundler can do this correctly; but it is very hard to import ESM in a CJS module.
• Currently some bundlers (Webpack, parcel, ..) will rewrite import.meta.url into static strings like "file:///path/to/build/time/file.js". This will make the Emscripten generated code not working.

As a library author, the best option for me is to offer 2 exports - one for UMD and one for ESM. This is why I created this issue.

[fs-eire]

BTW it would be great if Emscripten can support generate multiple targets at one build (not only UMD/ESM). In my use case, I acutally need 4 targets:

• output.js (umd, ENVIRONMENT=web,webview,worker)
• output.mjs (esm, ENVIRONMENT=web,webview,worker)
• output.node.js (umd, ENVIRONMENT=node)
• output.node.mjs (esm, ENVIRONMENT=node)

I am currently using Regex to replace the code snippet in generated files in order to exclude Node.js outputs for web. This is very hacky and unstable because with the upgrade of emscripten the old regex may no longer work.

You may be interested in why I don't use default. Because default supports both web and node, right? The reason is the bundler again:

• Bundler is not happy with await import("module") even it is guarded by condition isNode.
• Tree shaking is not working with the variable of IS_ENVIRONMENT_NODE

[fs-eire]

I would share a viewpoint from a library developer: some requirement above is not a problem of Emscripten, they are more like the problem of bundler. However, we cannot control or predict how users use bundler. If bundler has a bug or an unexpected behavior, we can track the bugfix but at the same time we need to workaround to offer user the out-of-box experience.