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.

[guybedford]

I'm aiming to post up the Node.js implementation soon and this question is now coming up again in implementation work - I think we do need to make a decision here at this point as once source phase implementations start shipping it will get harder to reserve names.

I agree import attributes could be used to configure this property, and that it would also be nice not to have to rely on that.

Using the empty string "" is actually not possible since it will throw in instance imports (i.e. they aren't supported in import map resolutions).

Should we define something here? Something like wasm:strings or wasm:string_constants? Has there been progress on compact imports?

[eqrion]

@guybedford No progress on compact imports yet, unfortunately.

What do you think about the suggestion to have ESM-integration reserve a wasm: prefix so that we throw when any import uses it? This would give us the ability to later claim anything in that space for string constants. This would be useful not just for string constants, but for any new builtins we'd want to claim.

[kmiller68]

What do you think about the suggestion to have ESM-integration reserve a wasm: prefix so that we throw when any import uses it? This would give us the ability to later claim anything in that space for string constants. This would be useful not just for string constants, but for any new builtins we'd want to claim.

I like this idea generally although, IIUC, it gets a bit tricky when poly-filling for older browsers. One option could be to have a custom section for ESM that provides a different identifier to import from if wasm:foo doesn't exist?

[guybedford]

This makes a lot of sense as the approach, sure. I've posted https://github.com/WebAssembly/esm-integration/pull/95.

[guybedford]

This has now been resolved in https://github.com/WebAssembly/esm-integration/pull/95 with tests in https://github.com/WebAssembly/esm-integration/pull/110.