Review requested:

• @nodejs/url

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.75%. Comparing base (04946a7) to head (3f93972).
⚠️ Report is 5 commits behind head on main.

@@            Coverage Diff             @@
##             main   #61776      +/-   ##
==========================================
+ Coverage   89.73%   89.75%   +0.01%     
==========================================
  Files         675      675              
  Lines      204648   204652       +4     
  Branches    39330    39324       -6     
==========================================
+ Hits       183651   183689      +38     
+ Misses      13282    13255      -27     
+ Partials     7715     7708       -7     

I think url.format is only deprecated for url.format(string), not url.format(urlObject): https://nodejs.org/api/url.html#urlformaturlobject.

Also url.resolve is not deprecated in the doc: https://nodejs.org/api/url.html#urlresolvefrom-to.

I think we should take this opportunity to deprecate url.resolve rather than fixing it like this. url.parse is deprecated because it is not secure, not fast etc. and we have a better alternative now. Hiding the fact that url.resolve is calling an unsafe AND deprecated method is not in the best interest of node.js users.

The deprecation of url.resolve was revoked in #37784. To deprecate it again, I think it need to go through the deprecation cycle.

#61780

I think we should start a proper deprecation cycle of url.resolve and fix url.parse. If we also want to deprecate url.parse then it should have its own deprecation cycle properly. Emitting warnings from node_modules probably doesn't help anyone other than forcing more people to use NO_WARNINGS to surpress it which can backfire.

I am not sure if it's accurate to describe these APIs as insecure without context - AFAICT whether they are secure depends on whether you are relying on them to be a security boundary/feeding them malicious data. And relying on it in the wrong way turns bugs into your security risk, but it's not like using it alone in an empty script allows an attacker to execute remote code without pairing up with a bunch of other code that makes shaky assumptions. If your application doesn't do that and it's not in your hot path, it's not really something you have to worry about enough to deal with deprecation warnings coming out of a deep dependency, instead of spending that time on things that actually matter for your own code's performance and security).