https://github.com/tapjs/signal-exit

when you want to fire an event no matter how a process exits.
https://github.com/tapjs/signal-exit

Last synced: 3 months ago
JSON representation

when you want to fire an event no matter how a process exits.

• Host: GitHub
• URL: https://github.com/tapjs/signal-exit
• Owner: tapjs
• License: isc
• Created: 2015-05-16T05:21:30.000Z (over 9 years ago)
• Default Branch: main
• Last Pushed: 2023-10-17T22:25:48.000Z (about 1 year ago)
• Last Synced: 2024-05-15T13:26:04.444Z (6 months ago)
• Language: TypeScript
• Homepage:
• Size: 502 KB
• Stars: 180
• Watchers: 11
• Forks: 24
• Open Issues: 4
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md
  • License: LICENSE.txt

Awesome Lists containing this project

• awesome-cross-platform-nodejs - signal-exit - Cross-platform `exit` handler. (Libraries / Signals)
• awesome-cli - signal-exit - When you want to fire an event no matter how a process exits. (Helpful)
• awesome - tapjs/signal-exit - when you want to fire an event no matter how a process exits. (TypeScript)
• awesome-javascript - signal-exit
• awesome-javascript - signal-exit

README

        
# 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.