Prevent direct use of process.exit() for better error handling and testing.
✅ This rule is included in the node logical presets.
Calling process.exit() immediately terminates the Node.js process without allowing proper cleanup or error handling.
This makes code harder to test and can lead to resource leaks or incomplete operations.
Throwing errors provides better stack traces and allows proper error handling, while returning exit codes from CLI entry points maintains testability.
NodeJS.Process.exit(code?: number | string |null): never
The process.exit() method instructs Node.js to terminate the process
synchronously with an exit status of code. If code is omitted, exit uses
either the 'success' code 0 or the value of process.exitCode if it has been
set. Node.js will not terminate until all the 'exit' event listeners are
called.
To exit with a 'failure' code:
import { exit } from'node:process';
exit(1);
The shell that executed Node.js should see the exit code as 1.
Calling process.exit() will force the process to exit as quickly as possible
even if there are still asynchronous operations pending that have not yet
completed fully, including I/O operations to process.stdout and process.stderr.
In most situations, it is not actually necessary to call process.exit() explicitly. The Node.js process will exit on its own if there is no additionalwork pending in the event loop. The process.exitCode property can be set to
tell the process which exit code to use when the process exits gracefully.
For instance, the following example illustrates a misuse of the process.exit() method that could lead to data printed to stdout being
truncated and lost:
import { exit } from'node:process';
// This is an example of what *not* to do:
if (someConditionNotMet()) {
printUsageToStdout();
exit(1);
}
The reason this is problematic is because writes to process.stdout in Node.js
are sometimes asynchronous and may occur over multiple ticks of the Node.js
event loop. Calling process.exit(), however, forces the process to exit before those additional writes to stdout can be performed.
Rather than calling process.exit() directly, the code should set the process.exitCode and allow the process to exit naturally by avoiding
scheduling any additional work for the event loop:
import process from'node:process';
// How to properly set the exit code while letting
// the process exit gracefully.
if (someConditionNotMet()) {
printUsageToStdout();
process.exitCode=1;
}
If it is necessary to terminate the Node.js process due to an error condition,
throwing an uncaught error and allowing the process to terminate accordingly
is safer than calling process.exit().
In Worker threads, this function stops the current thread rather
than the current process.
@since ― v0.1.13
@param ― code The exit code. For string type, only integer strings (e.g.,'1') are allowed.
exit(0);
var process: NodeJS.Process
process.
NodeJS.Process.exit(code?: number | string |null): never
The process.exit() method instructs Node.js to terminate the process
synchronously with an exit status of code. If code is omitted, exit uses
either the 'success' code 0 or the value of process.exitCode if it has been
set. Node.js will not terminate until all the 'exit' event listeners are
called.
To exit with a 'failure' code:
import { exit } from'node:process';
exit(1);
The shell that executed Node.js should see the exit code as 1.
Calling process.exit() will force the process to exit as quickly as possible
even if there are still asynchronous operations pending that have not yet
completed fully, including I/O operations to process.stdout and process.stderr.
In most situations, it is not actually necessary to call process.exit() explicitly. The Node.js process will exit on its own if there is no additionalwork pending in the event loop. The process.exitCode property can be set to
tell the process which exit code to use when the process exits gracefully.
For instance, the following example illustrates a misuse of the process.exit() method that could lead to data printed to stdout being
truncated and lost:
import { exit } from'node:process';
// This is an example of what *not* to do:
if (someConditionNotMet()) {
printUsageToStdout();
exit(1);
}
The reason this is problematic is because writes to process.stdout in Node.js
are sometimes asynchronous and may occur over multiple ticks of the Node.js
event loop. Calling process.exit(), however, forces the process to exit before those additional writes to stdout can be performed.
Rather than calling process.exit() directly, the code should set the process.exitCode and allow the process to exit naturally by avoiding
scheduling any additional work for the event loop:
import process from'node:process';
// How to properly set the exit code while letting
// the process exit gracefully.
if (someConditionNotMet()) {
printUsageToStdout();
process.exitCode=1;
}
If it is necessary to terminate the Node.js process due to an error condition,
throwing an uncaught error and allowing the process to terminate accordingly
is safer than calling process.exit().
In Worker threads, this function stops the current thread rather
than the current process.
@since ― v0.1.13
@param ― code The exit code. For string type, only integer strings (e.g.,'1') are allowed.
exit(1);
if (
const error:any
error) {
var process: NodeJS.Process
process.
NodeJS.Process.exit(code?: number | string |null): never
The process.exit() method instructs Node.js to terminate the process
synchronously with an exit status of code. If code is omitted, exit uses
either the 'success' code 0 or the value of process.exitCode if it has been
set. Node.js will not terminate until all the 'exit' event listeners are
called.
To exit with a 'failure' code:
import { exit } from'node:process';
exit(1);
The shell that executed Node.js should see the exit code as 1.
Calling process.exit() will force the process to exit as quickly as possible
even if there are still asynchronous operations pending that have not yet
completed fully, including I/O operations to process.stdout and process.stderr.
In most situations, it is not actually necessary to call process.exit() explicitly. The Node.js process will exit on its own if there is no additionalwork pending in the event loop. The process.exitCode property can be set to
tell the process which exit code to use when the process exits gracefully.
For instance, the following example illustrates a misuse of the process.exit() method that could lead to data printed to stdout being
truncated and lost:
import { exit } from'node:process';
// This is an example of what *not* to do:
if (someConditionNotMet()) {
printUsageToStdout();
exit(1);
}
The reason this is problematic is because writes to process.stdout in Node.js
are sometimes asynchronous and may occur over multiple ticks of the Node.js
event loop. Calling process.exit(), however, forces the process to exit before those additional writes to stdout can be performed.
Rather than calling process.exit() directly, the code should set the process.exitCode and allow the process to exit naturally by avoiding
scheduling any additional work for the event loop:
import process from'node:process';
// How to properly set the exit code while letting
// the process exit gracefully.
if (someConditionNotMet()) {
printUsageToStdout();
process.exitCode=1;
}
If it is necessary to terminate the Node.js process due to an error condition,
throwing an uncaught error and allowing the process to terminate accordingly
is safer than calling process.exit().
In Worker threads, this function stops the current thread rather
than the current process.
@since ― v0.1.13
@param ― code The exit code. For string type, only integer strings (e.g.,'1') are allowed.
exit(1);
}
function
functionexitHandler():void
exitHandler() {
var process: NodeJS.Process
process.
NodeJS.Process.exit(code?: number | string |null): never
The process.exit() method instructs Node.js to terminate the process
synchronously with an exit status of code. If code is omitted, exit uses
either the 'success' code 0 or the value of process.exitCode if it has been
set. Node.js will not terminate until all the 'exit' event listeners are
called.
To exit with a 'failure' code:
import { exit } from'node:process';
exit(1);
The shell that executed Node.js should see the exit code as 1.
Calling process.exit() will force the process to exit as quickly as possible
even if there are still asynchronous operations pending that have not yet
completed fully, including I/O operations to process.stdout and process.stderr.
In most situations, it is not actually necessary to call process.exit() explicitly. The Node.js process will exit on its own if there is no additionalwork pending in the event loop. The process.exitCode property can be set to
tell the process which exit code to use when the process exits gracefully.
For instance, the following example illustrates a misuse of the process.exit() method that could lead to data printed to stdout being
truncated and lost:
import { exit } from'node:process';
// This is an example of what *not* to do:
if (someConditionNotMet()) {
printUsageToStdout();
exit(1);
}
The reason this is problematic is because writes to process.stdout in Node.js
are sometimes asynchronous and may occur over multiple ticks of the Node.js
event loop. Calling process.exit(), however, forces the process to exit before those additional writes to stdout can be performed.
Rather than calling process.exit() directly, the code should set the process.exitCode and allow the process to exit naturally by avoiding
scheduling any additional work for the event loop:
import process from'node:process';
// How to properly set the exit code while letting
// the process exit gracefully.
if (someConditionNotMet()) {
printUsageToStdout();
process.exitCode=1;
}
If it is necessary to terminate the Node.js process due to an error condition,
throwing an uncaught error and allowing the process to terminate accordingly
is safer than calling process.exit().
In Worker threads, this function stops the current thread rather
than the current process.
@since ― v0.1.13
@param ― code The exit code. For string type, only integer strings (e.g.,'1') are allowed.
If you are working with very specific Node.js system-level code that genuinely requires immediate process termination without cleanup, you might choose not to enable this rule.
However, such cases are rare, and most applications benefit from proper error handling.
Alternately, if your application is not very large and/or doesn’t intend to live for a long time, proper process flow logic might not be worth it for you to implement.
In that case this rule might not be for you.
