Repository navigation
DEP0169 DeprecationWarning: url.parse() when url.resolve() used (node_modules context) #61724
Description
Activity
url.resolve(from, to)is essentiallyurl.parse(from).resolve(url.parse(to))so this falls under DEP0169, similar tourl.format(string).Not sure there's anything to do but mark it as indirectly deprecated as well.
url.resolve()does silently accept Url object arguments, but since the only useful way to get one is fromurl.parse(), it doesn't really seem worth documenting.Thanks for pointing out the relationship!
It seems that the change in behavior may have been caused by #60991 in 25.4.0
For Node.js <25.4.0 in Cypress, using the npm module cypress, no DEP0169 was emitted, and my understanding of the code both before and after #60991 is that there should be no deprecation warning if the call comes from a
node_moduleslocation.I see that#60991is planned for backporting inhas been backported through #61661 into Node.js 24.13.1 so this may cause an increase in the number of users seeing similar displays ofDEP0169.if it is merged including this PR.At the moment it does not look like this is a documentation issue from my perspective. It seems more like an unintended change where some situations needing the
DEP0169warning suppressed are actually allowing it to warn when it should not be warning.
Whatever the outcome here, I will still bring this up as an issue in the cypress repo, as it should be possible to migrate their download.ts module to use the WHATWG URL API instead of the Legacy URL API. Edit: PR cypress-io/cypress#33348 merged for this.
The underlying issue is that the deprecation of
url.parse()has indirectly deprecated the majority of the legacy URL API, with the exception ofurl.format(obj), as the other methods depend onurl.parse()internally to convert string input to Url objects. This wasn't really noted at the time, and we now have a scenario where the API as a whole is marked as legacy, but almost all usage is de facto deprecated and (outside of node_modules) emits deprecation warnings.cc @jasnell @Trott @anonrig as interested parties in the original deprecation revocation and subsequent re-deprecation of
url.parse()– what do you think is the correct resolution here? Do we just mark offurl.resolve()as co-deprecated, or are we at the point where we may as well consider just re-deprecating that area of the API?cc @jasnell @Trott @anonrig as interested parties in the original deprecation revocation and subsequent re-deprecation of
url.parse()– what do you think is the correct resolution here? Do we just mark offurl.resolve()as co-deprecated, or are we at the point where we may as well consider just re-deprecating that area of the API?Unfortunately, it's been a long time since I've given this any thought. Hopefully @anonrig and @jasnell have viewpoints they can share. Also, let's ping @nodejs/url to see if anyone else on that team has something to say.
I think we should just deprecate url.resolve().
Reacted by Mike McCreadyIn an effort to provide simple repro steps I have unintentionally confused two DEP0169 issues in this one report. Possibly this should be split into two different GitHub issues.
Non
node_modulesusageUse of
url.resolve()in a nonnode_modulespackage context results in aDEP0169warning in release lines 24.x and 25.x, but not in 20.x or 22.xcd $(mktemp -d) cat > url-resolve.js <<EOT const url = require('node:url'); url.resolve('http://example.com/', '/one'); // 'http://example.com/one' EOT node url-resolve.js
Node.js Result 20.20.0 no deprecation warning 22.22.0 no deprecation warning 24.0.0 DEP0169 24.13.1 DEP0169 25.0.0 DEP0169 25.6.1 DEP0169 url.resolve(from,to) is not marked deprecated in the documentation for any of the currently supported release lines.
Usage from an npm package installed in
node_modulesUsing the npm module cypress@15.10.0's command
cypress installresults in a deprecation warning for the latest 24.x and 25.x releases only. This is effectively a breaking change within the respective release line.cd $(mktemp -d) npm install cypress@15.10.0 -D -E --ignore-scripts npx cypress cache clear npx cypress install
Node.js Result 20.20.0 no deprecation warning 22.22.0 no deprecation warning 24.0.0 no deprecation warning 24.11.0 no deprecation warning 24.13.1 DEP0169 25.0.0 no deprecation warning 25.6.1 DEP0169 For Cypress the issue will be remedied in the next release of Cypress.
url.resolve()has been replaced byURLin thecypress installcommand code. I can also reproduce this by publishing the simpleurl.resolve()example to GitHub as a package, and then running it after requiring it in a second package.The trace shows it being called in
node_modulesand I understood that usage insidenode_moduleswas supposed to cause the deprecation warning to be suppressed:(node:8453) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities. at urlParse (node:url:137:13) at Object.urlResolve [as resolve] (node:url:721:10) at prepend (/tmp/tmp.hT2HnLgaxi/node_modules/cypress/dist/tasks/download.js:65:36) at getUrl (/tmp/tmp.hT2HnLgaxi/node_modules/cypress/dist/tasks/download.js:87:12) at /tmp/tmp.hT2HnLgaxi/node_modules/cypress/dist/tasks/download.js:283:24 at Generator.next (<anonymous>)The mentioned stack trace should not trigger the deprecation warning as far as I can tell due to coming from a
node_modulesfolder and other calls are node internal ones. @legendecas PTAL(node:8453) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities. at urlParse (node:url:137:13) at Object.urlResolve [as resolve] (node:url:721:10) at prepend (/tmp/tmp.hT2HnLgaxi/node_modules/cypress/dist/tasks/download.js:65:36) at getUrl (/tmp/tmp.hT2HnLgaxi/node_modules/cypress/dist/tasks/download.js:87:12) at /tmp/tmp.hT2HnLgaxi/node_modules/cypress/dist/tasks/download.js:283:24 at Generator.next (<anonymous>)Reacted by Mike McCreadyThe mentioned stack trace should not trigger the deprecation warning as far as I can tell due to coming from a
node_modulesfolder and other calls are node internal ones. @legendecas PTALurl.parse()was configured to only seek 2 frames deep for node_modules; since this is called indirectly by other node:url methods, I think this will need to be at least 4 (to cover the internalurl.resolve > Url.prototype.resolve > url.parsestack), or we change the publicurl.parseto a warning wrapper and have a non-warning internal method as wellReacted by Mike McCreadyI'm ok with either (a) deprecating
url.resolve(...)or (b) deepening thenode_modulescheck to avoid the issue. (b) is obviously less disruptive.1 remaining item
(a) deprecating url.resolve(...)
That would solve the issue for usage outside of
node_modulesin 24.x & 25.xEdit: follow-on in #61816
I've moved the deprecation documentation issue to #61816 for clarity. This is about documenting that #55017 added Application deprecation (non-
node_modulescode only) in v24.0.0 explicitly forurl.parse()and the implicit deprecation caused by the dependency ofurl.resolve()onurl.parse()needs to be retroactively added to the documentation for v24.0.0.With the deprecation documentation issue spun off to #61816, this issue can focus on the regression introduced by #60991 which causes
url.resolve()usage in anode_modulesenvironment under Node.js 24.13.1 and 25.4.0 - 25.6.0 to emit DEP0169.It seems the change from:
if (!urlParseWarned && !isInsideNodeModules(100, true)) {
to
if (!urlParseWarned && !isInsideNodeModules(2)) {
was too radical and did not take account of a nested call from
urlResolvetourlParse.Deprecation detection / suppression needs to be changed so that invoking
url.resolve()in anode_modulescontext does NOT emit DEP0169, the same as is the case forurl.parse()in anode_modulescontext.- changed the title
[-]DEP0169 DeprecationWarning: url.parse() when url.resolve() used[/-][+]DEP0169 DeprecationWarning: url.parse() when url.resolve() used (node_modules context)[/+]on Feb 14, 2026 Also reproducible with the following on Windows using Node.js 24.13.1 installed from MSI package:
cd $(mktemp -d) yarn add yarn
This issue remains reproducible for Node.js 24.14.0 LTS and 25.7.0
export NODE_OPTIONS='--trace-deprecation' cd $(mktemp -d) npm install cypress@15.10.0 -D -E --ignore-scripts npx cypress cache clear npx cypress install
produces:
(node:3994) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities. at urlParse (node:url:137:13) at Object.urlResolve [as resolve] (node:url:721:10) at prepend (/tmp/tmp.Bp14h3MLKW/node_modules/cypress/dist/tasks/download.js:65:36) at getUrl (/tmp/tmp.Bp14h3MLKW/node_modules/cypress/dist/tasks/download.js:87:12) at /tmp/tmp.Bp14h3MLKW/node_modules/cypress/dist/tasks/download.js:283:24 at Generator.next (<anonymous>)Edit: Still reproducible in Node.js 24.14.1, no longer reproducible in Node.js >=25.8.1 including 25.9.0
#62002 is submitted to formally confirm deprecation of
url.resolve()in a non-node_modulescontext and to clarify that the definition of DEP0169: Insecure url.parse() as:Type: Application (non-`node_modules` code only)also applies to
url.resolve(). In other words, there should be no deprecation warning fornode_modulesusage ofurl.resolve()- added a commit that references this issue
on Mar 8, 2026 Verified fixed in Node.js 25.8.1 with test from #61724 (comment) above.
Reacted by RenéVerified fixed in Node.js 24.15.0 with test from #61724 (comment) above.
Version
24.x & 25.x - see #61724 (comment) for details
Platform
Subsystem
url
What steps will reproduce the bug?
Run example from Legacy URL API url.resolve(from, to)
How often does it reproduce? Is there a required condition?
For the above steps, it always reproduces in Node.js 25.4.0 - 25.6.0. It is a regression from Node.js 25.3.0.
If the
url.resolve()call is embedded in an npm package, it depends how the corresponding module is called, whether or not a deprecation warning appears. See the additional information section below for examples.What is the expected behavior? Why is that the expected behavior?
The example with only
url.resolve()should run without producing a deprecation warning.The history section of url.resolve(from, to) states that the deprecation was revoked in v15.13.0, v14.17.0 and there is no entry for any higher version.
DEP0169 lists url.parse() explicitly. It does not include any direct reference to
url.resolve().What do you see instead?
Additional information
I originally noticed this with Cypress, on Ubuntu 24.04.3 LTS, Node.js 25.6.0, with steps to reproduce:
where the call is from
/node_modules/cypress/dist/tasks/download.js.The following steps however do NOT cause any deprecation warning, even though download is also run: