It does not catch 'nodemon' reload.

[Zirafnik]

The hook does not catch 'nodemon' reloads. I am not sure if this is by design or not.

[jpmnteiro]

@Zirafnik nodemon sends a SIGUSR2 by default (see remy/nodemon#1098).

Looking at the source code for this package, it doesn't seem to register a handler for that signal, so I suspect it's relying on the exit (or beforeExit) hooks.

[sindresorhus]

I don't think we can simply register a handler for SIGUSR2, because the wanted behavior of the signal is sender-defined. To support it by default, we would have to be able to detect that the signal came from nodemon, which I'm not sure is possible in Node.js.

One way to solve this would be to get nodemon to set a certain environment variable that we could check.

// @jakobo

[thecodedrift]

Looking at the source code for this package, it doesn't seem to register a handler for that signal, so I suspect it's relying on the exit (or beforeExit) hooks.

That's correct. As Sindre said, SIGUSR2 is a userland signal, which means we cannot act on it. The signal data doesn't include parent processes either.

If you don't need asynchronous support, you can just change nodemon's signal via nodemon --signal to SIGINT or SIGTERM which would be sufficient.

On the asynchronous side, I'm hesitant to make responding to SIGTERM perform asynchronous cleanup. In practice, despite it being for polite termination, end developers do not hold that expectation.

A better option would be if nodemon could support --signal message which would send the signal identifier via IPC. This is how PM2 works in environments that don't support signaling. We then handle process.on("message", ...) and can shut down gracefully.