-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
(unintended?) npm@8 breaking change: return status different for npm outdated
#40382
Comments
/cc @nodejs/npm It seems that npm@8 now exits with code 1. npm@7 exited with code 0. |
This comment has been minimized.
This comment has been minimized.
C:\temp>npm -v C:\temp>npm outdated -g --depth=0 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Most likely the non-zero exit code is intended for use in scripting/automation to reliably know if there are outdated dependencies without having to try to parse the output, whose format could easily change. Also you could look at it this way if you view all non-zero exit codes as "failures": npm failed to find no outdated dependencies. |
This comment has been minimized.
This comment has been minimized.
From my experience, non-zero exit codes for non-errors is very common in the *nix world. Even common utilities like grep do this (e.g. to signal if a match was made or not). While Bash and others may have recommended meanings for various exit codes, there is no universal standard that everyone is required to follow. I would say the only commonly agreed upon meaning is for an exit status of Since the change in npm seems to have originated in a new major version (of npm) and npm still uses semver, it seems a sensible breaking change to me. Perhaps the course of action here would be to submit an issue on the npm CLI issue tracker to ask for this particular change to be noted in their v8.0.0 changelog. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Off-topic stuff about grep return codes
Non-zero return status can indicate error but can also indicate other non-error failures. A well known example, and one that seems parallel to the case here, is $ grep bar README.md ; echo $?
bar
0
$ grep foo README.md ; echo $?
1
$ grep ajdkflajsdkl ajdkfljasdklfj ; echo $?
grep: ajdkfljasdklfj: No such file or directory
2
$ I'm going to close this because it is in the wrong repository. You may open this issue in https://github.com/npm/cli if you want to argue that |
I'd like to keep this open because npm 8 was rushed into Node.js 16 with this message:
|
Works for me. I certainly agree it's a breaking change! |
This comment has been minimized.
This comment has been minimized.
In parallel, I have opened an issue on npm site npm/cli#3871 |
npm outdated
I hid a bunch of comments here as off-topic. (@mscdex, I didn't hide yours because you're a Collaborator and subject to different rules, but if you feel like hiding or editing yours to keep this concise and focused, please do.) The issue at hand is that the return status is different between npm@7 and npm@8, and that that is apparently an unintended breaking change. Whether or not the changed behavior is correct is immaterial. |
To clarify: this behavior did not actually change in npm v8; it changed in npm v7.24.2. In other words, it would have happened even if node had updated to npm 7 latest and not npm 8. npm v7.24.1 and below do not exit nonzero in this scenario. |
Created RFC npm/rfcs#473 |
From npm/cli#3871 (comment):
As @nassau-t indicates in a previous comment, they've opened an RFC in the npm repository about it. Given all this, I'm going to close this again. Because this wasn't a change in npm 8 (and therefore is not a result of #40369) and is not an issue with Node.js but with npm, the npm org is the right place for this to be discussed and for action (if any) to be taken. @targos If you disagree and still think this should remain open, by all means, re-open this issue. Thanks! |
If someone else have to handle this exception... BAD SOLUTION: A clear, smart program:
That fails, evidently.
GOOD SOLUTION: 2nd attempt, with a particular exception handled
More clear, as seen (ironic), but hey, it works!!!
|
Version
v16.11.0
Platform
Microsoft Windows NT 10.0.19042.0 x64
Subsystem
No response
What steps will reproduce the bug?
require('child_process').execSync('npm outdated -g --depth=0')
How often does it reproduce? Is there a required condition?
every time
What is the expected behavior?
What do you see instead?
Additional information
No response
The text was updated successfully, but these errors were encountered: