proposal-source-phase-imports icon indicating copy to clipboard operation
proposal-source-phase-imports copied to clipboard

Use special module specifier format

Open bergus opened this issue 2 years ago • 1 comments

I might be missing the exact requirements and use cases, but from a quick glance at the readme I thought: Why not just use the fragment or query part the specifier URL?

import x from "<specifier>#<reflection-type>"

or

import x from "<specifier>?type=<reflection-type>"

instead of

import x from "<specifier>" as "<reflection-type>"

It won't need special syntax, and afaiu it would have the same cache key semantics as outlined in the readme.

bergus avatar Mar 15 '22 16:03 bergus

Why not just use the fragment or query part the specifier URL?

Fragment and query are already usable in both Node and Browsers ESM support (sometimes useful for things like cache busting and similar). Query fragments in particular are exposed to the imported module in import.meta.url, for example query fragments can already be used for things like import(`./dictionary.js?lang=${ lang }`).

Fragment directives were specifically carved out to provide an area of urls for hosts to provide functionality that doesn't collide with user url parts, for this case one could imagine something like:

import module from "./mod.wasm#:~:type=wasm-module";
import instance from "./mod.wasm#:~:type=wasm-instance";

Another alternative would be schemes to declare types:

import module from "wasm-module:./mod.wasm";
import instance from "wasm-instance:./mod.wasm";

This would be fairly similar to how Node already uses node: to offer a guaranteed way to distinguish builtins from things in node_modules. So there is precedence for schemes in specifiers for changing behaviour.

Jamesernator avatar May 29 '22 11:05 Jamesernator

We have decided not to pursue this, due to ambiguity concerns (and because not all hosts use URLs as specifiers).

lucacasonato avatar May 16 '23 06:05 lucacasonato