util: move deprecated util._extend() to EoL

[AugustinMauroy]

Description

Granting DEP0060 (old one) to End of life and remove it form source code. First time I do that I'm not sure if I do it correctly

Comparison

Benchmarking util._extend() vs Object.assign() on v25.2.1
util._extend()                                x 5,662,376 ops/sec (114 runs sampled) v8-never-optimize=true min..max=(71.13ns...286.75ns)
Object.assign()                               x 9,243,556 ops/sec (105 runs sampled) v8-never-optimize=true min..max=(41.50ns...168.81ns)

[nodejs-github-bot]

Review requested:

• @nodejs/userland-migrations

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.55%. Comparing base (93c2581) to head (0424c81).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #60812      +/-   ##
==========================================
+ Coverage   88.43%   88.55%   +0.11%     
==========================================
  Files         703      703              
  Lines      208235   208231       -4     
  Branches    40085    40155      +70     
==========================================
+ Hits       184162   184397     +235     
+ Misses      16069    15829     -240     
- Partials     8004     8005       +1     

Files with missing lines	Coverage Δ
lib/util.js	97.88% <ø> (-0.09%)	⬇️

... and 47 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Renegade334]

debug@<2.6.7 was the sticking-point last time (#53429) – these versions still see a couple of million downloads a week, although that sounds like a significant drop.

[AugustinMauroy]

First, I'm going to write a codemod for this deprecation to move forward with user that use this api directly.
In same time, I'm going to try to see how we can help maintainer to upgrade/remove debug dep

[benjamingr]

I think the benefit (we don't have to maintain it) is low and the breakage is big with this one.

[AugustinMauroy]

IMO benefit is:

• reduce deprecated apis
• inciting user to move to native solution
• forcing the user to modernise their code

[benjamingr]

We already have a deprecation so users know they should not use this API.

Breaking millions of installations to teach users not to use an API sounds like a very aggressive/breaking move to me and I would rather we don't unless we find a way to avoid the breakage.

[AugustinMauroy]

What if we land this in v25 so it's will be on v26 LTS it's mean the gap between two LTS is sufficient.
I mean it's trow an error on v22, v24 and in v26 it's remove that doesn't sound too crazy.
And I just created a codemod for this depreciation

[benjamingr]

I mean it's trow an error on v22

We throw an error? I thought we just emit a warning don't we?

[AugustinMauroy]

I mean it's trow an error on v22

We throw an error? I thought we just emit a warning don't we?

My bad miss wording. yeah I mean warning

[Qix-]

Thanks @AugustinMauroy for the heads up on bsky. :)

If this were to land, which version of Node would this go out on? At the very least I can deprecate versions prior to this and mention in the deprecation notice that they'll break after upgrading to node x.y.z, whatever that is. If a backport is needed I can do that (but would prefer not to).

Please don't worry on account of debug, though, for API changes. It's the package's fault for using an underscored method like that anyway, and has since been rectified. From a cursory view, the version range that used _extend is minimally used - I'll double check that when issuing the deprecation notice, but it shouldn't be a problem.

I do appreciate the concern though!

[AugustinMauroy]

If this were to land, which version of Node would this go out on?

as it v25 and v26 if I got it correctly

[aduh95]

If this were to land, which version of Node would this go out on?

as it v25 and v26 if I got it correctly

This is labelled semver-major PRs that contain breaking changes and should be released in the next major version. , it couldn't go in v25 as v25.0.0 has already been released. It would go to the release lines that haven't been cutoff at the time of landing (if it were to land today, that'd be v26+).

[AugustinMauroy]

Thanks Antoine for this clarification!

[benjamingr]

Are we really ok with breaking millions of installs just to delete a deprecated API?

[ljharb]

Re the 3 benefits cited in #60812 (comment), "reducing deprecated APIs" for its own sake is not much of a benefit; if the native solution isn't enticing enough, then it's not better; and_forcing_ users isn't something we should want to do.

I don't think the massive amount of breakage this will absolutely cause is going to ever be worth it.