1840723 - Redesign Import Attributes Host Hook for Extensibility

Status: NEW

(Core :: JavaScript Engine, enhancement, P4)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

The currently defined host hook is sort of silly because at best we could have embedders remove the set of supported assertions... but considering we only support one assertion, this is of limited use.

In the short term I plan to remove the host hook, but it would be nice to bring it back if we could design it for better extension than we currently have. I suspect the way to do it would be to have it no longer use an enum but rather a vector of Ids.

Comment 1

[Jon Coppeard (:jonco)]

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #0)
Is this extensibility a goal? I thought that the way import attributes was specced in terms of lists of key/value pairs was more about spec flexibility (e.g. so JSON modules can be added without a change to the JS spec) rather than embedder flexibility. But I don't actually know (and the explainer doesn't say).

The reason I'm asking is because supporting a vectors of key/value pairs is quite a lot more cumbersome than just using an enum and seems wasteful if we don't need it.

(An alternative proposal, if we do want to enable this is flexibility, might be to use a single JS value here and have two host hooks, one to parse this value from syntax and one to compare the values. That way we could use a simple representation internally while still allowing embedders to do what they liked.)

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Hmm.

I've got a lot of this paged out at the moment. My intention for this bug was that if we had a concrete need for embedders to add their attributes, we could provide a nicer way of dealing with them -- but I'm sort of at a loss for what that looks like right now.

Like, hypothetically suppose an embedder wanted to add decompress as a new attribute, to import .json.gz files, what would that look like?

let j = await import("file.json.gz", {with: {type: "json", decompress: "gzip"}}); 

So the embedder would need:

1. To modify HostGetSupportedAttributes to return "decompress"
2. ...

That's about the point where this currently runs aground; we would actually need hooks in js::ModuleRequestObject::getModuleType and js::shell::ModuleLoader::loadAndParse to support this new module type

Like, in principle this is specified for host extensibility, but in practice it seems that unlike most host hooks where the machinery all works together, the hooks here are at best wishful thinking.

Maybe this should be spec feedback?