Review requested:

• @nodejs/userland-migrations

Codecov Report

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

@@            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     

... and 47 files with indirect coverage changes

• ❄️ 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.

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.

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

IMO benefit is:

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

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.

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

I mean it's trow an error on v22

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

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

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!

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

as it v25 and v26 if I got it correctly

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+).

Thanks Antoine for this clarification!

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

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.

I also think "forcing users to update their code" is not a strong enough motivation in itself either, especially when the code in question usually lies in users' dependencies that they don't control, and the result is really "the runtime forcing extra work on everyone, especially package maintainers who might already be tired of doing free labour, for pure stylistic preferences". The usual motivation for actually deprecating something in a breaking manner would be "to enforce secure practices" or "it's too much maintenance burden to keep it", because otherwise a bug-in-bug-out API would just be more work for everyone anyway, but it doesn't apply in this case (it's not really much to maintain).

That said I am okay with deprecating it only when it's not inside a node_modules (that is, in code that is in users' control) like what we do for the buffer constructor etc.

Honestly, while it's unfortunate to have to keep around, I'd be fine with this being marked Legacy and left as is.

Hey any news here. So with landing of v26 if consensus is found, it's will be landed on 27 ?