WHATWG URL compliance

[stevenvachon]

via universal-url

[Rob--W]

Why?

[stevenvachon]

Because it's only going to get more popular with time. http/https modules support them in Node 8.x. They also parse at least 2x faster.

[Rob--W]

My library is already compatible with WHATWG URLs, the exported function behaves identical regardless of whether the input is a WHATWG URL or a legacy (Node.js) URL. The return value is a string. If the consumer really wants to have a URL, it is trivial to do new URL(returnValueHere) to obtain a URL.

So, I don't see a benefit in adding "universal-url" as a dependency.

[stevenvachon]

I was referring to the internal use of url.parse(). It's better to use the specification parser.

[Rob--W]

I was referring to the internal use of url.parse(). It's better to use the specification parser.

Better in what sense? I don't see a functional difference between the two parsers in my use case. I only use scheme (.protocol), host name (inferred from .host) and port (.port) properties of (parsed) URLs.

There must be a compelling reason before I add new dependencies. The only potential advantage that you've mentioned so far is a "at least 2x faster". I don't attribute much value to this claim, not only because of the lack of benchmarks, but mainly because the existing implementation is already sufficiently fast and unlikely to be a bottleneck for performance issues.

[stevenvachon]

The specification uses TR46 to parse IDNA host names.

Benchmarks: nodejs/node#10678 (comment)

[silverwind]

Should probably switch the legacy url to use URL, present as global since Node.js 10.0.0.