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[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 90.13%. Comparing base (bba07d7) to head (6043c63). :warning: Report is 503 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%)	:arrow_down:
lib/internal/test_runner/runner.js	92.64% <ø> (-0.01%)	:arrow_down:
src/node_options.cc	84.44% <ø> (-0.12%)	:arrow_down:
src/node_options.h	97.84% <100.00%> (ø)

... and 31 files with indirect coverage changes

:rocket: New features to boost your workflow:

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

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

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