feat(standard-server-peer): promote to stable#766
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis change removes the "experimental_" prefix from various class, interface, type, and function names related to RPC handlers and links across multiple packages, adapters, and documentation. All references, imports, and exports are updated to use the stable names, with no changes to logic, control flow, or implementation beyond renaming. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant RPCLink
participant Server
participant RPCHandler
Client->>RPCLink: Send RPC request
RPCLink->>Server: Transmit message (via port/ws)
Server->>RPCHandler: Forward request
RPCHandler-->>Server: Process and respond
Server-->>RPCLink: Return response
RPCLink-->>Client: Deliver result
Possibly related PRs
Suggested labels
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Summary of Changes
Hello @unnoq, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request marks a significant step in the project's maturity by promoting several key RPC handling and linking components from an experimental state to stable. The changes primarily involve removing the experimental_ prefix from various classes, interfaces, and functions, and updating all references in the codebase, including documentation and examples. This ensures a more stable and predictable API for developers.
Highlights
- API Stability: The
experimental_prefix has been removed from coreRPCHandlerandRPCLinkclasses, interfaces, and related utilities across@orpc/clientand@orpc/serveradapters (message-port, websocket, bun-ws, ws), signifying their promotion to stable APIs. - Codebase Modernization: Updated imports and class/interface names throughout the client and server adapter implementations to reflect the newly stable API, improving readability and consistency.
- Documentation & Examples: All relevant documentation files and playground examples have been updated to use the stable API names, ensuring users have up-to-date guidance.
- Partial Promotion for CrossWS: While the
standard-server-peerutilities used by thecrosswsadapter have been promoted, theexperimental_CrosswsHandlerclass itself retains itsexperimental_prefix, indicating that thecrosswsadapter might still be under active development or considered experimental.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
More templates
@orpc/arktype
@orpc/client
@orpc/contract
@orpc/experimental-durable-event-iterator
@orpc/hey-api
@orpc/json-schema
@orpc/nest
@orpc/openapi
@orpc/openapi-client
@orpc/react
@orpc/react-query
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-aws-lambda
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/standard-server-peer
@orpc/svelte-query
@orpc/tanstack-query
@orpc/trpc
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (3)
packages/client/src/adapters/message-port/rpc-link.test.ts (2)
30-33: Await the async expectation to ensure the test actually fails when the promise rejectsWithout awaiting or returning the promise produced by
expect(...).resolves, Jest/Vitest may finish the test before the assertion settles, leading to false-positives.- expect(orpc.ping('input')).resolves.toEqual('pong') + const promise = expect(orpc.ping('input')).resolves.toEqual('pong') ... + await promiseRepeat the same pattern wherever you use
resolves/rejectsbelow.
70-73:rejectsassertion is not awaited- expect(orpc.ping('input')).rejects.toThrow(/aborted/) + await expect(orpc.ping('input')).rejects.toThrow(/aborted/)packages/client/src/adapters/websocket/rpc-link.test.ts (1)
70-73: Await therejectsexpectation- expect(orpc.ping('input')).rejects.toThrow(/aborted/) + await expect(orpc.ping('input')).rejects.toThrow(/aborted/)
♻️ Duplicate comments (1)
packages/client/src/adapters/message-port/rpc-link.test.ts (1)
50-54: Same missing-await issue in “on success with blob”Apply the same fix here:
- expect(orpc.ping(new Blob(['input']))).resolves.toEqual('pong') + const promise = expect(orpc.ping(new Blob(['input']))).resolves.toEqual('pong') ... + await promise
🧹 Nitpick comments (15)
packages/client/src/adapters/message-port/rpc-link.test.ts (1)
12-19: Consider cleaning up message ports inafterEachFailing to close both ports can leak event listeners between tests:
afterEach(() => { clientPort.close() serverPort.close() })playgrounds/electron/src/renderer/src/lib/orpc.ts (1)
1-1: Suspicious relative path
'../../../main/router'is three levels up; verify this is intended for both build and runtime environments. Consider using a TS path alias for cross-package imports to avoid fragile deep relatives.packages/durable-event-iterator/src/durable-object/object.ts (1)
7-9: Left-overexperimental_prefix may confuse users.
experimental_HibernationPluginstill carries the prefix while adjacent code has been promoted to stable.
If the plugin itself is also considered stable now, rename it (and its import path) for consistency; otherwise add a comment clarifying why it remains experimental.packages/durable-event-iterator/src/client/plugin.ts (1)
4-11: Generic constraint could be widened
RPCLinkOptions<object>narrows the link to payloads assignable toobject. If users pass primitives (e.g.stringpayloads) this breaks. Consider:-import type { RPCLinkOptions } from '@orpc/client/websocket' -... -private readonly linkOptions: Omit<RPCLinkOptions<object>, 'websocket'> +import type { RPCLinkOptions } from '@orpc/client/websocket' +... +private readonly linkOptions: Omit<RPCLinkOptions<unknown>, 'websocket'>Using
unknownmaintains type-safety while staying payload-agnostic.Also applies to: 20-21, 42-43
apps/content/docs/adapters/websocket.md (1)
22-24: Docs update is correct; check remaining examples for consistencyGreat to see the stable
RPCHandlerbeing referenced here. Note, however, that the CrossWS example further down (line 43) still importsexperimental_RPCHandler. Updating that snippet as well will keep the docs consistent with the new API surface.packages/server/src/adapters/websocket/rpc-handler.ts (1)
5-6: Fine rename; consider temporary alias for smoother migrationThe switch to the stable
WebsocketHandlerimport compiles cleanly. If you expect downstream consumers to still referenceexperimental_WebsocketHandler, you may want to leave a deprecated re-export inhandler.tsfor one minor version to avoid a hard break.packages/server/src/adapters/ws/rpc-handler.ts (1)
5-6: Import rename acceptedMatches underlying handler implementation. Same deprecation-alias thought applies.
packages/server/src/adapters/bun-ws/rpc-handler.ts (1)
5-6: Import name aligned; watch for consumer breakageAs with the other adapters, consider a deprecated alias to reduce churn.
packages/server/src/adapters/bun-ws/handler.ts (1)
50-57: Auto-clean up peer on nativecloseevent
Bun.WebSocketemits its own"close"/"end"events. CurrentlyBunWsHandlerrelies on the caller to invokeclose(ws); if that is forgotten, theWeakMapentry survives until GC gets thewsitself. Hooking the websocket’s native close event guarantees tidy shutdown and avoids danglingServerPeers:@@ constructor( private readonly standardHandler: StandardHandler<T>, ) { + // Ensure peers are cleaned up even if the integrator forgets to call `close()` + // (Bun’s WebSocket inherits from EventTarget) + (ws: ServerWebSocket) => { + ws.addEventListener?.('close', () => this.close(ws), { once: true }) + } }packages/client/src/adapters/message-port/link-client.ts (1)
20-27: Detach listeners to prevent MessagePort leaks
onMessagePortMessage/onMessagePortCloseappear to register permanent listeners.
When this client is disposed the port may live on, keepingClientPeerin memory.
Store the unsubscribe handles and expose aclose()/dispose()method:constructor(options: LinkMessagePortClientOptions) { @@ - onMessagePortMessage(options.port, async (message) => { - await this.peer.message(message) - }) - - onMessagePortClose(options.port, () => { - this.peer.close() - }) + const offMsg = onMessagePortMessage(options.port, (m) => this.peer.message(m)) + const offClose = onMessagePortClose(options.port, () => this.peer.close()) + + // provide a way for callers to clean up proactively + this.dispose = () => { + offMsg() + offClose() + this.peer.close() + } } + + /** Call when the client should be torn down. */ + dispose(): void { /* overwritten in ctor */ }packages/client/src/adapters/websocket/link-client.ts (1)
31-41: Handle WebSocketerror/closeconsistently
closeis handled, but an'error'followed by abrupt socket termination would leaveClientPeeropen. Consider mirroring theclosecleanup for'error':options.websocket.addEventListener('close', () => { this.peer.close() +}) + +options.websocket.addEventListener('error', () => { + this.peer.close() })packages/server/src/adapters/ws/handler.ts (1)
26-33: Browser Blob conversion can allocate large buffersConverting an array of fragments to a single
Blob(new Blob(event.data)) copies the payload.
For large messages this doubles memory. If the target runtimes include Node’sws, you can avoid the copy by concatenatingBuffers or forwarding each fragment in order.
Not urgent, but worth profiling.packages/server/src/adapters/websocket/handler.ts (3)
9-13: Consider including theclose()method inMinimalWebsocket
upgrade()subscribes to the'close'event butclose()isn’t required on the type.
If external callers ever need to invokews.close()directly, adding it now avoids future widening casts.
45-48: Broaden accepted binary payload types for Node compatibility
wsimplementations in Node emitBufferobjects (anArrayBufferView).
Extending the union prevents an unnecessaryascast for consumers.- data: string | ArrayBuffer | Blob, + data: string | ArrayBuffer | ArrayBufferView | Blob,
72-78: Delete peer entry after closing to speed up GCAlthough
WeakMapholds keys weakly, removing the entry proactively avoids dangling listeners and eases reasoning.if (peer) { peer.close() + this.#peers.delete(ws) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (35)
apps/content/docs/adapters/browser.md(6 hunks)apps/content/docs/adapters/electron.md(1 hunks)apps/content/docs/adapters/message-port.md(2 hunks)apps/content/docs/adapters/websocket.md(5 hunks)apps/content/docs/adapters/worker-threads.md(2 hunks)apps/content/docs/plugins/hibernation.md(2 hunks)packages/arktype/README.md(1 hunks)packages/client/src/adapters/message-port/link-client.ts(1 hunks)packages/client/src/adapters/message-port/rpc-link.test.ts(1 hunks)packages/client/src/adapters/message-port/rpc-link.ts(1 hunks)packages/client/src/adapters/websocket/link-client.ts(1 hunks)packages/client/src/adapters/websocket/rpc-link.test.ts(1 hunks)packages/client/src/adapters/websocket/rpc-link.ts(2 hunks)packages/durable-event-iterator/src/client/plugin.ts(1 hunks)packages/durable-event-iterator/src/durable-object/object.ts(1 hunks)packages/server/src/adapters/bun-ws/handler.ts(1 hunks)packages/server/src/adapters/bun-ws/rpc-handler.test.ts(1 hunks)packages/server/src/adapters/bun-ws/rpc-handler.ts(1 hunks)packages/server/src/adapters/crossws/handler.ts(1 hunks)packages/server/src/adapters/message-port/handler.ts(1 hunks)packages/server/src/adapters/message-port/rpc-handler.test.ts(1 hunks)packages/server/src/adapters/message-port/rpc-handler.ts(1 hunks)packages/server/src/adapters/standard-peer/utils.test.ts(1 hunks)packages/server/src/adapters/standard-peer/utils.ts(1 hunks)packages/server/src/adapters/websocket/handler.ts(4 hunks)packages/server/src/adapters/websocket/rpc-handler.test.ts(1 hunks)packages/server/src/adapters/websocket/rpc-handler.ts(1 hunks)packages/server/src/adapters/ws/handler.ts(1 hunks)packages/server/src/adapters/ws/rpc-handler.test.ts(1 hunks)packages/server/src/adapters/ws/rpc-handler.ts(1 hunks)packages/server/tests/message-port.test.ts(1 hunks)playgrounds/browser-extension/entrypoints/background/index.ts(1 hunks)playgrounds/browser-extension/entrypoints/popup/lib/orpc.ts(1 hunks)playgrounds/electron/src/main/index.ts(1 hunks)playgrounds/electron/src/renderer/src/lib/orpc.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (9)
packages/server/src/adapters/message-port/handler.ts (1)
packages/server/src/context.ts (1)
Context(1-1)
packages/server/src/adapters/ws/rpc-handler.ts (2)
packages/server/src/context.ts (1)
Context(1-1)packages/server/src/adapters/ws/handler.ts (1)
WsHandler(14-43)
packages/server/src/adapters/bun-ws/rpc-handler.ts (2)
packages/server/src/context.ts (1)
Context(1-1)packages/server/src/adapters/bun-ws/handler.ts (1)
BunWsHandler(17-58)
packages/client/src/adapters/message-port/link-client.ts (3)
packages/client/src/adapters/message-port/message-port.ts (1)
SupportedMessagePort(22-22)packages/client/src/adapters/standard/types.ts (1)
StandardLinkClient(9-11)packages/standard-server-peer/src/client.ts (1)
ClientPeer(19-157)
packages/client/src/adapters/websocket/link-client.ts (2)
packages/client/src/adapters/standard/types.ts (1)
StandardLinkClient(9-11)packages/standard-server-peer/src/client.ts (1)
ClientPeer(19-157)
packages/server/src/adapters/websocket/rpc-handler.ts (2)
packages/server/src/context.ts (1)
Context(1-1)packages/server/src/adapters/websocket/handler.ts (1)
WebsocketHandler(11-79)
packages/client/src/adapters/websocket/rpc-link.ts (2)
packages/client/src/adapters/message-port/rpc-link.ts (2)
RPCLinkOptions(7-8)RPCLink(16-21)packages/client/src/adapters/standard/rpc-link.ts (1)
StandardRPCLink(14-22)
packages/server/src/adapters/websocket/handler.ts (2)
packages/server/src/context.ts (1)
Context(1-1)packages/standard-server-peer/src/server.ts (1)
ServerPeer(19-135)
packages/server/src/adapters/ws/handler.ts (1)
packages/server/src/context.ts (1)
Context(1-1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: lint
- GitHub Check: publish-commit
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (33)
packages/client/src/adapters/message-port/rpc-link.test.ts (1)
4-4: Import rename looks correct – matches the newly-stabilised class name.packages/client/src/adapters/websocket/rpc-link.test.ts (1)
3-3: Import rename acknowledged – no issues spotted.playgrounds/browser-extension/entrypoints/popup/lib/orpc.ts (1)
4-4: Import update looks good.packages/server/src/adapters/message-port/rpc-handler.test.ts (1)
3-3: Import rename OK – aligns with the stable API.playgrounds/electron/src/renderer/src/lib/orpc.ts (1)
4-4: Import update looks correct.packages/server/src/adapters/bun-ws/rpc-handler.test.ts (1)
3-3: Rename lingeringexperimental_RPCHandlerreferencesThe
experimental_RPCHandleridentifier is still present in tests, docs, and the handler implementation. Update these to useRPCHandlerdirectly to avoid build breakages:• packages/server/src/adapters/crossws/rpc-handler.test.ts
- import { experimental_RPCHandler as RPCHandler } from './rpc-handler' + import { RPCHandler } from './rpc-handler'• apps/content/docs/adapters/websocket.md
- import { experimental_RPCHandler as RPCHandler } from '@orpc/server/crossws' + import { RPCHandler } from '@orpc/server/crossws'• packages/server/src/adapters/crossws/rpc-handler.ts
- export class experimental_RPCHandler<T extends Context> extends CrosswsHandler<T> { + export class RPCHandler<T extends Context> extends CrosswsHandler<T> {Likely an incorrect or invalid review comment.
packages/server/src/adapters/ws/rpc-handler.test.ts (1)
3-3: Import rename acknowledged – LGTM.No functional impact; test continues to compile against the stabilised
RPCHandler.packages/server/src/adapters/websocket/rpc-handler.test.ts (1)
3-3: Stable name adoption confirmed.Good to see the WebSocket adapter tests moved over as well.
playgrounds/electron/src/main/index.ts (1)
4-5: Electron entry-point updated – looks correct.The import path now matches the stable package export. No additional action required.
packages/server/src/adapters/standard-peer/utils.test.ts (1)
3-4: Import rename looks good; double-check re-export pathThe test now imports
handleStandardServerPeerMessagedirectly. Make surepackages/server/src/adapters/standard-peer/utils.tsactually re-exports the stable symbol under that exact name (no alias left hanging around) so TS consumers don’t fall back to anany.packages/server/tests/message-port.test.ts (1)
3-7: Renamed symbols compile but watch for transitive re-exports
RPCLinkandRPCHandlerare referenced from their new stable locations. Verify that every barrel file inside@orpc/client/message-portand@orpc/server/message-portforwards the same identifiers to avoid breaking downstreampaths/exportsmaps.apps/content/docs/adapters/worker-threads.md (1)
16-17: Docs update LGTMExamples reflect the stable API. No further action.
Also applies to: 35-36
apps/content/docs/adapters/message-port.md (1)
27-29: Docs import rename confirmedThe snippet now matches the public API; nothing else needed.
Also applies to: 39-41
packages/server/src/adapters/crossws/handler.ts (1)
5-5: LGTM! Clean stabilization of API imports.The removal of the
experimental_prefix from both the type and function imports aligns perfectly with the PR objective to promote standard-server-peer to stable. The changes are consistent and maintain the same functionality.Also applies to: 8-8
playgrounds/browser-extension/entrypoints/background/index.ts (1)
1-1: LGTM! API stabilization complete.The removal of the
experimental_prefix fromRPCHandlerimport correctly reflects the promotion to stable API. The usage remains identical, ensuring seamless transition.apps/content/docs/plugins/hibernation.md (1)
71-71: LGTM! Documentation updated for stable API.The documentation examples have been correctly updated to reflect the stable API by removing the
experimental_prefix from bothRPCHandlerandRPCLinkimports. This ensures users are guided to use the stable APIs.Also applies to: 149-149
apps/content/docs/adapters/electron.md (1)
15-15: LGTM! Documentation reflects stable API.The documentation example has been correctly updated to use the stable
RPCHandlerimport, removing theexperimental_prefix. This guides users to the stable API for Electron integration.apps/content/docs/adapters/browser.md (1)
21-21: LGTM! Comprehensive documentation update for stable API.All browser adapter examples have been consistently updated to use the stable API by removing the
experimental_prefix from bothRPCHandlerandRPCLinkimports. This provides users with accurate guidance for using the stable APIs across different browser integration scenarios.Also applies to: 33-33, 55-55, 73-73, 125-125, 137-137
apps/content/docs/adapters/websocket.md (4)
74-78: LGTM – import now matches the codebase
88-92: LGTM –@orpc/server/bun-wsimport is in sync with implementation.
114-118: LGTM – Consistent update for the hibernation example.
156-160: LGTM – Client-side example now points to the stableRPCLink.packages/server/src/adapters/websocket/rpc-handler.ts (1)
13-16: LGTM – no behavioral changepackages/server/src/adapters/ws/rpc-handler.ts (1)
13-16: LGTM – Pure rename, logic untouched.packages/server/src/adapters/bun-ws/rpc-handler.ts (1)
13-16: LGTM – No functional modifications detected.packages/server/src/adapters/message-port/handler.ts (3)
6-7: Typename update looks correctThe type alias matches the updated export in
standard-peer; no type errors expected.
12-13: Import rename OK
handleStandardServerPeerMessageis used consistently below.
15-16: LGTM – Class rename only; implementation unchanged.packages/server/src/adapters/message-port/rpc-handler.ts (1)
5-15: Stable rename looks goodImport path and class rename are consistent with the promotion-to-stable objective. No functional change introduced – compilation should remain green.
packages/server/src/adapters/standard-peer/utils.ts (2)
6-8: Renaming looks goodType alias renamed cleanly; downstream consumers remain unaffected.
9-14: Function promotion LGTMSignature & internal usage updated consistently; no behavioural change introduced.
packages/client/src/adapters/websocket/rpc-link.ts (1)
16-21: No issues – rename propagated correctlyConstructor wiring & option shaping remain intact; good job on the clean promotion.
packages/client/src/adapters/message-port/rpc-link.ts (1)
16-20: Looks solidMessage-port link mirrors the WebSocket variant faithfully; no functional concerns.
Summary by CodeRabbit