GeezerVison

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

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.

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

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

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.

CI: https://ci.nodejs.org/job/node-test-pull-request/12656/

-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.

New CI: https://ci.nodejs.org/job/node-test-pull-request/12797/
Edit: AIX rebuild: https://ci.nodejs.org/job/node-test-commit-aix/12156/

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.

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/

@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 :)

Landed in 3124146

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.

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.

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

@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 +.

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.

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

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

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 
}