lib: add option to silence warnings

[PoojaDurgad]

Introduce an option --suppress-warnings to silence experimental and deprecation warnings for specified features

Fixes: #30810

Co-Authored-By: Cody Deckard [email protected]

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[benjamingr]

Why?

[cjihrig]

Why?

There is prior discussion in #30810 and #31000.

[benjamingr]

@cjihrig in that case this PR goes against the TSC consensus discussed in the PR?

Edit: Oh I see this allows disabling the warning for a specific feature and not all features.

[cjihrig]

I haven't reviewed this PR yet, but IIRC, the idea was that we could support silencing specific warnings, not just experimental warnings.

[mscdex]

It looks like this option doesn't allow specifying multiple features, is this intentional?

[PoojaDurgad]

I'm working to address the issues.

[jasnell]

Any process.emitWarning() may include a code option.

Rather than introducing a new cli option just to disable experimental warnings, we should extend the existing --no-warnings to allow silencing specific codes:

$ node --no-warnings=EXP001,DEP002

Or, by warning type:

$ node --no-warnings=ExperimentalWarning,DeprecationWarning

Note: We do not currently assign individual codes to experimental warnings. We should start doing so.

Additionally, the way this PR makes the change, experimental warnings would not be emitted to the process.on('warning') event, which is a mistake. The existing --no-warnings flag will only suppress the default action of printing warnings to stderr but those will still be emitted to process.on('warning'). This is intentional behavior that should be preserved here as well.

[PoojaDurgad]

@mscdex , @jasnell , @benjamingr - I pushed some changes . please have a look.

• Introduced new flag --suppress-warnings
• Introduced codes for experimental warnings.
• Enabled the flag to take multiple codes.
• Adjusted tests to the changes.
• Added a test.

[jasnell]

What's the difference between this and the existing --no-warnings flag?

[PoojaDurgad]

@jasnell - I have introduced the new flag --suppress-warnings and also introduced codes for experimental warnings which enables this flag to silence the experimental and deprecation warnings for supplied codes. The idea is to support silencing warnings for experimental and deprecation warnings and enabled the flag to take multiple codes.

[jasnell]

Yes, and what I'm saying is that the --no-warnings flag can just be extended to support this without introducing a new flag. --no-warnings (with no arguments) would continue to work as it does today, while --no-warnings={list of codes} would suppress the named codes. In either case, the documentation here should indicate that the flag takes a list of codes.

[PoojaDurgad]

@jasnell - well instead of introducing new cli option we can extend the existing --no-warnings option right . yeah I understood and thanks for the review.

[jasnell]

This is not the right way to include the code. The emitWarning api already has an option for including the code correctly. Also, I would add this check into the emitWarning processing so it can be applied generically to all warning types.

[jasnell]

Not sure why this comment was marked resolved as the issue is still there.

[PoojaDurgad]

without knowing, it was marked as resolved

[PoojaDurgad]

@jasnell - I have a doubt , can you confirm one thing please , the experimental warning vm.measureMemory API calls emitExperimentalWarning like this emitExperimentalWarning('vm.measureMemory');

node/lib/vm.js

Line 390 in 22293ea

emitExperimentalWarning('vm.measureMemory');

so the function takes a string and it matches with the function emitExperimentalWarning(feature) like this

node/lib/internal/util.js

Line 188 in 51b4367

function emitExperimentalWarning(feature) {

so if I'm not wrong this call does not include an option for codes. If the above file modification is not the right way to include the code, then how to do that? can you suggest me.

[martinmunillas]

@PoojaDurgad are you willing to keep working on this?, I ask because is something I'm interested in too and i would be glad to help

[bnoordhuis]

I'm going to close this because the pull request has a great many conflicts and because the requested feature from #30810 has been implemented but thanks anway, @PoojaDurgad, it's much appreciated.

[haidaqn]

I am getting this error when integrating nextjs 13 with clerk and using node 16.13.0 : " ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use node --trace-warnings ... to show where the warning was created) "