Review requested:

• @nodejs/web-standards

We discussed these before. The legacy properties were proposed in #50521, which was closed because there was no clear Node.js use case or interoperability benefit.

navigator.onLine was proposed in #50224 and was blocked. The concerns were that online status is unreliable in Node.js, always returning true is not useful, and an implementation should also provide the online and offline events.

WinterTC55 Navigator Registry also says that non-browser runtimes should not implement these legacy properties. If they do, they should implement the whole compatibility group with a matching browser-style userAgent.

I don't think passing these WPT tests is enough reason to revisit those decisions unless there is new use case or compatibility issue that wasn't considered in #50521 and #50224.

I'm aware that previous attempts to add these properties were rejected, but I still think there is value in supporting them, particularly for Web Platform compatibility.

Passing the relevant WPTs means that code relying on navigator, including its legacy properties, can behave consistently when run in Node.js. While these properties are legacy, they remain widely available across browsers and may still be relied upon by existing code.

We've historically been willing to retain legacy functionality, such as punycode, as doing so provides compatibility with existing programs. I don't see this as really that different.

These properties add a small amount of effectively unchanging values. Given the low maintenance cost, I think supporting them for compatibility with widely available Web APIs is something we should be open to.

Even if other runtimes such as Deno and Bun don't support these properties, I don't think that should necessarily prevent us from doing so. There are 450K+ GitHub code results referencing them. While much of that code is undoubtedly intended for browsers, supporting these properties increases the amount of "general-purpose" JavaScript that can run in Node.js.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.31%. Comparing base (e2d7b34) to head (070ca92).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main   #65119      +/-   ##
==========================================
- Coverage   90.31%   90.31%   -0.01%     
==========================================
  Files         759      759              
  Lines      248290   248342      +52     
  Branches    46859    46868       +9     
==========================================
+ Hits       224241   224280      +39     
- Misses      15472    15511      +39     
+ Partials     8577     8551      -26     

... and 37 files with indirect coverage changes

• ❄️ 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.

bump @nodejs/web-standards

I'm not sure I understand the reasoning. What purpose do these serve beyond just passing tests? There are lots of web apis we don't need to implement.

The motivation is both passing tests and allowing legacy web code to run in Node.js. An extra 60ish lines of code is a small additional to make us pass WPT and allow similar legacy code to run.