JavaScript-driven dynamic import map creation, instead

[domenic]

@manucorporat brought up an idea in this space that seems the most promising of one I've imagined so far. Basically, you dynamically generate your import maps at runtime in JavaScript, based on feature detection, instead of creating a JSON-based DSL in the map itself.

The section at https://github.com/littledan/import-map-feature-tests#why-not-provide-an-imperative-api-from-javascript-for-these-feature-tests doesn't seem to address this possibility, but instead an adjacent one. I guess it says the prefetch scanner might execute the feature test on the network thread, but that seems implausible...

The repo goes through a number of cases while building its DSL. The question is then, which of these cases can we do in JS? Briefly,

• Module exists: this is already in the base import maps spec, IIUC
• JavaScript parses: can be done, but violates CSP
• WebAssembly validates: can be done, maybe violates CSP?
• Module has an export: can be done but only async
• Global exists: can be tested with JS easily
• Module's export has a property: can be done but only async
• Options bag entries: can be tested with JS awkwardly (via throwing getters); see Need pattern for feature detecting dictionary members whatwg/webidl#107.

I'm especially interested in the "can be done but violates CSP" cases. It seems like we could pretty easily add some kind of Function.isParseable("js string"), or similar, which just returns true/false, with no execution, and is allowed by CSP. There are some details (e.g., module vs. script vs. function body), but they don't seem too hard to work out. I assume something similar could be done for WebAssembly.

Thoughts welcome!

[littledan]

This is an interesting path. I've definitely gotten the feedback that the JSON-based query language is ugly, so this would be a good way to resolve that concern!

Two reasons why I didn't start down it initially, but maybe these thoughts are somehow outdated:

• For the "module has an export" case (which is what got me started in this line of thought), I wasn't sure if there was a way to add import map entries after performing another import. From import map processing, it sounds like not yet, but after writing this explainer, I heard suggestions that it may be possible in some restricted way.
• To allow the browser to kick off fetches as soon as possible, I thought it might be helpful to allow the queries to be evaluated without running JS; this is related to but a bit of a stronger goal than the reasons import maps does not propose a programmable resolution hook. Someone implementing module resolution would be able to evaluate this thought better than me.

For WebAssembly, I don't think there's a risk of CSP violation, since you can just use the WebAssembly.validate call (and this is side-stepping the fact that WebAssembly CSP interaction is not standard or common between browsers yet).