Request: Omitting experimental flags from new config file

[jasnell]

Opening this issue on behalf of several individuals with whom I spoke about the new configuration file landed in #57016 ...

The specific request from three separate people in separate conversations is to specifically omit --experimental-* flags from the configuration file format, even if hose flags are otherwise allowed in NODE_OPTIONS.

/cc @marco-ippolito @ljharb @ShogunPanda @anonrig @joyeecheung @mhdawson @bnb (as the folks who authored/reviewed that PR)

[marco-ippolito]

I'm not against it but I would like the decision to be properly motivated.
Experimental options are already hardcoded in .env files and package.json

[jasnell]

Absolutely fair... I opened the issue so that we can discuss the motivation. I can see it both ways so not sure I'm best to articulate the motivation. I'm sending this issue link to multiple people with the hope they will weigh in.

[pmarchini]

A thought regarding a specific use case: the test runner has many experimental flags and is, in fact, largely experimental.
The configuration file potentially has a strong application in this specific area.

I wonder, for this reason, if it might make sense to consider handling exceptions when it comes to not allowing experimental flags to be managed via the file.

[joyeecheung]

I wonder if we can solve the problem by:

• Make sure experimental features that we don't want widespread usage always lead to a runtime warning
• Make sure this warning cannot be disabled via the config file (if the --no-warnings or other warning flags specifically come from the config file, they are not effective for experimental warnings...or deprecation warnings, for that matter).
• When we want experimental features to get wider usage, we either remove the warning, or allow it to be disabled by files

[marco-ippolito]

What about denylist some of the experimental feature we don't want to support in the config file?

[richardlau]

What about denylist some of the experimental feature we don't want to support in the config file?

The problem with that is if we forget to add a new experimental feature to the denylist and then subsequently add it later it might break someone who has already added it to their config file.

[marco-ippolito]

Then for the reason above I don't think we should do a granular configuration, either we do something that applies to all experimental flags or do nothing. Disable silencing warnings in the config file should be enough.

[bnb]

I'm generally +1 to @joyeecheung's suggestions as general enhancements, regardless of which direction we go with this discussion.

What about denylist some of the experimental feature we don't want to support in the config file?

I'm concerned about this because then you have to know which ones work and which don't and it could be very confusing for developers. IMO being consistent with how things are applied broadly in a config file is super important for good DX.

I'd like to propose something totally different:

We could build-in a feature that can maintain flags for you, as the project prefers. As a hypothetical example, did Node.js v32.0.0 promote the experimental-jsonc-support feature to stable? Run something like node --upgrade-noderc or node --upgrade-noderc --only=experimental-features and we can automatically sort it out for you.

This could enable a few things:

• Potential for more rapid adoption of the .noderc file because we're doing good work that's annoying to do currently
• The project can have more direct input with our users on how flags are used, providing a path for users to rely on our defaults
• Bring upgrades both of Node.js itself and of features we're shipping more to the forefront for developers
• This one's a bit more half-baked, but I think it could serve as an escape hatch for maintainers both who do want to support experimental features and who don't as it upstreams the problem of maintaining those features to us

[GeoffreyBooth]

I'm concerned about this because then you have to know which ones work and which don't and it could be very confusing for developers. IMO being consistent with how things are applied broadly in a config file is super important for good DX.

I strongly agree with this. I already find it very frustrating that some things work as flags but not in NODE_OPTIONS. That's already a bug, IMO, and something we should make consistent. Likewise, all flags and NODE_OPTIONS should be supported in the config file. It's not a config file if it doesn't fully let you configure Node.

• Make sure experimental features that we don't want widespread usage always lead to a runtime warning

Sure, this can correlate with the experimental stages if we want a standardized way to handle this.

• Make sure this warning cannot be disabled via the config file (if the --no-warnings or other warning flags specifically come from the config file, they are not effective for experimental warnings...or deprecation warnings, for that matter).
• When we want experimental features to get wider usage, we either remove the warning, or allow it to be disabled by files

In other words, the config file would not let you do certain configuration that's already possible via flags or NODE_OPTIONS. I don't want to need a mix of flags and the config file to get Node to behave the way I want. To me that feels user-hostile.

/cc @marco-ippolito @ljharb @ShogunPanda @anonrig @joyeecheung @mhdawson @bnb (as the folks who authored/reviewed that PR)

I think we need nodejs/admin#953, as I'm finding it hard to follow these issues without targeted notifications.

[github-actions]

This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.