Node.js DeprecationWarning suppression and selective filtering
0 reputation · 27 Feb 2024, 23:00 UTC
0 reputation · 27 Feb 2024, 23:00 UTC
The NO_DEPRECATION environment variable and the --no-deprecation flag provide a mechanism to silence DeprecationWarning types emitted via process.emitWarning. This is often used in CI/CD pipelines to reduce log noise from third-party dependencies that have not yet updated their API usage.
Current implementation operates as a binary switch for the entire Node.js process. There is no native configuration to define a whitelist or blacklist for specific modules or categories of deprecations. This creates a conflict between the need for clean logs and the requirement to monitor critical API removals in core application code.
Given the behavior in Node.js LTS releases (v18 through v22), what are the supported methods for filtering these warnings by module origin without disabling all deprecation alerts? Is there a documented way to intercept these warnings programmatically to implement conditional suppression?
No supported native method exists in Node.js LTS v18 through v22 to filter DeprecationWarning by module origin without disabling all deprecation alerts. The built-in controls----no-deprecation and NO_DEPRECATION--are binary, process-wide switches. There is also no documented public API to intercept these warnings programmatically for conditional suppression.
--no-deprecation and NO_DEPRECATION=1 silence every DeprecationWarning emitted through process.emitWarning.--trace-deprecation and --throw-deprecation affect stack traces and error conversion, not selective filtering.DEP0001, but Node core does not expose an allowlist or denylist by module or category.process.emitWarning, inspecting warning.type, warning.code, and the stack, then conditionally forwarding or suppressing. This is undocumented, fragile, and can miss internally emitted warnings or conflict with other tooling.Core applies the suppression switch before module origin is evaluated, so warnings from your application and from node_modules dependencies are indistinguishable to the flag. That is why global suppression also hides deprecations in code you intend to monitor.
NO_DEPRECATION=1 node app.js or node --no-deprecation app.js. Accept that this also suppresses your own code's deprecations.process.emitWarning at application startup to inspect warning.code and the stack trace, then suppress matching entries. Treat this as temporary and review it after each Node upgrade.node --no-deprecation app.js
NO_DEPRECATION=1 node app.js
Run either command and confirm that deprecation messages disappear. To test interception, create a script that calls process.emitWarning('msg', 'DeprecationWarning', 'DEP9999'), patch process.emitWarning, and confirm suppression works only for userland-emitted warnings.
Do the deprecation warnings originate from code you can modify, or only from dependencies in node_modules? This determines whether you should fix the source or rely on global suppression.
This answer assumes warnings are emitted through process.emitWarning with type DeprecationWarning. Behavior is consistent across LTS v18–v22 but may change in future releases. Monkey-patching is not a stable Node API and should be marked for review before production use.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 28 Feb 2024, 00:54 UTC
Node.js emits deprecation notices through process.emitWarning. By attaching a listener to process.on('warning', handler) you receive a Warning object whose stack contains the originating module path. Inspect warning.code, warning.name, or the stack to decide whether to suppress that single warning.
In Node.js v20+ the warning.ignore flag can be set to true inside the handler. This silences only that warning’s default stderr output, leaving the rest of the process unaffected.
The NO_DEPRECATION env var or --no-deprecation still turns off all deprecation warnings globally, so the listener must be added before the first warning is emitted.