[DevTools Bug]: standalone bundle should be rebuilt with a patched ws 7.x release

Website or app

React DevTools standalone package: https://github.com/react/react/tree/main/packages/react-devtools-core

Repro steps

Version

react-devtools-core@8.0.0

Problem

The published dist/standalone.js contains a frozen copy of ws@7.5.10.
react-devtools-core declares ws as ^7, and a fresh npm installation now
resolves that external dependency to ws@7.5.13, but the standalone server
executes the copy compiled into its bundle instead.

The current repository lockfile resolves ws@^7 to 7.5.10. The lockfile entry
before #37029 also resolved both ws@^7 and ws@^7.4.6 to 7.5.10, so this was
not introduced by the Playwright update.

This is relevant because the upstream fragment-memory fix was released in
ws@7.5.11. The upstream advisory and fix are already public:
https://github.com/advisories/GHSA-96hv-2xvq-fx4p

Verification

1. Install the published package:

   npm init -y
   npm install react-devtools-core@8.0.0
   

2. Inspect node_modules/react-devtools-core/dist/standalone.js.map.

3. Compare its 13 node_modules/ws sourcesContent entries with the published
   ws@7.5.10 source files. All 13 match byte-for-byte. In particular, the
   following files remain in their 7.5.10 form and differ from 7.5.11:

   • lib/receiver.js
   • lib/websocket-server.js
   • lib/websocket.js

4. The compiled standalone artifact also lacks the
   WS_ERR_TOO_MANY_BUFFERED_PARTS guard introduced by the 7.5.11 fix.

5. A fresh dependency resolution installs ws@7.5.13, but changing or
   overriding that external package does not change dist/standalone.js.

Expected behavior

The published standalone artifact should be built with a patched supported
7.x release of ws.

Suggested fix

Update ws to 7.5.11 or later, regenerate dist/standalone.js, and publish a
new react-devtools-core release containing the rebuilt artifact. Updating the
lockfile alone will not change the copy already frozen in published packages.

This is separate from #37624, which concerns forwarding the host argument to
httpServer.listen(). Fixing that binding behavior does not update the frozen
dependency used when standalone DevTools is intentionally exposed through a
VM, container, port forward, or reverse proxy.

How often does this bug happen?

Every time

DevTools package (automated)

No response

DevTools version (automated)

No response

Error message (automated)

No response

Error call stack (automated)

Error component stack (automated)

GitHub query string (automated)