(unintended?) npm@8 breaking change: return status different for `npm outdated`

[nassau-t]

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?

>node
Welcome to Node.js v16.10.0.
Type ".help" for more information.
> require('child_process').execSync('npm outdated -g --depth=0')
<Buffer 50 61 63 6b 61 67 65 20 20 20 20 20 20 20 20 20 20 20 20 20 43 75 72 72 65 6e 74 20 20 20 57 61 6e 74 65 64 20 20 20 4c 61 74 65 73 74 20 20 4c 6f 63 ... 216 more bytes>

What do you see instead?

>node
Welcome to Node.js v16.11.0.
Type ".help" for more information.
> require('child_process').execSync('npm outdated -g --depth=0')
Uncaught Error: Command failed: npm outdated -g --depth=0
    at checkExecSyncError (node:child_process:826:11)
    at Object.execSync (node:child_process:900:15) {
  status: 1,
  signal: null,
  output: [
    null,
    <Buffer 50 61 63 6b 61 67 65 20 20 20 20 20 20 20 20 20 20 20 20 20 43 75 72 72 65 6e 74 20 20 20 57 61 6e 74 65 64 20 20 20 4c 61 74 65 73 74 20 20 4c 6f 63 ... 216 more bytes>,
    <Buffer >
  ],
  pid: 14996,
  stdout: <Buffer 50 61 63 6b 61 67 65 20 20 20 20 20 20 20 20 20 20 20 20 20 43 75 72 72 65 6e 74 20 20 20 57 61 6e 74 65 64 20 20 20 4c 61 74 65 73 74 20 20 4c 6f 63 ... 216 more bytes>,
  stderr: <Buffer >
}

Additional information

No response

[targos]

/cc @nodejs/npm

It seems that npm@8 now exits with code 1. npm@7 exited with code 0.

[Mesteery]

I think he uses npm@6 since the depth option in npm outdated does not exist in either npm@7 or npm@8.
AFAIK, npm outdated exits with a code 1 if there are outdated dependencies otherwise 0.
You could catch or use spawnSync.

[nassau-t]

C:\temp>npm -v
8.0.0

C:\temp>npm outdated -g --depth=0
Package Current Wanted Latest Location Depended by
@types/node 16.10.2 16.10.3 16.10.3 node_modules/@types/node global
webpack-dev-server 4.3.0 4.3.1 4.3.1 node_modules/webpack-dev-server global

[nassau-t]

I think he uses npm@6 since the depth option in npm outdated does not exist in either npm@7 or npm@8. AFAIK, npm outdated exits with a code 1 if there are outdated dependencies otherwise 0. You could catch or use spawnSync.

This is a nonsense. If there is no error, it must exit with code 0. (And outdated dependencies aren't an error).

[Mesteery]

This is a nonsense. If there is no error, it must exit with code 0. (And outdated dependencies aren't an error).

Not necessarily, many CLI/commands have this same behavior, for example, some Git commands.

[nassau-t]

I have been looking how exit status code works, and It seems that:

• 0 exit status means the command was successful without any errors.
• A non-zero (1-255 values) exit status means command was a failure. Exit status 1 is a Catchall for general errors. And so on.

I don't see any error in a list of outdated dependencies. It's only the response of the question that I am asking about.
The exit status could be 1 if there were some error when executing this command.

So, in the case that git is working that way, then git is also working wrong.

[mscdex]

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.

[nassau-t]

A command must return non zero code is there is an error, or a zero code status if all it's ok. That's the way it works.

The way you change it, because "without having to try to parse the output, whose format could easily change" is very wrong. If you want to do that, you can return nothing on stdout if all it's ok (unix alike). Or return something if you must report something.
But return a non zero code when there isn't any error, that's not the way.

Another option, if you want to parse it, is to add a --json parameter to the command, to receive the output as a json, and to be able to parse it easily.

[mscdex]

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 0, which can still be a bit vague but usually indicates some sort of positive ("success"/"good"/"ok") signal (again even in the case of grep it means one or more lines were matched, which can be viewed as a positive signal).

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.

[nassau-t]

So, as you say, if a status code of 0 is all ok, any number higher of 0 means that something wrong happened. It's obvious.

A --json solution can be over designed. But perhaps a --count parameter, returning only the number of results is a lot easier to parse, and has more meaning. So you could have a status code 0, so all went ok, and you can read only a number (0, 1, 2, ...) that represents the number of results.

It was working well (in my opinion) in the 16.x branch until 16.11.

C:\temp>node -v
v16.10.0

C:\temp>npm -v
7.24.0

C:\temp>node
Welcome to Node.js v16.10.0.
Type ".help" for more information.
> require('child_process').execSync('npm outdated -g --depth=0')
<Buffer 50 61 63 6b 61 67 65 20 20 20 20 20 20 20 20 20 20 20 20 20 43 75 72 72 65 6e 74 20 20 20 57 61 6e 74 65 64 20 20 20 4c 61 74 65 73 74 20 20 4c 6f 63 ... 216 more bytes>

But It works bad (in my opinion) also in the 14.x branch:

>node
Welcome to Node.js v14.18.0.
Type ".help" for more information.
> require('child_process').execSync('npm outdated -g --depth=0')
Uncaught Error: Command failed: npm outdated -g --depth=0
    at checkExecSyncError (child_process.js:790:11)
    at Object.execSync (child_process.js:863:15) {
  status: 1,
  signal: null,
  output: [
    null,
    <Buffer 50 61 63 6b 61 67 65 20 20 20 20 20 20 20 20 20 20 20 20 20 43 75 72 72 65 6e 74 20 20 20 57 61 6e 74 65 64 20 20 20 4c 61 74 65 73 74 20 20 4c 6f 63 ... 222 more bytes>,
    <Buffer >
  ],
  pid: 5264,
  stdout: <Buffer 50 61 63 6b 61 67 65 20 20 20 20 20 20 20 20 20 20 20 20 20 43 75 72 72 65 6e 74 20 20 20 57 61 6e 74 65 64 20 20 20 4c 61 74 65 73 74 20 20 4c 6f 63 ... 222 more bytes>,
  stderr: <Buffer >
}
> .exit

C:\temp>npm -v
6.14.15

[nassau-t]

I don't see git returning status code distinct of 0 as usual as you said...?!

C:\sites\peticions_plugin>node
Welcome to Node.js v16.11.0.
Type ".help" for more information.
> require('child_process').execSync('git status')
<Buffer 4f 6e 20 62 72 61 6e 63 68 20 6d 61 73 74 65 72 0a 59 6f 75 72 20 62 72 61 6e 63 68 20 69 73 20 75 70 20 74 6f 20 64 61 74 65 20 77 69 74 68 20 27 6f ... 54 more bytes>
> .exit

C:\sites\peticions_plugin>echo hello >README.md

C:\sites\peticions_plugin>node
Welcome to Node.js v16.11.0.
Type ".help" for more information.
> require('child_process').execSync('git status')
<Buffer 4f 6e 20 62 72 61 6e 63 68 20 6d 61 73 74 65 72 0a 59 6f 75 72 20 62 72 61 6e 63 68 20 69 73 20 75 70 20 74 6f 20 64 61 74 65 20 77 69 74 68 20 27 6f ... 270 more bytes>
> require('child_process').execSync('git diff')
<Buffer 64 69 66 66 20 2d 2d 67 69 74 20 61 2f 52 45 41 44 4d 45 2e 6d 64 20 62 2f 52 45 41 44 4d 45 2e 6d 64 0a 69 6e 64 65 78 20 33 66 33 66 36 35 39 2e 2e ... 596 more bytes>

[Trott]

Off-topic stuff about grep return codes

This is a nonsense. If there is no error, it must exit with code 0.

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, which returns 0 if it finds a match, 1 if it doesn't find a match (failure, but not an error), and 2 for errors.

$ 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 npm outdated must return error codes according to your expectations. Node.js will use whatever npm hands it as the return status.