Skip to content

util: replace process.noDeprecation with getOptionValue for deprecation handling #59063

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions lib/internal/util.js
Original file line number Diff line number Diff line change
Expand Up @@ -182,8 +182,7 @@ function deprecate(fn, msg, code, useEmitSync, modifyPrototype = true) {
);

function deprecated(...args) {
// TODO(joyeecheung): use getOptionValue('--no-deprecation') instead.
if (!process.noDeprecation) {
if (!getOptionValue('--no-deprecation')) {
Copy link
Member

@jasnell jasnell Jul 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I don't think we can change this in this way. The process.noDeprecate property can be set dynamically at runtime and there are applications out there that take advantage of it. This change would end up breaking those existing uses. The irony here would be that we'd likely need to deprecate the process.noDeprecation flag.

Copy link
Member Author

@bjohansebas bjohansebas Jul 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That I didn't know, and honestly, I'm not sure if that support for doing it dynamically should be deprecated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, in this case I think the TODO comment is just incorrect. As long as the option and the process.noDeprecation flag are compatible with each other and non-contradictory, then I would just remove the TODO comment and leave this as is.

Copy link
Member

@joyeecheung joyeecheung Jul 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the TODO comment was left during refactoring when I was trying to figure out whether it's deprecatable at all - but at this point I am inclined to think that it is not as this shows up quite often in GitHub code search and also I am fairly certain there was one point I had to tell others to use it when there's no other alternative to avoid triggering excessive runtime warnings. It's probably better to document it instead of deprecating it at this point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the existing documentation (https://nodejs.org/docs/latest/api/process.html#processnodeprecation) leaves a lot to be desired.

emitDeprecationWarning();
}
if (new.target) {
Expand Down
Loading