"wasm:" scheme concerns & ESM Integration

[guybedford]

When investigating the integration of this specification with the ESM Integration in WebAssembly/esm-integration#95, where the ESM integration would ideally enable builtins by default, this has resulted in a re-raising of concerns around wasm: being treated as a scheme when used in the polyfill paths for builtins.

This was discussed in the WhatNOT meeting today, and the concern was at least confirmed that the primary issue is the reservation of the resolution of the wasm: scheme that might otherwise be later registered in browsers. Specifically that in the JS module resolution algorithm, URL parsing rules would be applied to these specifiers.

The argument being made therefore is that supporting the string builtins proposal in the ESM Integration, would likely require registering the wasm: scheme with IANA at this point.

The alternative might be to use any other string in JS String Builtins that does not parse as a URL, for example @wasm:js-string, $wasm:js-string or even something without a : like $wasm/js-string.

Some questions:

• Would a string name change still be possible at this phase of the proposal?
• Would there be interest in registering wasm: with IANA?
• Are there other approaches that might be worth considering here further for the ESM Integration?

[jakobkummerow]

Having read the entirety of WebAssembly/esm-integration#95, I honestly don't understand what the concern is. Wasm import module names can be any UTF-8 string (including the empty string), and as such can collide with anything you can think of (URLs, IP addresses, reserved keywords, operators, you name it). Even without this proposal, any Wasm module is free to use (import "http://blargh" "" ...) or (import "scheme:whatever" "*" ...) or (import "import" "break" ...). Those are just arbitrary identifier strings, they should never be eval()ed or interpreted or parsed or assumed to match (or not match) any particular regex or whatever. They should only ever be used for looking up property names on the provided imports object, where all of the above works just fine:

let imports = {
  "http://blargh": {
    "": ...,
  },
  "scheme:whatever": {
    "*": ...
  },
  "import": {
    "break": ...,
  },
};
let instance = WebAssembly.instantiate(module, imports);

If ESM integration gets confused by any of this, then it has a problem that's much bigger than "wasm:js-string". And if it can handle all of these examples, then I don't see how "wasm:js-string" is any worse.

[eqrion]

@jakobkummerow That's true with the JS-API, but with ESM-integration the browser now parses our module specifiers as URLs to actually figure out what to fetch and instantiate. So if we're using something for our builtin specifiers that parses as a URL, we're overriding the browser's logic. If someone were to create a wasm URL scheme and browsers implement it, we would have a conflict. I don't think that's likely to happen, but it's a theoretical possibility if no one has claimed the IANA scheme for wasm, which is the main concern I've heard.

The other option would be to change the specifier we use (only for esm-integration to avoid breaking anything) so that it deliberately doesn't parse as a URL.

[tlively]

If someone were to create a wasm URL scheme and browsers implement it, we would have a conflict.

But we represent browsers, so can't we just make sure this doesn't happen?

The other option would be to change the specifier we use (only for esm-integration to avoid breaking anything) so that it deliberately doesn't parse as a URL.

Would this require producers to change their output for use with esm-integration? That seems unfortunate.

[annevk]

But we represent browsers, so can't we just make sure this doesn't happen?

In principle we can do whatever, but it would be rather uncivil to squat on a URL scheme without a heads up to the larger web community (i.e., registering it).

The other argument that I don't see OP mention is that this sets a narrow precedent for built-in modules as well and as such I think it would be good to confirm that TC39 is also okay with this approach.

[eqrion]

The other option would be to change the specifier we use (only for esm-integration to avoid breaking anything) so that it deliberately doesn't parse as a URL.

Would this require producers to change their output for use with esm-integration? That seems unfortunate.

If we did this, I think the best thing would be to change the JS-API to allow either the new form (@wasm/ or whatever) or the old form (wasm:). And then only allow the new form with ESM-integration. So there'd be a one time change for a producer using ESM integration, but then going forward they would be in sync. Still gross though.

The other argument that I don't see OP mention is that this sets a narrow precedent for built-in modules as well and as such I think it would be good to confirm that TC39 is also okay with this approach.

I'm not sure I agree with this part. Wasm builtins are not visible to JS or the larger Web in any significant way. The only intersection point is around Wasm ESM-integration where we need it to be aware of them when parsing the imports. But we're not allowing JS to import wasm builtins, nor having it show up in import reflection, nor having it show up in fetch or anything like that.

We've deliberately tried to have as small a scope as possible (basically just JS specific wasm instructions) to avoid the issues that came up in the old builtin module debate. If someone tried to use wasm builtins as an argument for why general builtin modules are now okay, I wouldn't support it on that basis.

[eqrion]

I think this is something the Wasm CG should discuss, so I filed to discuss this at the next CG meeting.

[Pauan]

I think the best thing would be to change the JS-API to allow either the new form (@wasm/ or whatever)

Note that this conflicts with npm scoped packages, which use @foo/bar. And thanks to import maps, npm imports do work in the browser. So it's probably a good idea to pick a different syntax.

[rossberg]

I love how the suggestions for picking alternative syntax (and for that matter, just about everything the JS ecosystem does with import names :( ) drive the whole idea of URIs ad absurdum.

I mean, URIs were designed to address the very problem of naming diverse things in a universal and uniform manner with a standardised syntax and interpretation. Foregoing that syntax to avoid clashes is just backwards. As @Pauan's remark shows, that solves nothing really and instead just kicks the can into more anarchic territory.

We should pick a proper scheme, and do whatever is necessary to standardise it. That said, as I mentioned before, I really don't like clobbering a scheme name as broad as "wasm:" for this purpose, and would suggest something that more specifically denotes the wasm-js API.

[guybedford]

I agree with @eqrion that Wasm import specifiers exist outside of JS semantics here, and therefore while discussion in TC39 might be informative, no discussion in TC39 is required - ECMA-262 doesn't specify anything at all about specifiers or URLs. The JS ES module system spec doesn't even know what a URL is.

Therefore I would say that is an HTML integration concern only, and the JS builtins discussion, while possibly informed by this, is a separate one entirely. For example, there has never been any question from TC39 about node: or deno: being used for standard library imports in the JS ecosystem, and these JS module specifiers are already also polyfillable with import maps in all browsers themselves.

Properly specifying the scheme sounds sensible, but consensus would need to be found quite soon given the nature of the shipping implementations here.

I personally would support any approach that finds consensus to further inform the shipping ESM Integration implementations in Node.js, Deno, tools and bundlers.

[bashor]

Could we extend the spec and prohibit using "//" right after "wasm:"? Wouldn't it be enough to distinguish the cases?

[Pauan]

@bashor URLs do not require //. Since the // is optional, wasm:foo is a valid URL.

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax