Skip to content
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

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

Closed
pghalliday opened this issue Sep 9, 2015 · 13 comments
Closed
Labels
stale no activity for 2 weeks

Comments

@pghalliday
Copy link

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 pghalliday changed the title Is the special case for exit code 2 necessary? Is the special case for exit code 2 necessary? (JSHint integration) Sep 9, 2015
@pghalliday
Copy link
Author

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
Copy link

the code is here:

if (code === 2) {

it was added with this commit:
9651ab8

@lukeapage
Copy link

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
Copy link
Owner

remy commented Sep 9, 2015

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
Copy link

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
Copy link

dallonf commented Nov 25, 2015

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

@deepwell
Copy link

deepwell commented Mar 1, 2016

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
Copy link

stale bot commented Dec 5, 2017

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

@stale stale bot added the stale no activity for 2 weeks label Dec 5, 2017
@stale stale bot closed this as completed Dec 12, 2017
@dallonf
Copy link

dallonf commented Dec 12, 2017

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

@frosas
Copy link

frosas commented Dec 12, 2017

@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
Copy link

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!)

remy pushed a commit that referenced this issue Jul 17, 2018
Only exit after code 2 if it happened quickly; improve messaging (recommend `||exit 1`)

If nodemon exits _quickly_ on code 2, then it'll bail and warn. If it's after ~500ms, then it assumes that the sub-process intentionally used exit 2 (like mocha or stylelint), it won't bail and treat it as a failure (like a crash).

Props to @joeytwiddle

Fixes #496 
Fixes #627
SalathielGenese added a commit to squall-io/squall that referenced this issue Dec 14, 2019
@neilyio
Copy link

neilyio commented Jun 4, 2021

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale no activity for 2 weeks
Projects
None yet
Development

No branches or pull requests

9 participants