src: make node.config.json throw at unknown fields

[marco-ippolito]

The documentation is correct but the implementation was not

[nodejs-github-bot]

Review requested:

• @nodejs/config

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.66%. Comparing base (2428030) to head (8923655).
⚠️ Report is 70 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62992      +/-   ##
==========================================
+ Coverage   89.63%   89.66%   +0.03%     
==========================================
  Files         706      707       +1     
  Lines      219219   219512     +293     
  Branches    42004    42088      +84     
==========================================
+ Hits       196499   196832     +333     
+ Misses      14622    14581      -41     
- Partials     8098     8099       +1     

Files with missing lines	Coverage Δ
src/node_config_file.cc	83.96% <100.00%> (+0.23%)	⬆️

... and 60 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.

[ljharb]

won't this mean that you can't make a config file that supports multiple versions of node and gracefully uses features from the newer ones when available?

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/72968/

[marco-ippolito]

won't this mean that you can't make a config file that supports multiple versions of node and gracefully uses features from the newer ones when available?

Yes but also means if you mispell a configuration you will know. I prefer correctness over convenience.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/72973/

[ljharb]

It's not just about convenience, though - it's about being able to support multiple node versions at one time, which also makes upgrading easier (and not supporting that makes upgrading harder).

I very much prioritize correctness, but having a closed config every time is highly likely to hold back the ecosystem.

[marco-ippolito]

The support for multiple versions of node in the same configuration was never planned and should be discouraged. The $schema needs to match with version being used. I think a possible solution to this problem would be support an array of configurations and node can pick the right one based on version. This plus the ability to extend (like tsconfig)