Self-initializing ES modules

[guybedford]

Under MODULARIZE=instance and WASM_ESM_INTEGRATION, when INCOMING_MODULE_JS_API is empty, or when -sSTRICT is passed, the ES module initializes itself via top-level await rather than exporting an init function. The named Wasm/runtime exports are ready to use as soon as the module is imported. Also works with pthreads.

Initial version used a -pTLA, but was adapted to not require a custom option since there is already existing use of top-level await.

This PR was made with AI assistance

[sbc100]

The reason we have the init function is so that the user gets a chance to configure the module via moduleArgs.

If the user doesn't want that configuration then yes we could just async initialize the module. However, I wonder if we could just ifer that intent via -sINCOMING_MODULE_JS_API=[] (which means there are not configuration points that could live in moduleArgs).

Note that -sSTRING mode already implies -sINCOMING_MODULE_JS_API=[] and I hope the make the default one day.

I'm not necessarily opposed to some kind explicit option but as always I'll try to resist adding new settings :)

[sbc100]

The argument for the option is that TLA is quite invasive, and requires the JS environment to properly support it.

In particular the major friction currently is that require() of ES Modules can't support it, so it restricts consumers to ESM only.

I'm not sure we need to worry too much about that use case. We have the ability to generate normal non-ESM modules. If somebody want to opt into ESM output, I think its fair to assume they will be consume it as an ESM module.

Also, the majority of our users are targeting the web where require() is not a thing anyway right?

[guybedford]

Agreed, ok, I've refactored this PR to be based on -sSTRICT / empty INCOMING_MODULE_JS_API option. This makes it now formally a breaking change, but I suppose we can do this under the experimental option.

[sbc100]

Agreed, ok, I've refactored this PR to be based on -sSTRICT / empty INCOMING_MODULE_JS_API option. This makes it now formally a breaking change, but I suppose we can do this under the experimental option.

Great.

@brendandahl WDYT? Is this too magical to automatically opt-out of the init() function like this? Obviously too much magic is bad, but also adding a new setting such for this would be bad too.