Integration with JS String Builtins

[guybedford]

The expected integration with JS String Builtins is that this feature would be turned on for the ESM Integration.

During the update at the WasmCG today the question was brought up what string constants builtin would be used here. Specifically a special import name must be declared at compile time, and the actual list of string constants must be provided at instantiation time.

We may need to consider:

1. Using a default name for the string constants import (previously this was " but could be anything else defined in the ESM integration)
2. Whether import attributes can provide configuration for string constants. Perhaps this import attribute be used to define the name of the string constant import, or it could even allow defining the string constants themselves in the instantiation.

@eqrion feel free to add further context here.

[eqrion]

Thanks for filing this, those both match what I'd expect we could do here.

Trying to find a good default name for the string constants import was difficult. I would prefer it not to be "'" if we could avoid it, but the feedback I've been given is that the binary size increase would make this prohibitive.

I'm championing a compact-import-section proposal that could solve this. But it's very early (no explainer even yet), so it's not much help here.

How would you feel with making the default be that esm-integration does not enable the importedStringConstants feature at all? Then we could add an import attribute (possibly later) that enables it with a given name. (e.g. { importedStringConstants: "XYZ" }).

Users could still import strings using the other mechanisms discussed here, but if they want the most optimal/advanced method they would need to add an import attribute.

[lukewagner]

Disabling string constants until there is a good solution as a conservative first step makes sense, I think. But to enable it, could we have a single-fixed JS API-defined module-string, with binary size issues addressed by the compact-import-section proposal? Requiring an import attribute just for this technicality seems unfortunate.

[eqrion]

Disabling string constants until there is a good solution as a conservative first step makes sense, I think. But to enable it, could we have a single-fixed JS API-defined module-string, with binary size issues addressed by the compact-import-section proposal? Requiring an import attribute just for this technicality seems unfortunate.

That would also be fine with me. Just checking my understanding, at this later point we could pick anything in the wasm: namespace without possibly breaking any code, because wasm esm-integration effectively would 'reserve' the whole 'wasm:' namespace for only wasm stuff.