Repository navigation
Expose the url-to-options function from internal/url.js #34349
Description
Activity
I'm inclined to say it's better to copy it out into a npm module than to expose it because:
-
it's borderline trivial
-
it doesn't really fit anywhere (cross-cut of url and http)
-
it's annoying to have to worry about backwards compatibility / not breaking the public API when making changes
Reacted by James M Snell-
it's borderline trivial
I strongly disagree. If this was trivial then it wouldn't be used in the
httpmodule 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
httpmodule so you already need to worry about this.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.
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 usingundici.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
urlToOptionsfails 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, includinggot,cacheable-requestandcawuse that.There's already an NPM package called
url-to-options.Even
node-fetchwould benefit from this.On the other side,
request(now deprecated) andaxiosuse the legacyurl.parseinstead.- added a commit that references this issue
on Jan 22, 2021 - added a commit that references this issue
on Aug 8, 2021 - added a commit that references this issue
on Aug 12, 2021 - added a commit that references this issue
on Aug 31, 2021 - added a commit that references this issue
on May 22, 2026
Is your feature request related to a problem? Please describe.
#14570 (comment)
Describe the solution you'd like
Expose the
urlToOptionsmodule 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.