1 | # signal-exit
|
2 |
|
3 | When you want to fire an event no matter how a process exits:
|
4 |
|
5 | - reaching the end of execution.
|
6 | - explicitly having `process.exit(code)` called.
|
7 | - having `process.kill(pid, sig)` called.
|
8 | - receiving a fatal signal from outside the process
|
9 |
|
10 | Use `signal-exit`.
|
11 |
|
12 | ```js
|
13 | // Hybrid module, either works
|
14 | import { onExit } from 'signal-exit'
|
15 | // or:
|
16 | // const { onExit } = require('signal-exit')
|
17 |
|
18 | onExit((code, signal) => {
|
19 | console.log('process exited!', code, signal)
|
20 | })
|
21 | ```
|
22 |
|
23 | ## API
|
24 |
|
25 | `remove = onExit((code, signal) => {}, options)`
|
26 |
|
27 | The return value of the function is a function that will remove
|
28 | the handler.
|
29 |
|
30 | Note that the function _only_ fires for signals if the signal
|
31 | would cause the process to exit. That is, there are no other
|
32 | listeners, and it is a fatal signal.
|
33 |
|
34 | If the global `process` object is not suitable for this purpose
|
35 | (ie, it's unset, or doesn't have an `emit` method, etc.) then the
|
36 | `onExit` function is a no-op that returns a no-op `remove` method.
|
37 |
|
38 | ### Options
|
39 |
|
40 | - `alwaysLast`: Run this handler after any other signal or exit
|
41 | handlers. This causes `process.emit` to be monkeypatched.
|
42 |
|
43 | ### Browser Fallback
|
44 |
|
45 | The `'signal-exit/browser'` module is the same fallback shim that
|
46 | just doesn't do anything, but presents the same function
|
47 | interface.
|
48 |
|
49 | Patches welcome to add something that hooks onto
|
50 | `window.onbeforeunload` or similar, but it might just not be a
|
51 | thing that makes sense there.
|