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

url: expose the WHATWG URL API globally #18281

Closed
wants to merge 1 commit into from

Conversation

targos
Copy link
Member

@targos targos commented Jan 21, 2018

Install URL and URLSearchParams on the global object, like they can be
found in browser environments.

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
Affected core subsystem(s)

url

/cc @nodejs/tsc @nodejs/url @jasnell

Quick CI: https://ci.nodejs.org/job/node-test-pull-request-lite/106/
Quick CI: https://ci.nodejs.org/job/node-test-pull-request-lite/107/

@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Jan 21, 2018
@targos targos added whatwg-url Issues and PRs related to the WHATWG URL implementation. and removed lib / src Issues and PRs related to general changes in the lib or src directory. labels Jan 21, 2018
@vkurchatkin
Copy link
Contributor

I'm -0 on this, but I think that it's a leat preferable to schedule this for a major release.

@targos targos added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jan 21, 2018
@targos
Copy link
Member Author

targos commented Jan 21, 2018

I think that it's a leat preferable to schedule this for a major release.

I agree. I forgot to put the semver-major label.

@cjihrig
Copy link
Contributor

cjihrig commented Jan 21, 2018

I'd rather not add more globals, but I won't block this if people think it's the right thing to do.

Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes complete sense to me. Very much in favour. 👍

(Even though with this being semver-major, my vote doesn't make much of a difference.)

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might want a lint rule like the one we have for Buffer which verifies that internal modules don’t rely on the global and instead do explicitly require url?

@targos
Copy link
Member Author

targos commented Jan 21, 2018

@addaleax we don't need a special rule. ESLint already considers uses of global URL an error.

@mcollina
Copy link
Member

I'm +0 on this. The implementation is ok, but I would not add more globals, but I'm not objecting either as it's very common on web platform.

If we are doing this, I would prefer if we started using it everywhere, even internally (https://github.com/nodejs/node/blob/master/lib/_http_client.js#L26), and gently phase away the old url parser. If we think this is the way to go, there is very little incentive for the community to adopt it if we do not use it internally.

Copy link
Member

@TimothyGu TimothyGu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

Copy link
Member

@bnoordhuis bnoordhuis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally don't have a problem with exposing them as globals. Next up: TextEncoder?

I'll get my coat.

doc/api/url.md Outdated
@@ -447,20 +431,23 @@ console.log(JSON.stringify(myURLs));
### Class: URLSearchParams
<!-- YAML
added: v7.5.0
changes:
- version: REPLACEME
pr-url: REPLACEME
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should be able to also set this, shouldn't we?

doc/api/url.md Outdated
<!-- YAML
added: v7.0.0
changes:
- version: REPLACEME
pr-url: REPLACEME
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should be able to go ahead and set this, no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks. updated

@targos
Copy link
Member Author

targos commented Jan 22, 2018

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very happy to see this come back around. It wasn't quite as popular an idea the first time I suggested it :-)

@ChALkeR
Copy link
Member

ChALkeR commented Jan 22, 2018

-0 for reasons described in nodejs/node-eps#28 (comment) (my and others comments). I don't think that things changed much since that discussion.

I won't block this though if this is what others want.

@@ -327,6 +328,24 @@
setupInspector(originalConsole, wrappedConsole, Module);
}

function setupGlobalURL() {
const { URL, URLSearchParams } = NativeModule.require('internal/url');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this impact startup performance, and if so, could it be required on use possibly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, as this module is already being imported on startup:

// Ensure setURLConstructor() is called before the native
// URL::ToObject() method is used.
NativeModule.require('internal/url');

Install URL and URLSearchParams on the global object, like they can be
found in browser environments.

PR-URL: nodejs#18281
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@targos
Copy link
Member Author

targos commented Jan 29, 2018

@targos
Copy link
Member Author

targos commented Jan 30, 2018

I'm not sure what's going on with AIX but it does not seem related.
Given all the +1s, I'm going to land this tomorrow if there are no explicit objections.

@Trott
Copy link
Member

Trott commented Jan 30, 2018

Trying again on AIX. Given all the problems that have erupted on CI in the last month or two, I'm kinda -1 on landing something if we can't get CI to build/run on a platform. But I'm optimistic this is fixed now, so hopefully no problems...

CI for AIX: https://ci.nodejs.org/job/node-test-commit-aix/12189/

@mhdawson
Copy link
Member

@Trott thanks for restarting AIX. I fixed up one of the machines yesterday. There were a bunch of stale processes. I see the run you launched is green :)

@targos targos added the notable-change PRs with changes that should be highlighted in changelogs. label Jan 31, 2018
@targos
Copy link
Member Author

targos commented Jan 31, 2018

Landed in 3124146

@targos targos closed this Jan 31, 2018
@targos targos deleted the global-url branch January 31, 2018 15:08
targos added a commit that referenced this pull request Jan 31, 2018
Install URL and URLSearchParams on the global object, like they can be
found in browser environments.

PR-URL: #18281
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@fregante
Copy link

fregante commented Feb 2, 2018

I'm a nobody here, but I hope to see APIs shared across platform in the global scope so I don't have to mess with the browser field and "redirect" files every time I want to publish a cross-platform package.

@guybedford
Copy link
Contributor

I'm just wondering, would it be worth backporting this to 8.x? Would help a lot to be able to treat this as a baseline support. I can put together the port if it sounds like it could be possible.

@TimothyGu
Copy link
Member

@guybedford I'd rather not since there might be code out there checking typeof URL to detect Node.js/browsers.

@guybedford
Copy link
Contributor

@TimothyGu I've never ever seen a pattern like that for environment detection - usually it is based on Window or Document. Every case I've seen doing typeof URL is for a feature detection to use URL, which will imply a behaviour change yes, but it should be a wanted one in those cases.

Users wanting to use the URL global in Node won't be able to until Node 8 EOL, which is over a year away, so it's a shame not to be able to really use this awesome feature in published packages that want to support Node 8 +.

@mcollina
Copy link
Member

I'm generically -1 in adding new globals in semver-minors. Code running without 'use strict' will be affected (sigh): unfortunately there are plenty of modules that do exactly that.
I think landing it in 8 will require a @nodejs/tsc vote. It might be a good thing to check anyway what our position is, if you want to move this forward and champion this.

@targos
Copy link
Member Author

targos commented Apr 25, 2018

If you feel strongly about it, can you please open a new issue for that discussion?

guybedford pushed a commit to guybedford/node that referenced this pull request Apr 25, 2018
Install URL and URLSearchParams on the global object, like they can be
found in browser environments.

PR-URL: nodejs#18281
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@guybedford
Copy link
Contributor

I've created #20306 to track. @mcollina what sort of code examples without 'use strict' might be affected by this do you think?

@mcollina
Copy link
Member

mcollina commented May 2, 2018

try {
  new URL("http://google.com")
} catch (e) {
  // we are on Node 10!
  // so we can use XYZ.
}

also

if (!global.URL) {
  // assume something that's not true anymore 
}

MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
Install URL and URLSearchParams on the global object, like they can be
found in browser environments.

PR-URL: nodejs#18281
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
notable-change PRs with changes that should be highlighted in changelogs. semver-major PRs that contain breaking changes and should be released in the next major version. whatwg-url Issues and PRs related to the WHATWG URL implementation.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet