util: replace process.noDeprecation with getOptionValue for deprecation handling

[bjohansebas]

one less TODO

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.06%. Comparing base (049664b) to head (70538e6).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #59063      +/-   ##
==========================================
- Coverage   90.06%   90.06%   -0.01%     
==========================================
  Files         645      645              
  Lines      189130   189129       -1     
  Branches    37094    37098       +4     
==========================================
- Hits       170339   170335       -4     
+ Misses      11511    11471      -40     
- Partials     7280     7323      +43     

Files with missing lines	Coverage Δ
lib/internal/util.js	96.17% <100.00%> (-0.01%)	⬇️

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

[jasnell]

Unfortunately I don't think we can change this in this way. The process.noDeprecate property can be set dynamically at runtime and there are applications out there that take advantage of it. This change would end up breaking those existing uses. The irony here would be that we'd likely need to deprecate the process.noDeprecation flag.

[bjohansebas]

That I didn't know, and honestly, I'm not sure if that support for doing it dynamically should be deprecated.

[jasnell]

Yeah, in this case I think the TODO comment is just incorrect. As long as the option and the process.noDeprecation flag are compatible with each other and non-contradictory, then I would just remove the TODO comment and leave this as is.

[joyeecheung]

I think the TODO comment was left during refactoring when I was trying to figure out whether it's deprecatable at all - but at this point I am inclined to think that it is not as this shows up quite often in GitHub code search and also I am fairly certain there was one point I had to tell others to use it when there's no other alternative to avoid triggering excessive runtime warnings. It's probably better to document it instead of deprecating it at this point.

[jasnell]

Yeah, the existing documentation (https://nodejs.org/docs/latest/api/process.html#processnodeprecation) leaves a lot to be desired.