Alexandro.Net

Version 1.0.0

@stackline/signal-exit

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

Independent maintenance of signal-exit 4.1.0. Original authors and licenses are retained.

Installation

# Preserve existing imports with an npm alias
npm install signal-exit@npm:@stackline/signal-exit@1.0.0
# Or use the scoped package name in your imports
npm install @stackline/signal-exit@1.0.0

Node.js: >=14. Read the compatibility and maintenance notes before migrating.

Usage and API

The reference below may retain upstream package names. Use the alias installation above to run those imports with this Stackline release.

@stackline/signal-exit

Independent maintenance fork of signal-exit@4.1.0. Original API, module format, runtime dependency ranges, and supported Node.js engines are preserved.

npm install @stackline/signal-exit
# Preserve existing imports with an npm alias:
npm install signal-exit@npm:@stackline/signal-exit@1.0.0

See UPSTREAM.md for the exact source and issue review, and CHANGELOG.md for focused maintenance changes. Development and release tooling runs on Node.js 24; that does not change the library runtime requirement.

Maintained by Stackline. Issues · npm.

Upstream documentation

signal-exit

When you want to fire an event no matter how a process exits:

Use signal-exit.

// 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

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.

Upstream issues and maintenance review

Upstream and issue review

Base: tapjs/signal-exit, npm signal-exit@4.1.0, commit 458776d9cf8be89712aa1f7b45bb2163ce15ef4a. Full Git history and upstream attribution are retained. Last npm publication: 2023-07-29T05:44:56.721Z. Release inactivity does not by itself prove abandonment.

Review: 2026-09-29T00:22:12.546517+00:00. Source coverage: Most recently updated 100 open and 30 closed issue/PR entries; PRs removed. This is triage evidence, not a claim of exhaustive review.

Confirmed #85: removing a listener from inside that callback mutated the active iteration and skipped the next listener. Iterate a snapshot and verify the exact A/B/alwaysLast sequence in a subprocess. Address #82 by normalizing a numeric string exitCode before delivering the documented numeric callback, with a subprocess regression. #80 asks for repeated captured signals, whereas 4.1.0 explicitly documents one-shot unloading; retain that contract. #78 involves simultaneous older-major copies; retain the upstream v3 coexistence workaround without claiming every host combination. #81 is optional tracing, not a confirmed defect. #84/#87 are unrelated content. Closed async-handler reports (#46/#70) are documented synchronous-exit limitations. Other closed engine/platform/debugger reports remain historical; real POSIX signal/exit subprocesses and Node14 compatibility are tested. Base license remains ISC; later upstream license changes are not imported.

Reviewed issue entries

Legacy test subprocess launchers now use execFile with argument arrays instead of shell command concatenation. This resolves CodeQL environment-path injection findings and handles executable/fixture paths containing spaces; it does not change the shipped runtime.

Release changes

Stackline changes

1.0.0 — 2026-09-28

Independent maintenance fork of signal-exit 4.1.0. Preserve published API, module exports and runtime engine compatibility. Confirmed #85: removing a listener from inside that callback mutated the active iteration and skipped the next listener. Iterate a snapshot and verify the exact A/B/alwaysLast sequence in a subprocess. Address #82 by normalizing a numeric string exitCode before delivering the documented numeric callback, with a subprocess regression. #80 asks for repeated captured signals, whereas 4.1.0 explicitly documents one-shot unloading; retain that contract. #78 involves simultaneous older-major copies; retain the upstream v3 coexistence workaround without claiming every host combination. #81 is optional tracing, not a confirmed defect. #84/#87 are unrelated content. Closed async-handler reports (#46/#70) are documented synchronous-exit limitations. Other closed engine/platform/debugger reports remain historical; real POSIX signal/exit subprocesses and Node14 compatibility are tested. Base license remains ISC; later upstream license changes are not imported.

Pinned development tools, real API and packed-consumer checks, GitHub CI/CodeQL gates, exact-artifact npm provenance and immutable release evidence are added. See UPSTREAM.md for limits of issue triage.

Changelog

4.1

4.0

3.0.3 (2020-03-26)

3.0.1 (2016-09-08)

3.0.0 (2016-06-13)

Release files and references

Package bytes, npm provenance and the immutable GitHub release were verified for this version. Security checks describe the reviewed release; documented compatibility risks and upstream reports are not blanket claims of resolution.