GeezerVison

What's the use case for this? I want to make sure we're not allowing the suppression of warnings that we might not actually want to permit the suppression of.....

What's the use case for this? I want to make sure we're not allowing the suppression of warnings that we might not actually want to permit the suppression of.....

This is a really good question and I can see both sides as valid. First off, I think that the experimental warning feature is a good way to inform users about the stability of features they're using in their code and how quickly they can change. However, I can also see the argument about these warnings potentially being too numerous and could create clutter in error logs while a user is searching for an issue that is occurring in their code or debugging an unexpected condition. We've tried to reduce that as much as possible by not repeating experimental warnings and granted, they're probably not too difficult to ignore. But I think giving users an additional level of control to suppress these warnings while not suppressing all warnings provides some benefit in the long run as they can better monitor warnings which are more critical to them. Additionally, I think that since the user has to explicitly request to ignore these through the CLI, they will be knowledgeable with what they're doing and accidental misuse will be low.

I'm not really in favor of this change right now. The warnings in this case serve a very important purpose.

IMO - given that experimental features are out for use, it is fair for users to expect to use those cleanly, or at least have some control over the prints. It may be unnecessary to force warnings every time, onto an informed user?

I don't really have a strong opinion on whether or not this should land, but...

While I do think experimental warnings are important, I think explicitly opting out of them with a feature like this is a better option than, say, silencing all warnings with --no-warnings.

@Qard -

Using experimental features should be discouraged for normal use.

But then we have been producing experimental features in release builds, including LTS all these while - I guess with an intent of folks using and experimenting those in the field?

Allowing the warnings to be silenced suggests that the warnings against using those features are not important.

May be at least for a subset of the users, who have seen the warning a few times, want to supress it because otherwise their scripts / monitors that process the stderr will have to be modified to ignore these warnings, and at a later point in time when a feature stabilizes they will have to again modify those scripts to remove those special code. With this feature in place, they don't have to do these special care.

My bottom line is: if we are looking at the field to gather usability insights to improve on experimental features, we also need to provide improved user experience with these features.

In my opinion, the only reason they are shipped behind runtime flags on release builds rather than behind build flags is because it increases the likelihood people will actually try the new things out and encounter the bugs so we can be more certain of stability before giving it a proper release. If you had to build your own custom Node.js just to try a new feature I suspect out "release" features would be a lot less stable due to less user testing.

i don't think experimental warnings should be suppressible. when experimental features are enabled, node is running in an unstable state, and that should be made very clear to whoever is running it. (maybe we should whitelist them from --no-warnings)

Allow list SGTM.

@devsnek -

i don't think experimental warnings shouldn't be suppressible.

looks like the double negative statement (which translates to experimental warnings should be suppressible) is NOT what you meant?

when experimental features are enabled, node is running in an unstable state, and that should be made very clear to whoever is running it.

One can bring in a counter argument that: on the same ground, --no-warnings should be removed as well?

There is no disagreement about the importance of the experimental warnings. The question is about its consumability - when message are produced every run of the workload without a bailout option, one can argue that users are being punished for using it.

We have evidence of experimental features being used in production (async_hooks , diagnostic report etc.) despite their stability status, owing to their unique capabilities. Implementing this option will help Node.js users to run their production workloads with less clutter.

Since this seems to be a controversial change, do we want to have TSC evaluate for a final decision to either move forward or close this PR and related issue/feature request?

I would be ok with moving forward on this if it were a mechanism to disable specific identified warnings rather than an entire category. Specifically, we have the ability to attach identifiers to warnings that we currently use for deprecations (e.g. the DEP00XX identifiers) and can also use for experimental warnings (e.g. a hypothetical EXP00XX identifier). We could then disable specific warnings by id using the command-line flag (e.g. node --no-warnings=EXP0001,DEP0022) to disable only specific individual warnings.

This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open.

Closing this because it has stalled. Feel free to reopen if this PR is still relevant, or to ping the collaborator who labelled it stalled if you have any questions.

2 PRs on it, re-opening

So what exactly is holding this up at the moment? What work needs to be done to close it out? Not sure if I can be of help or not but I'm having to disable all warnings with --no-warnings at the moment, which I really don't like doing. I figured it was obvious I had made an informed decision to use an experimental feature since I have to explicitly invoke node with --experimental-vm-modules, so getting blasted with the same warning telling me that repeatedly while testing code just needlessly clutters and obfuscates the output. I'm a lot more worried about broadly disabling all warnings just to make my output readable than I am about using an experimental feature that I'm well-aware I'm using.

So what exactly is holding this up at the moment?

I think someone needs to put in the work to make this so that the user chooses which experimental warnings to hide.

@jasnell @Qard You're the ones with the request-for-changes. Can you confirm or clarify?

My concern is that many people will just always run with that flag and ignore experimental warnings entirely. Even worse would be if test runners and the like start using it by default, creating an environment with different behaviour from what is typical.

Experimental features should not be used in a production app. We're just further enabling people to ignore our judgement about what is and is not ready for production use. If you're worried about log pollution it's because you're using something in prod that you should not be. If a thing is really not actually experimental anymore we should be advocating for marking that thing as stable, not for allowing experimental warnings to be ignored.

