Package Exports
- log-process-errors
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (log-process-errors) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
Log all process errors on the console (or using a custom logger): uncaughtException, unhandledRejection, rejectionHandled, multipleResolves and warning.

Usage (preferred)
Require this module with the -r CLI flag.
node -r log-process-errors ...Usage (custom)
In order to customize options, log-process-errors/custom must be required
like this instead:
const logProcessErrors = require('log-process-errors/custom')
logProcessErrors(options)options is an optional object with the following properties:
log{function}getLevel{function}getMessage{function}colors{boolean}(default:false)skipEvent{function}exitOn{string[]}(default:['uncaughtException'])
logProcessErrors() should be called as early as possible in the code.
log-process-errors modifies logging globally. This is not recommended for
libraries since their users might not expect this side effect. Also this might
lead to conflicts between libraries. Libraries should use the
-r log-process-errors CLI flag instead of
require().
Duplicate warnings
It is recommended to use the
--no-warnings CLI flag or
the
NODE_NO_WARNINGS=1
environment variable to prevent warnings being logged twice.
Process exit
The exitOn option specifies which event should trigger process.exit(1):
- the default value is
['uncaughtException']. This is the default behavior of Node.js. It's also recommended by the official documentation. - we recommend using
['uncaughtException', 'unhandledRejection']instead since this will be the future default behavior of Node.js - to prevent any
process.exit(1), use[]
process.exit(1) will only be fired after successfully logging the event.
Custom logging
By default events will be logged to the console (e.g. console.error()).
This behavior can be overridden with the log option. For example to log events
with Winston instead:
logProcessErrors({
log(message, level, info) {
winstonLogger[level](message)
},
})The function's arguments are:
message{string}: nice and detailed description of the event. Can be customized with thegetMessageoption.level{string}: log level. Can be customized with thegetLeveloption.info{object}: event information
If logging is asynchronous, the function should return a promise (or use
async/await). This is not necessary if logging is using streams (like
Winston).
Log level
By default the log level will be warn for warning events and error for
the other events.
This can be overridden by using the getLevel option. It should be a function
function using info as argument and returning a string
among error, warn, info or debug.
logProcessErrors({
getLevel({ eventName }) {
return eventName === 'uncaughtException' ? 'error' : 'warn'
},
})Log message
A nice-looking and descriptive log message is generated by default.
The message will be colorized unless either:
- the output does not support colors
- the option
colorsis set tofalse
The message generation can be overridden by using the getMessage option. It
should be a function using info as argument and returning
a string.
Skipping events
Events can be skipped with the skipEvent option. It should be a function
using info as argument and returning true or false.
For example to skip warning events:
logProcessErrors({
skipEvent({ eventName }) {
return eventName === 'warning'
},
})Event information
The options log, getLevel, getMessage and skipEvent all receive as
argument an info object with information about the event. It has the following
properties:
eventName{string}: can beuncaughtException,unhandledRejection,rejectionHandled,multipleResolvesorwarningerror{any}:- either the value thrown by
uncaughtException - or the error emitted by
warning.error.codeanderror.detailmight be defined. - it is usually an
Errorinstance but could technically be anything
- either the value thrown by
promiseState{string}: whether the promise wasresolvedorrejectedpromiseValue{any}: value resolved/rejected by the promisesecondPromiseState,secondPromiseValue: likepromiseStateandpromiseValuebut for the second time the promise was resolved/rejected
Whether the properties above are defined or not depends on the event name:
eventName: always presenterror: only onuncaughtExceptionandwarningpromiseState,promiseValue: only onunhandledRejection,rejectionHandledandmultipleResolvessecondPromiseState,secondPromiseValue: only onmultipleResolves
The following properties are also defined with the getMessage option:
level{string}colors{object}: Chalk instance to colorize strings (disabled if the optioncolorsisfalse)
Stop logging
Logging can be stopped by firing the function returned by logProcessErrors()
const logProcessErrors = require('log-process-errors/custom')
const stopLogging = logProcessErrors(options)
stopLogging()