Normative: make non-USV import strings a syntax error

[guybedford]

Just like export name strings must be valid well-formed unicode strings, this adds a SyntaxError for import specifier strings which are invalid unicode.

While this is a normative change, it is hard to imagine it being a breaking one. At the very least, opening for discussion - having module specifiers / module IDs as valid unicode seems a desirable property.

[bakkot]

What's the motivation for this?

[guybedford]

@bakkot Wasm modules only support USV string imports, so that in the ESM integration not all specifiers would be compatible at a strictly theoretical level.

[michaelficarra]

I'm not against this, but that motivation doesn't make sense to me. @guybedford Can you explain in more detail or with examples?

[guybedford]

@michaelficarra this is mostly a correctness issue over there being a tangible use case, although it's difficult to predict if there might be some tangible use case in future. Specifically, in WebAssembly modules, the import strings that are used to work the same like import 'mod' in the ESM integration are validated in WebAssembly modules to only be valid UTF strings. Thus, in theory Wasm imports are a subset of JS imports in this way. When @bmeck added string exports to get Wasm parity (export { a as "a" } kind of thing), this included a well-formed string validation step to match Wasm as well. So I was just investigating whether we should do the same for JS imports from a purity perspective.

[michaelficarra]

@guybedford The string exports (and associated USV validation) makes sense because those two things (JS exports and wasm imports) interact. Wasm module specifiers and JS module specifiers don't interact. At least I don't understand how they do. So you're just trying to have their design match for purity's sake? That's pretty weak motivation.

Still, this artificial limitation doesn't seem like it would hurt anything, I just don't see how it might help anything.

[ljharb]

Can you have a JS source code module that exports something under a non-well-formed name?

[bakkot]

This isn't about the names of the exports - it's about module specifiers. At least if I understand the goal correctly.

(The answer to your question as stated is no, though.)

[bakkot]

Also, if we do this we should also probably add a similar error for import().

Incidentally, right now (if I'm reading it right) HTML already requires that unpaired surrogates in module specifiers get replaced with U+FFFD (REPLACEMENT_CHARACTER) before hitting the network.

[guybedford]

@bakkot it sounds like an alternative might also be to pass the string through toWellFormed then?

[bakkot]

@guybedford Yup, though if we're going to change things I think I'd lean towards just making them illegal outright, as you propose; then we can update HTML so that it knows specifiers are already well-formed.

(HTML actually has a bug right now where it passes specifiers, which are not constrained to be well-formed, into an algorithm which is typed to only accept well-formed strings. Turns out I was not reading it right in my previous comment.)