-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
esm: syncify default path of ModuleLoader.load
#57419
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
Open
JakobJingleheimer
wants to merge
10
commits into
nodejs:main
Choose a base branch
from
JakobJingleheimer:esm/syncify-ModuleLoader-load
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
3a0882a
esm: syncify default path of `ModuleLoader.load`
JakobJingleheimer d633804
!fixup: don't force `ModuleLoader.load` to be async (can via hooks)
JakobJingleheimer 4276af1
!fixup: remove obsolete `getSource` in favour of `getSourceSync`
JakobJingleheimer f60650f
!fixup: account for `node:internal` in `isMain` check
JakobJingleheimer 76c93d5
Revert "!fixup: account for `node:internal` in `isMain` check"
JakobJingleheimer b697946
Reapply "!fixup: account for `node:internal` in `isMain` check"
JakobJingleheimer 8f93801
fixup!: add todo & note about mysterious fix/failure
JakobJingleheimer 558dfff
fixup!: move isInternal check to specific vm resolve path
JakobJingleheimer d765ed3
fixup!: remove `referrerName === 'node:internal/process/task_queues'`
JakobJingleheimer 7c5787a
module: exclude `node:` prefixed referrer as "parsable url"
JakobJingleheimer File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it might happen from the branch here and the "reset source to null and then resolve twice - the second time resolving a full path - if it's commonjs" quirk of the sync loading path. Which might mean that this sync version may not be used as-is without getting rid of that quirk or patched here somehow to not trigger that quirk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 what makes you think it's that quirk? and why is it only exposed when going through that specific VM scenario?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because when this surfaces through the hooks it's documented as a caveat https://nodejs.org/api/module.html#caveat-in-the-asynchronous-load-hook. Internally this happens too, just less observable, I think this only happens in the sync loading, and the vm test isn't expecting this quirk to surface (now that
import()
switches to use sync loading that hits this quirk). Have you tried actually debugging the module loading to see what happens when the error gets thrown?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not yet because I didn't know where to look (there was no stack-trace and I've never touched VM before). But now that I know where it happens, I have a place to start.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably less related to vm because
USE_MAIN_CONTEXT_DEFAULT_LOADER
= use the default loader as if it's being imported from the main context. You could debug the loader paths where ERR_UNSUPPORTED_RESOLVE_REQUEST gets thrown. It doesn't have a stack trace becauseassert.rejects
is unable to capture the async stack trace (I wanted to use normalassert.strictEqual
but @aduh95 suggested to useassert.rejects
and I accepted his suggestions, maybe it's worth reverting back #51244 (comment) )There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It comes from the
shouldBeTreatedAsRelativeOrAbsolutePath
branch withinmoduleResolve
:It's trying to instantiate a URL with
'node:internal/process/task_queues'
as the "base".I think perhaps
normalizeReferrerURL
is not supposed to recognise'node:internal/process/task_queues'
as a valid URL, in which casereferrerName
would be voided toundefined
. Does that sound right to you?I added an extra check ( 7c5787a ) within
normalizeReferrerURL
to excludenode:
prefixed referrers, and this test and all the es-module tests pass. If all the tests pass, and we find it acceptable, I think that commit should be separated into its own PR that lands before this one.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like a bug, because
internal/process/task_queues
doesn't haveimport()
inside, and the referrer should never be anode:
-prefixed URL since we don'timport()
in any of our builtins (that would not work either because we don't implement the host dynamic import callback for builtins). It sounds like whatever that differs in the sync loading from the async one (maybe this "reset to null and then re-resolve + reload" behavior) might alter the request that gets send to resolve that ends up creating an invalid request. You might want to see what is the URL being resolved with that invalid base and debug to find where that invalid request is created under what circumstances and stop it from doing that.I think if you have to land it with the bug it's better to make the special case completely about this specific URL and add a comment mentioning that the bug exists. Excluding
node:
completely for this merely enlarges the scope of the bug, because that's supposed to be unreachable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joyeecheung so for the time-being, are you saying I should switch back to d765ed3? (and update the comment since it's not a mystery anymore)
I think fixing that bug is out of scope of this PR (ex if this got reverted, that would also revert the bugfix)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's still a mystery why an unreachable condition is somehow reachable, and is likely a bug caused by reusing a path that's not yet ready/meant to be reused this way without fixups. Another route is to not reuse
getSourceSync()
and write a more comparable version of synchronousgetSource
without that differing branch.