Add WebSocket row to MSW comparison table

[jpr5]

Summary

• Adds missing "WebSocket APIs" row to the README MSW comparison table
• index.html already had this row — README was out of sync

🤖 Generated with Claude Code

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/CopilotKit/llmock/@copilotkit/llmock@28

commit: f15455c

[claude]

🔴 MSW v2 introduced a ws handler API for WebSocket mocking (docs), so the "No" in the MSW column is factually incorrect. The table already uses "Manual — ..." for SSE rows where MSW can do it but requires work; the WebSocket row should follow the same pattern, e.g., "Yes — in-process only" or "Manual — generic WS interception only".

Extended reasoning...

What the bug is

The new table row added by this PR claims MSW has No WebSocket support:

| WebSocket APIs | **Built-in** | **No** |

This is factually inaccurate. MSW v2 (released late 2023) introduced a ws namespace with a ws.link() API for intercepting WebSocket connections in-process, similar to how MSW intercepts HTTP requests via http.get()/http.post(). This is a stable, well-documented feature: https://mswjs.io/docs/api/ws/

Why the current text is inconsistent

The table already uses nuanced descriptions for other rows where MSW can accomplish the task but with caveats. For example:

• Cross-process interception → "No (in-process only)"
• OpenAI Chat Completions SSE → "Manual — build data: {json}\n\n + [DONE] yourself"
• Claude Messages API SSE → "Manual — build event:/data: SSE yourself"

These rows acknowledge MSW can do the underlying work (intercept HTTP, handle SSE) but with limitations or manual effort. The WebSocket row breaks this pattern by saying a flat "No" when MSW does have WebSocket interception — it just lacks the built-in LLM-specific protocol formatting that llmock provides.

Step-by-step proof

1. A developer reads the README comparison table and sees "No" for MSW WebSocket support.
2. They conclude MSW cannot intercept WebSocket connections at all.
3. In reality, MSW v2 provides ws.link("wss://example.com") which returns a handler that can intercept WebSocket connections, send/receive messages, and simulate server events — all in-process.
4. The developer makes a technology choice based on inaccurate information.

Origin and propagation

The index.html comparison table (line 1310-1312) already has this inaccuracy, but with a slightly more specific label: "WebSocket APIs (Realtime, Gemini Live)". That qualifier makes "No" marginally more defensible since MSW does not have built-in LLM protocol support. However, the README version just says "WebSocket APIs" generically, making the "No" clearly wrong — MSW absolutely supports WebSocket APIs.

This PR is propagating the error from index.html into README.md.

Suggested fix

Change the MSW column to something like:

• "Yes — in-process only" (consistent with the cross-process row)
• "Manual — generic WS interception only" (consistent with the SSE rows)
• "Manual — no built-in LLM protocol formatting"

Any of these would be accurate and consistent with the table's existing style.