src: unflag --experimental-default-config-file

[marco-ippolito]

Let's unflag it in Node.js v25

[nodejs-github-bot]

Review requested:

• @nodejs/config
• @nodejs/test_runner
• @nodejs/tsc

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.13%. Comparing base (bba07d7) to head (6043c63).
Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #58703      +/-   ##
==========================================
- Coverage   90.17%   90.13%   -0.04%     
==========================================
  Files         637      637              
  Lines      188023   187999      -24     
  Branches    36887    36878       -9     
==========================================
- Hits       169552   169461      -91     
- Misses      11223    11286      +63     
- Partials     7248     7252       +4     

Files with missing lines	Coverage Δ
lib/internal/process/pre_execution.js	92.43% <100.00%> (-0.43%)	⬇️
lib/internal/test_runner/runner.js	92.64% <ø> (-0.01%)	⬇️
src/node_options.cc	84.44% <ø> (-0.12%)	⬇️
src/node_options.h	97.84% <100.00%> (ø)

... and 31 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[anonrig]

This is still an experimental feature (line 991). What's the goal of this change? We should also make it stable at the same time, or not enable it this early.

[marco-ippolito]

Why make it stable? It's still experimental but people can start using it with a nice dx, so that node automatically picks up node.config.json without the flag

[RafaelGSS]

Wouldn't it make more sense to stabilize this feature before enabling it by default?

• Stabilize the default config file (remove the --experimental)
• Enable it by default

[marco-ippolito]

To answer both @RafaelGSS and @anonrig it does not make sense to stabilize and then unflag because similarly to --experimental-strip-types we can only determine the impact it has on ecosystem if enabled by default.
For example if the default name conflicts with some other framework that we are unaware of, and we have to make a change, we would not be able to do it after making it stable without deprecation cycle.

[anonrig]

I don't think we should unflag this while having the config file as an experimental feature.

[marco-ippolito]

There is no way it can become stable before being unflagged as I explained above. @nodejs/tsc

[RafaelGSS]

There is no way it can become stable before being unflagged as I explained above. @nodejs/tsc

I won’t be too strong about this, but that’s usually how it works for most experimental flags we introduce—for example, the Permission Model. If we enable an experimental feature by default before addressing all the necessary security patches (while the feature is still opt-in and experimental), it feels a bit odd and too risky in my opinion. Some features just need more time for people to adopt and test. Forcing them (or enabling by default) feels like pushing it too much, IMO.