tc39 / proposal-source-phase-imports

Proposal to enable importing modules at the source phase
https://tc39.es/proposal-source-phase-imports/
MIT License
129 stars 9 forks source link

Use special module specifier format #19

Closed bergus closed 1 year ago

bergus commented 2 years ago

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.

Jamesernator commented 2 years ago

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.

lucacasonato commented 1 year ago

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