Is the special case for exit code 2 necessary? (JSHint integration)

[pghalliday]

I see that exit code 2 has special meaning for bash (http://tldp.org/LDP/abs/html/exitcodes.html) however I am trying to use nodemon with JSHint. Unfortunately JSHint uses exit code 2 to signal that there are lint errors so nodemon exits the first time I forget a semi-colon with the following error.

[nodemon] failed to start process, possible issue with exec arguments

I can't actually see any reason nodemon should exit in this case, whether JSHint should be using that exit code or not

I have raised a corresponding issue at jshint/jshint#2672

[pghalliday]

In case anyone lands here with the same problem my simple workaround for now is to call nodemon like this:

nodemon -e js -x 'jshint --exclude node_modules . || exit 1'

[lukeapage]

the code is here:

nodemon/lib/monitor/run.js

Line 118 in e177dd7

if (code === 2) {

it was added with this commit:
9651ab8

[lukeapage]

this is what node document as its exit codes: https://github.com/nodejs/node-v0.x-archive/blob/master/doc/api/process.markdown#exit-codes
and they purposefully avoid 2.

[remy]

Okay, I think it makes more sense to change nodemon rather than hope for a breaking change to update in jshint. I can't remember exactly why I added this code, but I was being intentional.

Do we think the entire condition should be removed based on the exit codes from node's docs?

[lukeapage]

Well, it seems you do get warning 2 when its a bad command, but you can get error code 2 from any app for a variety of different reasons - I don't think you can assume its a bad command. Maybe log a warning? or add an option for fatalErrorCode?

Probably both nodemon should be more accepting or error code 2 and jshint shouldn't use it.

[dallonf]

Seems that Mocha also throws error code 2. +1 for Nodemon accepting it as a normal failure.

[deepwell]

I'd love to see this fixed as well. Mocha exits with code 2 when there are 2 errors (code 3 for 3 errors, etc.). That mocha "feature" defeats nodemon from continually watching and re-running the tests as I fix them.

[stale]

This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3

[dallonf]

Imo, this is still a problem. Unless this is an explicit "won't fix" from the devs, this should remain open.

[frosas]

@remy, you already suggested to remove that condition. Is there anything deterring you from doing that? The change is minimal (I can submit a PR if that's the issue) but I understand it supposes introducing a breaking change (thus, requiring a new major version).

[markbirbeck]

In case anyone else arrives here in 2018 onwards, it's still an issue with Mocha. The two solutions proposed that change the error code both work:

mocha || true

or:

mocha || exit 1

Perhaps a command-line option to tell nodemon to ignore the error code would work?

(Sorry I don't have time to do a PR at the moment, but perhaps in a month or so!)

[neilyio]

This seems to pose a problem when you also want -- <your args> ........... to tell nodemon stop slurping arguments.

Python libraries return an exit code 2 sometimes, and right now I have a command like this in package.json:

scripts: {
    "parse-reload": "nodemon --exec 'python -m parse || exit 1' --"
}

This allows me to npm run parse-reload. I'd like to be able to pass arbitrary arguments so that they are forwarded to the inner Python process, like this: npm run parse-reload my-file.txt my-other-file.txt

If I omit the || exit 1 from the end of the command, then nodemon correctly forwards the arguments when I use the -- directive. The command effectively becomes: nodemon --exec 'python -m parse my-file.txt my-other-file.txt'. This works wonderfully, until a Python library throws an error code 2, and then nodemon quits.

So I add the || exit 1 to the end of parse-reload, along with --, to form the example you see above. Now, nodemon can smoothly reload on error 2. However, I can no longer pass my arguments, because the -- appends the arguments to exit 1, as opposed to python -m parse. The command effectively becomes nodemon --exec 'python -m parse || exit 1 my-file.txt my-other-file.txt'.

I think this could easily be solved if nodemon would expose a nodemon.json option that could toggle this error 2 behaviour.

[daveyarwood]

This is still an issue when using nodemon with tsc. There are plenty of valid reasons why a process would exit with the code 2, so this behavior seems silly to me, and having to add || exit 1 is an awkward workaround.

The workaround works, so I'm not complaining, but just my 2 cents.