You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
A while back in #222 and #169 we talked about the idea of having some prefix.
Recent discussions about prefixes have led to a polarizing debate between "prefix" and "namespace" notations — for things that are not necessarily the same thing.
You do file://… if the implementation supports the scheme with the respective resource location and access protocols of that spec or people file bugs)
You do https://… if the implementation supports the scheme with the respective resource location and access protocols of that spec or people file bugs, and potentially lawsuits)
You do mailto: if the implementation supports the scheme — I don’t think a good implementation wants this to lead to a network request by the browser context itself
If you have a scheme, it can have zero network-transport and yet an implementation can make it very very meaningful to one loader.
You see this with blobs today — they are memory things — they cannot extend beyond the lifespan of the context, and they even CSP so that they don’t see yours, browser context wise.
The Point
importprocessfrom'process';// internally node:processimportpkgfrom'pkg';// internally node:… something that makes this resolve
Can we not say the above is implicit? If in node the default scheme is node: then specifiers are all of that scheme unless they are not.
Would that not lead to a balance between all things we care about ecosystem wise and still balance with newer notions others are exploring a decade later.