-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
LTS (16.17.0) includes buggy version of npm #44406
Comments
The Node.js team cannot fix npm directly. npm is maintained by GitHub. Once a new version is published by the npm team, you can update npm independently of Node.js. |
Then please revert You can always update npm independently of Node.js, as you so stated. |
Similarly, you should be able to downgrade using |
So what you imply here is that a major version of Node.js marked as LTS does not exhibit any forms of stability and/or compatibility? Should I be sticking with EOL versions instead to ensure things won't be broken any further? |
I'm sorry, how and where did I imply that? This is one of the most ridiculous straw men I have ever seen and if you insist on resorting to logical fallacies instead of having a useful discussion, I don't think myself or other project maintainers will have much interest in discussing this with you. I explained to you that we cannot fix the alleged bug in npm ourselves because we do not maintain npm (#44406 (comment)). I also gave you a solution that should allow you to work around the issue locally by installing a version of npm that suits your needs without having to switch to a different version of Node.js (#44406 (comment)). I did not give you an answer as to whether we would downgrade npm on the v16 release line for various reasons:
Following your attempt at logical conclusions, are you certain that downgrading npm will not break anything? Are there no features or bug fixes that would be undone by an npm downgrade and that some v16 users might rely upon? Those are the stability guarantees you seem to desire, so please make sure that downgrading npm will provide those guarantees. You can, of course, open PRs against npm or against Node.js to either fix the bug or to propose some other solution, such as downgrading npm, and they will go through the regular review process. |
Thanks for the clarification − I was under the (mistaken) impression that this issue will not be rectified going forward. Please accept my sincere apology. Though I am confused as to why this rather visible issue managed to slip through the Node.js release process after it has been reported for months, I understand that no procedure's perfect and as long as the goal is to eventually address the issue at hand, I will just roll back to the last version of Node.js v16 that does not bundle this latest version of |
It does seem like this issue should have been caught by CITGM, which I believe the releasers run, but maybe only when they expect a breaking change and therefore not on LTS releases. I'm not 100% sure of the process there. I'm also not 100% sure of how the lookup.json in CITGM works, but it does appear that UglifyJS is skipped as flaky in at least some situations. Maybe @nodejs/releasers and/or @nodejs/citgm can shed a little light. If the issue is the lookup.json settings, it's possible that there's either a bug to fix in UglifyJS or a quirk on our end to accommodate. If the issue is that we don't run CITGM on LTS releases, I doubt that's going to change (because the release process is already onerous enough) but something we can do is run CITGM on every PR that updates |
CITGM should be run on every release, and it usually is as it is part of the documented release process. We only rarely do not run it - typically only in the case of urgent security or bug fixes where we know the CITGM run results would be unlikely to alter our decision to include a patch.
With This is a general issue with CITGM right now. Last time I crunched the numbers, I realised of the 115 modules we had in the lookup at the time, at least 85 were marked as skipped or flaky on at least one platform or version. Both skip and flaky will mask errors. CITGM failures per run are ranging from 65-120 recently, which includes a lot of noise for the releaser to sift through to try and identify any new regressions. All of this unfortunately means we're less likely to catch regressions. Releasers and various other contributors have worked to keep on top of the CITGM failures/flakes to keep the regression tool working as effectively as possible, but it's a never-ending challenge with too few people. Our team at Red Hat even had a dedicated 'CITGM greenness day' to try and resolve some failures and reduce noise but it was soon back up to where it is now. To resolve this I think we either need to be encouraging more contributions to keeping CITGM healthy, or explore alternative approaches. |
I haven't had time to look into that specific issue, but if the only thing it does is add annoying logs to the output, CITGM wouldn't be able to catch the problem. |
If you look at the issue reported in npm, you'll see that the problem is not specific to UglifyJS at all − the example is just to illustrate how it affects very basic use cases. Assuming this version of npm went into Node.js v18 before eventually making its way into v16 LTS, I would have encountered and reported it earlier if it weren't for the showstopper #43129 which means I haven't been able to use v18 on any development environments. |
Hey all... I've surfaced this with the @nodejs/npm team to figure out what's going on and if we can get this fixed soon. As mentioned above by targos there are a number of other bugs fixed in the newer versions of npm so I don't think we should consider reverting. This also doesn't seem to be breaking enough to require an emergency LTS release, but please correct me if you disagree. Will aim to get an answer from the team about timeline on a fix, but since I haven't dug in it is possible this might be quite a bit of work to get done, will lyk as soon as I do. |
Thanks for looking into this @MylesBorins! It's a terminal display glitch as far as I can tell from npm/cli#5024 and running the reproduction steps provided in this issue. I don't believe this warrants an extra LTS release outside the regular release cycle. |
Version
v16.17.0
Platform
Microsoft Windows [Version 10.0.14393]
Subsystem
npm
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
Runs without superflous
[...] - : timing config:load:flatten Completed in 3ms
spamming every line of log output.What do you see instead?
Additional information
It is now becoming a major nuisance since it affects LTS version of Node.js
Please either fix or revert this buggy version of
npm
from Node.jsSee: npm/cli#5024
The text was updated successfully, but these errors were encountered: