Expose the url-to-options function from internal/url.js

[szmarczak]

Is your feature request related to a problem? Please describe.

#14570 (comment)

Describe the solution you'd like

Expose the urlToOptions module so it can be imported e.g. const {urlToOptions} = require('url');

That way we could easily convert a URL instance without duplicating the code like this.

Describe alternatives you've considered

No, duplicates increase the package size.

[bnoordhuis]

I'm inclined to say it's better to copy it out into a npm module than to expose it because:

1. it's borderline trivial

2. it doesn't really fit anywhere (cross-cut of url and http)

3. it's annoying to have to worry about backwards compatibility / not breaking the public API when making changes

[szmarczak]

it's borderline trivial

I strongly disagree. If this was trivial then it wouldn't be used in the http module to deserialize any URL instance.

it doesn't really fit anywhere (cross-cut of url and http)

Hmm... After giving it some thought I'd go for const {urlToOptions} = require('http'); since it returns HTTP options.

it's annoying to have to worry about backwards compatibility / not breaking the public API when making changes

That's the cost you always have to take. It's already used in the http module so you already need to worry about this.

[bnoordhuis]

It's trivial in the sense that it doesn't do anything that ordinary JS code cannot also do.

It it needed runtime magic or if you needed to go to extreme lengths to make it do something that's trivial for core code, that's a compelling argument to expose it, but that doesn't apply here.

There are exceptions to the rule (tls.checkServerIdentity() is one) but the threshold is pretty high.

It's already used in the http module so you already need to worry about this.

The distinction here is that it's only indirectly observable to user code. For example, we don't have to worry about callers passing something that's not a URL object.

[szmarczak]

It it needed runtime magic or if you needed to go to extreme lengths to make it do something that's trivial for core code, that's a compelling argument to expose it, but that doesn't apply here.

Then let's completely remove the http (client) module since we can achieve the same using undici.

You get me wrong, I just don't want to duplicate what already exists in the Node.js core.

The distinction here is that it's only indirectly observable to user code.

Because it's almost not observable to user code it doesn't mean that it doesn't have any impact. If urlToOptions fails then you can clearly see the issue here.

Although the end user won't have to use urlToOptions, many packages that operate on the low level, including got , cacheable-request and caw use that.

There's already an NPM package called url-to-options.

Even node-fetch would benefit from this.

On the other side, request (now deprecated) and axios use the legacy url.parse instead.

[ZYSzys]

#35960