GeezerVison

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

@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.

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.

@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.

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.

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

without knowing, it was marked as resolved

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

so the function takes a string and it matches with the function emitExperimentalWarning(feature) like this 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.