-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v22.x] backport unflagging of --experimental-require-module and related fixes/refactorings #55217
base: v22.x-staging
Are you sure you want to change the base?
[v22.x] backport unflagging of --experimental-require-module and related fixes/refactorings #55217
Conversation
Review requested:
|
CITGM for v22.x-staging: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/3481/ |
Some regressions found:
I think for backporting to v22.x we should probably do some changes: a. Provides b would not fix the test regressions 2-4, the packages still need to update their tests which is to be expected. But at least it would not break the CLIs for end users. |
As for esm, from what I can tell in standard-things/esm#883 it seems to have been broken in different ways since many major releases of Node.js ago. The regression that predated unflagging of require(esm) I found in #55085 (comment) also seem to come from some TDZ issue in the way the package is written (it relies on access to Node.js internals and seem to expect certain internals to be invoked in certain order). It doesn't seem to be very cost-effective to do anything about it on v22. |
These SGTM |
Opened #55241 for feature detection. |
Added a commit from #55243 and a commit for v22.x specifically (and maybe v20.x in the future) to disable the warning when require() comes from node_modules. |
I just updated v22.x-staging so this now has conflicts because of duplicated commits I guess. |
dda6fc3
to
9c282c3
Compare
Rebased to drop the duplicate commits. Also cherry-picked #55243 and #55241 from the main branch. I think for backport to v22.x it is ready, note that the last commit (silence the experimental warning when it comes from node_modules) is only targeting v22.x, as proposed in #55217 (comment) and agreed in the last TSC meeting. |
9c282c3
to
3d0afe0
Compare
Can you rebase please? |
5ed6462
to
898396a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
898396a
to
5ea60dc
Compare
Some packages have been using try-catch to load require(esm) in environments that are available. In 23, where require(esm) is unflagged, we emit an experimental warning when require() is used to load ESM. To backport require(esm) to older LTS releases, however, this could break existing CLI output. To reduce the disruption for LTS, on older release lines, this commit is applied to skip the warning if require(esm) comes from node_modules. This warning will be eventually removed when require(esm) becomes stable. PR-URL: nodejs#55217 Refs: nodejs#52697 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
When a ESM module cannot be loaded by require due to the presence of TLA, its module status would be stopped at kInstantiated. In this case, when it's imported again, we should allow it to be evaluated asynchronously, as it's also a common pattern for users to retry with dynamic import when require fails. PR-URL: nodejs#55502 Fixes: nodejs#55500 Refs: nodejs#52697 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Trim off irrelevant internal stack frames for require(esm) warnings so it's easier to locate where the call comes from when --trace-warnings is used. PR-URL: nodejs#55496 Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it>
274b3bb
to
f7bdcee
Compare
Failed to start CI⚠ Something was pushed to the Pull Request branch since the last approving review. ✘ Refusing to run CI on potentially unsafe PRhttps://github.com/nodejs/node/actions/runs/11789132997 |
Last Jenkins CI was green, FWIW. Coverage is failing due to a pre-existing issue #55510 |
Running CITGM again: v22.x-staging: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/3509/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RSLGTM
I'm generally in favor of landing this, but are we ready for all the issues that will be opened because of debug-js/debug#975 / npm/cli#7857 ? |
Isn't it fixed by not warning inside node_modules? |
Ah, maybe? Since the warning is still here with the latest v23.2.0, is it a patch that's only going to be pushed to v22? |
Yes, the patch for disabling warning from node_modules here is only targeting 22.x. We could consider landing it in 23, if necessary, but then that's 23. |
A warning is not a big deal, but it would be great to port this warning patch to v23 indeed. Otherwise, many OSS lib authors would get issues opened asking to fix those warnings while we can't easily do anything about it. It happened for me with things like punycode, and will likely happen again. Other example issues mentioning these warnings in v23: |
I think we have a few options that would need input from @nodejs/releasers and/or @nodejs/tsc
The patch in question is 14170f8?w=1 which is not that complex. |
FYI I think tentative -- the table was updated with generated dates by the tool added in nodejs/Release#1058. |
iirc there's precedent for option 3 and in this case it does not sound unreasonable. |
Did this patch ever landed on |
No, it was intended for v22.x (see https://github.com/nodejs/TSC/blob/main/meetings/2024-10-02.md), though now there is request to get it to v23.x as well. Not sure if we should just land it on main, though that might just make everything further and we'll have to wait for the next year to release it... |
oh yeah, I think we should def land it on |
I split out the patch in #55960 |
As part of the standard experimental feature graduation policy, when we unflagged require(esm) we moved the experimental warning to be emitted when require() is actually used to load ESM, which previously was an error. However, some packages in the ecosystem have already being using try-catch to load require(esm) to e.g. resolve optional dependency, and emitting warning from there instead of throwing directly could break the CLI output. To reduce the disruption for releases, as a compromise, this patch skips the warning if require(esm) comes from node_modules, where users typically don't have much control over the code. This warning will be eventually removed when require(esm) becomes stable. This patch was originally intended for the LTS releases, though it seems there's appetite for it on v23.x as well so it's re-targeted to the main branch. PR-URL: #55960 Refs: #55217 Refs: #52697 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jacob Smith <jacob@frende.me>
added: | ||
- v22.0.0 | ||
- v20.17.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change looks unrelated (EDIT: I see that it was in my original PR, so "unrelated" is an unfair characterization, but still it should not be included in the backport PR), also on release branches we only keep track of the changes for that release line.
added: | |
- v22.0.0 | |
- v20.17.0 | |
added: v22.0.0 |
This backports the following PRs that are related to the unflagging of --experimental-require-module:
Note that I don't think this backport PR is strictly required - the PRs seem to land cleanly on v22.x except the unflagging commit has a small conflict in the YAML changelog description. This PR is mostly opened to look for regressions in v22 with CITGM.
Refs: #52697