module: runtime deprecate module.register()

[GeoffreyBooth]

Building on #62395, this runtime-deprecates module.register().

I’m not sure when we want to land and release this; I think the options are basically either:

1. When module.registerHooks() goes stable, hopefully sometime before 26 goes LTS; module: doc-deprecate module.register() #62395 (comment)
2. In 26.0.0; the doc-deprecation is backported to the 25.x line, and the runtime deprecation is 26+; module: doc-deprecate module.register() #62395 (comment)

I’m opening this now in case the team wants to do the second option. cc @nodejs/loaders @nodejs/userland-migrations

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/userland-migrations

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.77%. Comparing base (7ffbb76) to head (a0e36fb).
⚠️ Report is 14 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62401      +/-   ##
==========================================
+ Coverage   89.70%   89.77%   +0.06%     
==========================================
  Files         692      692              
  Lines      214039   214563     +524     
  Branches    41064    41510     +446     
==========================================
+ Hits       192010   192615     +605     
+ Misses      14091    14050      -41     
+ Partials     7938     7898      -40     

Files with missing lines	Coverage Δ
lib/internal/modules/esm/loader.js	98.78% <100.00%> (+0.01%)	⬆️

... and 49 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.

[AugustinMauroy]

In general that seem good.

[mcollina]

lgtm

I think we should aim for 26.x, so we can actually drop in 27

[mcollina]

lgtm

[gurgunday]

lgtm

[mcollina]

lgtm

[mcollina]

@nodejs/tsc ptal. this should land for v26

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/72219/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/72286/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/72304/

[aduh95]

It doesn't look like we have consensus on what should be the policy for deprecating experimental APIs in #62456. Let's not land this until we're in alignment (also the doc-only should probably land first: #62395)

[GeoffreyBooth]

If landing the doc deprecation means that we can’t land the runtime deprecation until 27, drawing out removal until 28, then I’d rather skip the doc deprecation. The goal is to remove the API in 27, while giving users as much warning as possible.

I don’t think it’s reasonable to block PRs based on other PRs. I asked the @nodejs/tsc to discuss this in last week’s meeting and reach a consensus so that one or the other of these PRs could be unblocked, and I’m disappointed that that didn’t happen. I’m concerned that this is getting dragged out to the point that nothing will be able to land in time for 26.0.0.

[panva]

there is precedent on deprecating experimental features and this needs to get done in time for 26