Spaces:
Running
Running
# signal-exit | |
When you want to fire an event no matter how a process exits: | |
- reaching the end of execution. | |
- explicitly having `process.exit(code)` called. | |
- having `process.kill(pid, sig)` called. | |
- receiving a fatal signal from outside the process | |
Use `signal-exit`. | |
```js | |
// Hybrid module, either works | |
import { onExit } from 'signal-exit' | |
// or: | |
// const { onExit } = require('signal-exit') | |
onExit((code, signal) => { | |
console.log('process exited!', code, signal) | |
}) | |
``` | |
## API | |
`remove = onExit((code, signal) => {}, options)` | |
The return value of the function is a function that will remove | |
the handler. | |
Note that the function _only_ fires for signals if the signal | |
would cause the process to exit. That is, there are no other | |
listeners, and it is a fatal signal. | |
If the global `process` object is not suitable for this purpose | |
(ie, it's unset, or doesn't have an `emit` method, etc.) then the | |
`onExit` function is a no-op that returns a no-op `remove` method. | |
### Options | |
- `alwaysLast`: Run this handler after any other signal or exit | |
handlers. This causes `process.emit` to be monkeypatched. | |
### Capturing Signal Exits | |
If the handler returns an exact boolean `true`, and the exit is a | |
due to signal, then the signal will be considered handled, and | |
will _not_ trigger a synthetic `process.kill(process.pid, | |
signal)` after firing the `onExit` handlers. | |
In this case, it your responsibility as the caller to exit with a | |
signal (for example, by calling `process.kill()`) if you wish to | |
preserve the same exit status that would otherwise have occurred. | |
If you do not, then the process will likely exit gracefully with | |
status 0 at some point, assuming that no other terminating signal | |
or other exit trigger occurs. | |
Prior to calling handlers, the `onExit` machinery is unloaded, so | |
any subsequent exits or signals will not be handled, even if the | |
signal is captured and the exit is thus prevented. | |
Note that numeric code exits may indicate that the process is | |
already committed to exiting, for example due to a fatal | |
exception or unhandled promise rejection, and so there is no way to | |
prevent it safely. | |
### Browser Fallback | |
The `'signal-exit/browser'` module is the same fallback shim that | |
just doesn't do anything, but presents the same function | |
interface. | |
Patches welcome to add something that hooks onto | |
`window.onbeforeunload` or similar, but it might just not be a | |
thing that makes sense there. | |