String Constants Bikeshed

@eqrion

As discussed at the CG meeting today, it might yet be possible to specify a string constant for the ESM Integration.

Opening the bikeshed here for the current main suggestions, which I believe are:

wasm:js-string
wasm-js:strings

The slide on this topic is here for more details on the discussion.

@eqrion please let me know if I've got this correct or if there are changes or other suggestions that should be considered.

@conrad-watt I believe you had some more thoughts here from the presentation.

Suggestions / feedback very much welcome.

@lukewagner

Cross-posting @lukewagner's comment from #115:

Just my 2c on wasm: vs wasm-js:: although longer, wasm-js is attractive since it makes it clear from both a JS/ESM and wasm perspective that we're talking about "JS built-ins exposed to wasm" and keeps wasm: open for hypothetical pure-wasm builtins as well as non-JS builtins exposed to wasm.

@lukewagner

To restate from the meeting, I originally had some hesitation around specifying the import name for string constants before we knew if the compact import section proposal would be standardized. If it is standardized, we want a pretty name here. But if it's not standardized, we'd want a short name for binary savings.

But I now think that one path forward would be to choose the longer prettier name now, and then consider adding an alias for a short name in a future where the CG rejects compact imports (if that happens).

So back to the question of what name to use.

We have precedence of using wasm:js-XYZ from the original js-string-builtins proposal. js-primitive-builtins is also using that format, but is in development and could be changed. If we choose a different format here, we should probably add an alias for js-string-builtins to match the new one.

@lukewagner I hear the concern about using the wasm: scheme for just 'pure-wasm' builtins. I'm not sure I like using wasm-js: though, because that doesn't seem scalable for future embedding specific builtin collections. Would we require component builtins to reserve their own scheme like wasm-component:? Or wasm-python:?

I wonder if we could use URL paths here and create a hierarchy to group builtins. So we could have wasm:js/string, and hypothetically wasm:component/ or wasm:python/. While still reserving the root paths for core wasm builtins.

Regardless of the scheme, I think the name should be something like string-constants. Which would give us either wasm:js-string-constants, wasm:js/string-constants, or wasm-js:/string-constants.

We have precedence of using wasm:js-XYZ from the original js-string-builtins proposal. js-primitive-builtins is also using that format, but is in development and could be changed.

There's also custom descriptors, which defines wasm:js-prototypes.

I have been tentatively considering using wasm-js: here for things which are "JS conventions" and not actually even builtins.

That is - in the (unlanded) phase integration proposal (#117) I was using wasm-js:phase/foo to indicate a phase import in the second-level import string as a special reserved string that doesn't imply a builtin but rather implies a JS convention, separate from wasm:js-string providing an actual builtin.

For the string constant here, then thinking of the string constant less of a builtin itself and more of a naming convention such that wasm-js: might make sense.

In this framing:

wasm: formally specified builtins within Wasm specs
wasm-js: ESM-integration or JS-API specific conventions only.

For example (and certainly not proposing it now), we might also imagine some hypothetical future wasm-js:global/WebAssembly to get an externref for the WebAssembly global say.

Maybe this framing doesn't make sense though and I'm also completely fine with dropping this idea though and just going with wasm:js-string/constants too, but since we had wasm-js and while we're doing the bikeshed let's do it well I guess.

As for wasm:js/, wasm:component/, wasm:python/ style builtin structuring, that seems othogonal to these convention considerations and absolutely fine to me as well.

My preference would be pretty much equal between say wasm-js:string-constants or wasm:js-string/constants though.

@eqrion

@eqrion That's a good point about the proliferation of wasm-${X}: schemes; wasm:${X}/ seems like a totally reasonable alternative.

@guybedford

@guybedford I don't think we need to use the scheme to make a distinction between 'JS builtins' and 'JS conventions'. For the phase example you could use wasm:js/phase/source just as well.

I think my preference going forward would be for everything defined in the wasm spec or wasm embedder specs (like the JS-API) to use the plain wasm: scheme, and then group all embedder specific things into a single path. Any core wasm feature usable for all embedders could claim something in the root path.

So we would have:

// js-string-builtins
wasm:js/string
wasm:js/string-constants

// js-primitive-builtins
wasm:js/number
wasm:js/boolean
...

// custom-descriptors
wasm:js/prototypes

cc @tlively as someone working on something that uses the wasm scheme.

Sure, agreed with aligning on wasm: here then and avoiding wasm-js: for now. Let's please ensure wasm:js/string-constants is an exception to most other builtins though in using a kebab name, to rather prefer hierarchical wasm:js/string/feature style imports for sub modules for most situations.

Given the above, will we want to go through the re-aliasing process here on the builtins proposals into wasm:js/? Primitive builtins can likely be updated in the proposal, but string builtins would require a PR at this point?

I've updated the PR in #115, would value a review there.

cc @tlively as someone working on something that uses the wasm scheme.

I'm happy with anything. Settling on wasm:a/b... for everything sounds fine. Having to add aliases for the existing builtins is a little unfortunate, but well worth it to have a settled convention everyone is happy with using going forward.

@tlively

Sure, agreed with aligning on wasm: here then and avoiding wasm-js: for now. Let's please ensure wasm:js/string-constants is an exception to most other builtins though in using a kebab name, to rather prefer hierarchical wasm:js/string/feature style imports for sub modules for most situations

Ah, I wasn't really thinking of string constants as a 'sub module', but that makes sense to me. I'd be happy to go with wasm:js/string/constants too.

@tlively

Having to add aliases for the existing builtins is a little unfortunate, but well worth it to have a settled convention everyone is happy with using going forward.

Yeah, agreed it's not ideal. It's currently just a single mapping for wasm:js-string to wasm:js/string` so it's hopefully not too disruptive.

I realised today reading the text encoding/decoding spec that the discussion resolution here is not as clear as it should be, so wanted to summarize the outcome, which has now been landed into this spec:

The decision was made here to prefer wasm:js/ over wasm-js: for JS builtins going forward. The reason for this is to avoid scheme proliferation for non-js builtins. wasm-js: therefore remains currently unused, although it may be beneficial in conventions like the suggestions in Integration with import attributes #42.
New builtins should use the wasm:js/[name] pattern going forward.
Whether existing builtins will be re-aliased to use wasm:js/[name] still needs further discussion.

It might be worth bringing the above up in the CG as well to ensure we have clear guidance going forward.

Navigation Menu

Repository navigation

String Constants Bikeshed #118

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

String Constants Bikeshed #118

Description

Activity

guybedford commented on Oct 29, 2025

eqrion commented on Nov 3, 2025

sjrd commented on Nov 3, 2025

guybedford commented on Nov 5, 2025

lukewagner commented on Nov 6, 2025

eqrion commented on Nov 10, 2025

guybedford commented on Nov 10, 2025

tlively commented on Nov 10, 2025

eqrion commented on Nov 13, 2025

guybedford commented on Apr 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions