Skip to content
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

module: pass full URL to loader for top-level load #29736

Closed
wants to merge 1 commit into from

Conversation

guybedford
Copy link
Contributor

@guybedford guybedford commented Sep 27, 2019

This passes the full URL for the top-level "runMain" to the ESM loader, instead of the pathname. In addition the existing example loader check of the input path type is adjusted to catch the original issue.

This resolves the issue raised in #29610, where the result of new URL('/C:\path') will throw.

It's more of a footgun than an actual bug, since the issue is that the expectation is that the parent URL would be passed (new URL('/C:\path', pathToFileURL(process.cwd() + path.sep)) works fine), but it seems better to be consistent in the use of file URLs input into the loader.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@guybedford guybedford requested a review from bmeck September 27, 2019 16:22
@guybedford guybedford added the esm Issues and PRs related to the ECMAScript Modules implementation. label Sep 27, 2019
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@Trott Trott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Sep 30, 2019
@Trott
Copy link
Member

Trott commented Sep 30, 2019

Landed in c42ab99

@Trott Trott closed this Sep 30, 2019
Trott pushed a commit that referenced this pull request Sep 30, 2019
PR-URL: #29736
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
@DerekNonGeneric
Copy link
Contributor

@Trott, why wasn't this merged instead of being committed directly?

@Trott
Copy link
Member

Trott commented Sep 30, 2019

@Trott, why wasn't this merged instead of being committed directly?

See number 5 at https://github.com/nodejs/node/blob/f663b31cc2aecd585e73430504f3d7f5252851ca/COLLABORATOR_GUIDE.md#landing-pull-requests. Adding metadata to commit messages (and often editing the message beyond that) means we end up with a process where this happens. In theory, I could force-push to the contributor's branch to get a purple merge (and I can still do that, I suppose), but I'm usually hesitant to force-push to someone else's branch just for those aesthetics.

(Long-term, I hope we can get a commit-queue going that takes care of all this stuff automatically.)

targos pushed a commit that referenced this pull request Oct 1, 2019
PR-URL: #29736
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. esm Issues and PRs related to the ECMAScript Modules implementation.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants