fix: exit codes in node v20

[MichaelBitard]

Fixes #6399

Properly this time I hope :)

[wraithgar]

This subtly changes the behavior of when npm shows the "A complete log of this run can be found". Because this PR sets the exitCode variable no matter what, instead of only if we had a specific error, it will now show up during an npm audit where vulnerabilities are found. This is not what we want.

showLogFileError = (hasLoadedNpm && npm.silent) || noLogMessage
    ? false
    : !!exitCode

I think we have to leave exitCode undefined until we're ready to send it to process.exit and only then do we override it with process.exitCode if the exitCode variable is still undefined.

[MichaelBitard]

I added a noLogMessage to true when something goes wrong, we can suppose the error message has already been printed.

I think we have to leave exitCode undefined until we're ready to send it to process.exit and only then do we override it with process.exitCode if the exitCode variable is still undefined.

I'm not sure to understand what it means.

If something set process.exitCode to something other than 0, that means the script failed at some point, and we should exit our process with an exitCode different than 0 rigth?

[wraithgar]

If something set process.exitCode to something other than 0, that means the script failed at some point, and we should exit our process with an exitCode different than 0 rigth?

Correct, but we can't set our exitCode variable yet because that's doing some heavy lifting later on to determine if we need to show the extra logging message. Typically if a command sets exitCode but doesn't throw, that message isn't shown. Think of when you type npm foo, which isn't a command. You get an exit code of 1 but you don't get a message saying where to view the log of the run. That extra message is reserved for when a command throws an error. It's a subtle difference in signals from commands.

So, we have to wait till we call process.exit to see if we want to use exitCode or process.exitCode

[MichaelBitard]

Ok I think I understand, what I pushed after fixes these cases I think. If not I'll have to think of another way of fixing this Le mer. 17 mai 2023 à 18:15, Gar ***@***.***> a écrit :

…

If something set process.exitCode to something other than 0, that means the script failed at some point, and we should exit our process with an exitCode different than 0 rigth? Correct, but we can't set our exitCode *variable* yet because that's doing some heavy lifting later on to determine if we need to show the extra logging message. Typically if a command sets exitCode but doesn't throw, that message isn't shown. Think of when you type npm foo, which isn't a command. You get an exit code of 1 but you don't get a message saying where to view the log of the run. That extra message is reserved for when a command throws an error. It's a subtle difference in signals from commands. So, we have to wait till we call process.exit to see if we want to use exitCode or process.exitCode — Reply to this email directly, view it on GitHub <#6461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFHMR7KU5KJUDNSKKDG5TXGT2QHANCNFSM6AAAAAAYFHN2PU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[wraithgar]

Yep, you got there a different way by altering the other variable accordingly. It works, and smoke tests still pass. We'll add node 20 to our CI soon and cover any other holes soon hopefully.