-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for redirects #32
Comments
I feel quite strongly the concept of a referrer specifier is broken and should be avoided if possible. On the web, module redirects suffer from the following double instance issue:
As a result I would rather not see this mistake extended to new functionality like compartments. |
this sounds better solved by #18 |
I do not think there’s a real world where all import specifiers are fully qualified and refer exactly to the executing source. It may be possible to effect that reality on some hosts and virtual hosts, but definitely not on all of them. My hope is that a loader API is big enough to allow for at least some existing code targeting an existing host be possible to carry forward. |
By way of an update, the current draft solves this problem with “module descriptors”, which are a union of various kinds. The relevant ones allow the unified In #52, I entertain a conversation to add back |
I’ve closed the issue but discussion remains open for any aspect of the proposal. Please feel free to open, or open an alternative issue to tear the above redirect mechanisms out of the proposal! |
In Node.js, a module specifier
./utility
may be fulfilled by a module with the full specifier./utility/index.js
instead. To implement this, theloadHook
must return not just theStaticModuleRecord
, but also the actual full specifier of./utility/index.js
because that is the referrer specifier for any import specifier in that module.On the web a similar facility is necessary for redirects. In Node.js the same facility is also necessary for canonicalized filesystem paths (
realpath
).To support these cases, we can overload the return value of
loadHook
:Are there objections or alternatives to this change?
(I specified
ModuleRecord
above as potentially eitherStaticModuleRecord | ThirdPartyModuleInterface
, which is orthogonal)The text was updated successfully, but these errors were encountered: