Refs: #61724
Refs: #61780

Version

>=v24.0.0

Platform

Linux ubuntu-24.04 6.17.0-14-generic #14~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jan 15 15:52:10 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

url

What steps will reproduce the bug?

Run example from Legacy URL API url.resolve(from, to) directly without involving node_modules

const url = require('node:url');
url.resolve('/one/two/three', 'four');         // '/one/two/four'
url.resolve('http://example.com/', '/one');    // 'http://example.com/one'
url.resolve('http://example.com/one', '/two'); // 'http://example.com/two'

How often does it reproduce? Is there a required condition?

Always in Node.js >=24.0.0

What is the expected behavior? Why is that the expected behavior?

The DEP0169 documentation section should list url.resolve() alongside url.format() as being covered by this deprecation.

The url.resolve(from, to) should list Application deprecation as of v24.0.0

Application deprecation (non-node_modules code only) was introduced for url.parse(urlString[, parseQueryString[, slashesDenoteHost]]) in v24.0.0 through #55017.

Internally urlResolve() calls urlParse(), so url.resolve() needs the same level of deprecation as url.parse()

The documentation should reflect that it was introduced in v24.0.0.

What do you see instead?

The message for DEP0169 contains no reference to url.resolve(), nor does the DEP0169 documentation section mention url.resolve().

(node:5802) [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.
(Use `node --trace-deprecation ...` to show where the warning was created)

Additional information

Follows on from #61724 which describes two difference issues for url.resolve() deprecations

• inside node_modules where there is a regression introduced in 24.13.1 & 25.4.0
• outside node_modules where the deprecation warning was introduced undocumented in 24.0.0

#61780 is currently open to resolve this documentation issue