I feel we need to be very intentional with our messaging around experimental features that they are not safe to use in production and could change or disappear at any time. The presence of experimental features in a release is intended solely for experimentation--we want people to try out an uncertain idea and provide feedback so we can iterate and move it towards stable. When it is actually ready for people to use in prod we will mark it stable. Maybe we need another stage between experimental and stable to indicate something that's no longer in a could-break-at-any-time state but not quite yet at a point where we want to make firm promises about the stability?

Maybe we need another stage between experimental and stable to indicate something that's no longer in a could-break-at-any-time state but not quite yet at a point where we want to make firm promises about the stability?

I would be good with anything that adds meaningful clarity.

For any robust production setup, the messages aren't an issue, IMO. It's easy to ship logs off to a log management system and filter through them as needed. The issue is spamming of the console in development. At the same time, I think that's really beside the point.

The code I'm working on right now isn't high stakes and it isn't in production yet. The experimental features are only required for the test environment, anyway. The production code doesn't use anything experimental. I've spent plenty of time digging through the code and related issues for Node and many libs, just to get an experimental environment working and to make sure I understand the limitations and potential problems. That's all to say, I know what I'm doing. As someone that knows what I'm doing, has a use for the experimental feature, is happy to test the experimental feature and provide feedback, and has already knowingly & explicitly enabled the feature, I would like the option to not have my console spammed with messages telling me what I've done.

Also, I don't think the console spamming is what's stopping test runners from relying on experimental features. They're already in a position to easily filter out that noise if desired. In reality, it would incur too much risk to support. It would be insane for any remotely popular project which is exactly why it isn't already being done.

I maintain that my preference is for an option to disable individual experimental warnings by code/id as opposed to all warnings, and for that not to be permitted on NODE_OPTIONS.

I very much agree. That would be ideal. I have no idea how to implement that myself or I would. It sounds a bit more involved than a naive, if less ideal, solution. Would it be worth an initial quick, blunt mechanism before iterating to the more nuanced flags?

Not permitting disabling experimental warnings and not permitting disabling experimental warnings in NODE_OPTIONS just means people will use --no-warnings, which is already permissible in NODE_OPTIONS. People can make an informed decision when opting to use an experimental warning, even globally through NODE_OPTIONS and IMO should be allowed to own this decision without having a non-dismissable banner litter the output of their every Node invocation. I believe not allowing to disable experimental warnings in NODE_OPTIONS would do more harm than allowing it due to this.

Maybe we need another stage between experimental and stable to indicate something that's no longer in a could-break-at-any-time state but not quite yet at a point where we want to make firm promises about the stability?

I would be good with anything that adds meaningful clarity.

For any robust production setup, the messages aren't an issue, IMO. It's easy to ship logs off to a log management system and filter through them as needed. The issue is spamming of the console in development. At the same time, I think that's really beside the point.

The code I'm working on right now isn't high stakes and it isn't in production yet. The experimental features are only required for the test environment, anyway. The production code doesn't use anything experimental. I've spent plenty of time digging through the code and related issues for Node and many libs, just to get an experimental environment working and to make sure I understand the limitations and potential problems. That's all to say, I know what I'm doing. As someone that knows what I'm doing, has a use for the experimental feature, is happy to test the experimental feature and provide feedback, and has already knowingly & explicitly enabled the feature, I would like the option to not have my console spammed with messages telling me what I've done.

Also, I don't think the console spamming is what's stopping test runners from relying on experimental features. They're already in a position to easily filter out that noise if desired. In reality, it would incur too much risk to support. It would be insane for any remotely popular project which is exactly why it isn't already being done.

Same here, Jest kicks of as many processes as there are test files (as possible.) Therefore the spamming is real.

Same here, Jest kicks of as many processes as there are test files (as possible.) Therefore the spamming is real.

Ditto. Using ava and every test file logs this warning:

(node:20159) ExperimentalWarning: Custom ESM Loaders is an experimental feature.
This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

Landed on this PR after seeing this several 1,000 times and hoping there was a simple way to suppress the warning (because I'm using esbuild-node-loader to avoid a separate TS compilation step.)

I would be ok with moving forward on this if it were a mechanism to disable specific identified warnings rather than an entire category.

💯 agree. I would much prefer not being forced into an all-or-nothing situation on this.

FWIW, in the above case I'd expect to fix the issue with something like --ignore-warning=20159.

We discussed in the TSC meeting today (note we only had 6 people so a smallish subset). From the discussion there would be no objection from those who were there if there was an option to disabled specific experimental warnings and that was also supported in NODE_OPTIONS.

@medikoo

In tests sometimes I mock modules with variants that expose a subset of properties. I also tweak modules cache (using just publicly documented API), so new require's point exports mocks and not original exports.

Having such setup, with Node.js v14 I started to observe significant warnings pollution due to that

The warnings should vanish in case the modules contain a .loaded property set to true. Do you mind trying that out?

The cache is public and that can not change anymore. It has also been publicly documented from very early on. It's existance is documented but not really how to add new entries. This is something that would be benefitial. We could in theory detect properties being added to the cache and ignore those from the circularity check. The implementation of such check would not be trivial though (using proxies with a complicated behavior).

@BridgeAR great thanks for that hint. Interestingly I do not see those warnings anymore, but also a lot of has changed in this code area since my last comment.

If I'll see the warnings again, I'll check if your solution helps

Closing this in favor of #40940, being able to skip individual warnings is going to be less contentious.