feat(client, server)!: Adapter-Level Plugin Interception#292
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Caution Review failedThe pull request is closed. WalkthroughThis pull request applies widespread refactoring and type updates across multiple packages. Documentation for handlers has been updated for clarity, and tests have been streamlined. In the client and server packages, numerous method signatures and type imports have been revised—primarily replacing instances of ClientOptionsOut with ClientOptions (and renaming to FriendlyClientOptions where applicable)—while plugin architectures and handler inheritance structures have been modernized. Several obsolete files and exports have been removed, and dependency versions have been updated in select package.json files. Changes
Sequence Diagram(s)sequenceDiagram
participant C as Client
participant R as resolveFriendlyClientOptions
participant SL as StandardLink
participant PL as Plugin (if any)
participant RPC as RPCHandler
C->>R: Call procedureClient with input & options
R-->>C: Return resolved FriendlyClientOptions
C->>SL: Invoke StandardLink.call(options)
SL->>PL: Iterate & initialize each plugin (if defined)
SL->>RPC: Delegate call or process request via interceptors
RPC-->>SL: Return response (e.g., "pong")
SL-->>C: Return final response
sequenceDiagram
participant Req as IncomingRequest
participant NH as NodeHttpHandler / FetchHandler
participant SH as StandardHandler
participant Resp as HTTP Response
Req->>NH: Send HTTP request
NH->>SH: Delegate request conversion & handling
SH->>NH: Return standardized result
NH->>Resp: Send response with status 200 and content ("pong")
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (3)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
More templates
@orpc/arktype
@orpc/client
@orpc/contract
@orpc/openapi
@orpc/openapi-client
@orpc/react-query
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-fetch
@orpc/svelte-query
@orpc/standard-server-node
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (7)
packages/shared/src/args.test.ts (1)
3-6: Consider adding an empty array test caseThe tests cover the main scenarios but miss testing with an empty array input. Since the function would return an empty object for both
[undefined]and[], adding a test case forresolveMaybeOptionalOptions([])would ensure complete coverage.it('resolveMaybeOptionalOptions', () => { expect(resolveMaybeOptionalOptions([{ a: 1 }])).toEqual({ a: 1 }) expect(resolveMaybeOptionalOptions([undefined])).toEqual({}) + expect(resolveMaybeOptionalOptions([])).toEqual({}) })packages/shared/src/args.ts (1)
5-7: Clean implementation for resolving optional parameters.The
resolveMaybeOptionalOptionsfunction provides a convenient way to extract options from the tuple type, handling the case where options might be undefined. The fallback to an empty object ensures that consuming code doesn't have to deal with undefined values.I do have one minor concern:
Consider adding a more specific type annotation to the empty object fallback:
- return rest[0] ?? {} as T // 0 only undefined when all fields are optional + return rest[0] ?? ({} as T) // 0 only undefined when all fields are optionalThis makes the cast more explicit and helps emphasize that the empty object is being cast to type T.
packages/server/src/adapters/node/rpc-handler.test.ts (1)
6-16: Test simplification improves clarity.The test has been streamlined to focus on core functionality, making it more maintainable. This aligns well with the PR's objective of enhancing clarity and consistency.
Consider adding additional test cases for error conditions to ensure robust handling of edge cases.
packages/openapi/src/adapters/fetch/openapi-handler.test.ts (1)
5-14: Test simplified for better focus on core functionality.The test effectively verifies the basic functionality of the OpenAPIHandler. Consider expanding test coverage to include:
- Different HTTP methods (POST, PUT, DELETE)
- Error scenarios (invalid routes, malformed requests)
- Different response types (JSON, text, binary)
This would ensure more robust testing of the handler's capabilities.
packages/client/src/adapters/standard/rpc-link-codec.ts (1)
78-78: Consider using the generic class-level type parameterUsing
ClientOptions<any>here may reduce type safety. It might be more appropriate to align with the class’s type parameter:- async encode(path: readonly string[], input: unknown, options: ClientOptions<any>): Promise<StandardRequest> { + async encode(path: readonly string[], input: unknown, options: ClientOptions<T>): Promise<StandardRequest> {packages/server/src/adapters/standard/handler.ts (1)
62-64: Initializing plugins withinit().Immediate plugin initialization ensures all plugins have an opportunity to configure themselves before request handling begins. Consider adding error handling to safeguard potential plugin failures.
packages/client/src/adapters/standard/types.ts (1)
5-6: Codec method signatures
Changingencodeanddecodeto referenceClientOptions<any>andClientOptions<T>is part of the global refactor. However, the cast toanyfor the first method could undermine some type safety. Consider usingClientOptions<T>consistently, unless there are real scenarios requiring flexible context typing.- encode(path: readonly string[], input: unknown, options: ClientOptions<any>): Promise<StandardRequest> + encode(path: readonly string[], input: unknown, options: ClientOptions<T>): Promise<StandardRequest>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (60)
apps/content/docs/openapi/openapi-handler.md(1 hunks)apps/content/docs/rpc-handler.md(2 hunks)packages/client/src/adapters/fetch/link-fetch-client.ts(2 hunks)packages/client/src/adapters/fetch/rpc-link.ts(2 hunks)packages/client/src/adapters/fetch/types.ts(1 hunks)packages/client/src/adapters/standard/link.test.ts(1 hunks)packages/client/src/adapters/standard/link.ts(2 hunks)packages/client/src/adapters/standard/rpc-link-codec.ts(6 hunks)packages/client/src/adapters/standard/types.ts(1 hunks)packages/client/src/client.ts(2 hunks)packages/client/src/dynamic-link.test.ts(2 hunks)packages/client/src/dynamic-link.ts(2 hunks)packages/client/src/plugins/base.test.ts(0 hunks)packages/client/src/plugins/base.ts(0 hunks)packages/client/src/plugins/index.ts(0 hunks)packages/client/src/plugins/retry.ts(5 hunks)packages/client/src/types.ts(2 hunks)packages/client/src/utils.test.ts(2 hunks)packages/client/src/utils.ts(2 hunks)packages/openapi/package.json(0 hunks)packages/openapi/src/adapters/fetch/openapi-handler.test.ts(1 hunks)packages/openapi/src/adapters/fetch/openapi-handler.ts(1 hunks)packages/openapi/src/adapters/node/openapi-handler.test.ts(1 hunks)packages/openapi/src/adapters/node/openapi-handler.ts(1 hunks)packages/server/package.json(1 hunks)packages/server/src/adapters/fetch/handler.test-d.ts(1 hunks)packages/server/src/adapters/fetch/handler.test.ts(1 hunks)packages/server/src/adapters/fetch/handler.ts(1 hunks)packages/server/src/adapters/fetch/index.ts(1 hunks)packages/server/src/adapters/fetch/rpc-handler.test.ts(1 hunks)packages/server/src/adapters/fetch/rpc-handler.ts(1 hunks)packages/server/src/adapters/fetch/types.ts(0 hunks)packages/server/src/adapters/node/handler.test-d.ts(1 hunks)packages/server/src/adapters/node/handler.test.ts(1 hunks)packages/server/src/adapters/node/handler.ts(1 hunks)packages/server/src/adapters/node/index.ts(1 hunks)packages/server/src/adapters/node/rpc-handler.test.ts(1 hunks)packages/server/src/adapters/node/rpc-handler.ts(1 hunks)packages/server/src/adapters/node/types.ts(0 hunks)packages/server/src/adapters/standard/handler.test-d.ts(0 hunks)packages/server/src/adapters/standard/handler.test.ts(4 hunks)packages/server/src/adapters/standard/handler.ts(3 hunks)packages/server/src/adapters/standard/utils.test-d.ts(1 hunks)packages/server/src/adapters/standard/utils.test.ts(1 hunks)packages/server/src/adapters/standard/utils.ts(1 hunks)packages/server/src/plugins/base.test.ts(0 hunks)packages/server/src/plugins/base.ts(0 hunks)packages/server/src/plugins/cors.ts(2 hunks)packages/server/src/plugins/index.ts(0 hunks)packages/server/src/plugins/response-headers.ts(1 hunks)packages/shared/src/args.test-d.ts(1 hunks)packages/shared/src/args.test.ts(1 hunks)packages/shared/src/args.ts(1 hunks)packages/shared/src/array.test.ts(1 hunks)packages/shared/src/array.ts(1 hunks)packages/shared/src/index.ts(1 hunks)packages/shared/src/types.test-d.ts(1 hunks)packages/shared/src/types.ts(0 hunks)packages/zod/src/coercer.ts(2 hunks)playgrounds/svelte-kit/package.json(1 hunks)
💤 Files with no reviewable changes (11)
- packages/server/src/plugins/index.ts
- packages/openapi/package.json
- packages/server/src/plugins/base.ts
- packages/client/src/plugins/index.ts
- packages/client/src/plugins/base.test.ts
- packages/shared/src/types.ts
- packages/server/src/plugins/base.test.ts
- packages/server/src/adapters/standard/handler.test-d.ts
- packages/client/src/plugins/base.ts
- packages/server/src/adapters/fetch/types.ts
- packages/server/src/adapters/node/types.ts
🧰 Additional context used
🧬 Code Definitions (25)
packages/client/src/client.ts (2)
packages/client/src/types.ts (3)
Client(15-17)InferClientContext(23-23)FriendlyClientOptions(3-5)packages/client/src/utils.ts (1)
resolveFriendlyClientOptions(38-43)
packages/server/src/adapters/node/handler.test-d.ts (2)
packages/server/src/adapters/node/handler.ts (1)
NodeHttpHandlerPlugin(10-12)packages/server/src/adapters/standard/handler.ts (1)
StandardHandlerPlugin(19-21)
packages/client/src/utils.test.ts (1)
packages/client/src/utils.ts (1)
resolveFriendlyClientOptions(38-43)
packages/server/src/adapters/standard/handler.test.ts (2)
packages/server/src/plugins/cors.ts (1)
init(31-113)packages/server/src/adapters/standard/handler.ts (1)
StandardHandler(51-138)
packages/server/src/adapters/fetch/handler.test-d.ts (2)
packages/server/src/adapters/fetch/handler.ts (1)
FetchHandlerPlugin(10-12)packages/server/src/adapters/standard/handler.ts (1)
StandardHandlerPlugin(19-21)
packages/shared/src/array.test.ts (1)
packages/shared/src/array.ts (1)
toArray(1-3)
packages/shared/src/args.test.ts (1)
packages/shared/src/args.ts (1)
resolveMaybeOptionalOptions(5-7)
packages/server/src/adapters/standard/utils.test.ts (1)
packages/server/src/adapters/standard/utils.ts (1)
resolveFriendlyStandardHandleOptions(8-13)
packages/client/src/dynamic-link.test.ts (1)
packages/client/src/types.ts (1)
ClientOptions(25-27)
packages/server/src/adapters/standard/utils.ts (1)
packages/server/src/adapters/standard/handler.ts (1)
StandardHandleOptions(12-15)
packages/zod/src/coercer.ts (1)
packages/server/src/adapters/standard/handler.ts (1)
StandardHandlerPlugin(19-21)
packages/client/src/utils.ts (1)
packages/client/src/types.ts (3)
ClientContext(1-1)FriendlyClientOptions(3-5)ClientOptions(25-27)
packages/shared/src/args.test-d.ts (1)
packages/shared/src/args.ts (1)
MaybeOptionalOptions(1-3)
packages/client/src/adapters/fetch/rpc-link.ts (2)
packages/client/src/adapters/standard/link.ts (1)
path(44-56)packages/client/src/types.ts (1)
ClientOptions(25-27)
packages/server/src/plugins/cors.ts (1)
packages/server/src/adapters/standard/handler.ts (1)
StandardHandlerPlugin(19-21)
packages/openapi/src/adapters/node/openapi-handler.ts (5)
packages/server/src/adapters/node/handler.ts (2)
NodeHttpHandler(24-68)NodeHttpHandlerOptions(14-22)packages/openapi/src/adapters/standard/openapi-handler.ts (1)
StandardOpenAPIHandlerOptions(5-5)packages/openapi/src/adapters/standard/openapi-matcher.ts (1)
StandardOpenAPIMatcher(8-94)packages/openapi/src/adapters/standard/openapi-codec.ts (1)
StandardOpenAPICodec(9-88)packages/server/src/adapters/standard/handler.ts (1)
StandardHandler(51-138)
packages/server/src/adapters/node/rpc-handler.ts (3)
packages/server/src/adapters/node/handler.ts (2)
NodeHttpHandler(24-68)NodeHttpHandlerOptions(14-22)packages/server/src/adapters/standard/rpc-handler.ts (1)
StandardRPCHandlerOptions(5-5)packages/server/src/adapters/standard/handler.ts (1)
StandardHandler(51-138)
packages/server/src/adapters/node/handler.ts (1)
packages/server/src/adapters/standard/handler.ts (3)
StandardHandlerPlugin(19-21)StandardHandleOptions(12-15)StandardHandler(51-138)
packages/server/src/adapters/fetch/handler.ts (4)
packages/server/src/adapters/standard/handler.ts (3)
StandardHandlerPlugin(19-21)StandardHandleOptions(12-15)StandardHandler(51-138)packages/shared/src/array.ts (1)
toArray(1-3)packages/shared/src/args.ts (2)
MaybeOptionalOptions(1-3)resolveMaybeOptionalOptions(5-7)packages/server/src/adapters/standard/utils.ts (2)
FriendlyStandardHandleOptions(4-6)resolveFriendlyStandardHandleOptions(8-13)
packages/server/src/plugins/response-headers.ts (1)
packages/server/src/adapters/standard/handler.ts (1)
StandardHandlerPlugin(19-21)
packages/client/src/adapters/standard/link.ts (2)
packages/client/src/types.ts (2)
ClientContext(1-1)ClientOptions(25-27)packages/standard-server/src/types.ts (2)
StandardRequest(13-24)StandardLazyResponse(48-59)
packages/openapi/src/adapters/fetch/openapi-handler.ts (3)
packages/server/src/adapters/fetch/handler.ts (2)
FetchHandler(25-68)FetchHandlerOptions(19-23)packages/openapi/src/adapters/standard/openapi-handler.ts (1)
StandardOpenAPIHandlerOptions(5-5)packages/server/src/adapters/standard/handler.ts (1)
StandardHandler(51-138)
packages/client/src/adapters/standard/rpc-link-codec.ts (3)
packages/client/src/types.ts (1)
ClientOptions(25-27)packages/client/src/adapters/standard/link.ts (1)
path(44-56)packages/standard-server/src/types.ts (1)
StandardRequest(13-24)
packages/client/src/adapters/standard/types.ts (3)
packages/client/src/types.ts (2)
ClientContext(1-1)ClientOptions(25-27)packages/client/src/adapters/standard/link.ts (1)
path(44-56)packages/standard-server/src/types.ts (2)
StandardRequest(13-24)StandardLazyResponse(48-59)
packages/client/src/plugins/retry.ts (2)
packages/client/src/types.ts (1)
ClientOptions(25-27)packages/client/src/adapters/standard/link.ts (1)
StandardLinkPlugin(9-11)
🔇 Additional comments (131)
packages/zod/src/coercer.ts (3)
2-2: Interface import update for consistency.The import has been updated to use
StandardHandlerPluginfrom '@orpc/server/standard' instead of the previousHandlerPlugin. This aligns with the PR objective of renaming internal APIs for clarity and consistency.
31-31: Interface implementation change aligns with renamed type.The
ZodSmartCoercionPluginclass has been updated to implementStandardHandlerPlugin<TContext>instead ofHandlerPlugin<TContext>, following the renaming pattern mentioned in the PR objectives. The implementation remains functionally identical, only the interface name has changed.
32-47: Plugin initialization looks good.The
initmethod maintains the same implementation as before, usingStandardHandlerOptions<TContext>. The plugin correctly sets up client interceptors to perform smart coercion of input data based on Zod schemas, which aligns with the adapter-level plugin interception feature mentioned in the PR objectives.packages/shared/src/array.test.ts (1)
3-8: Well-structured test coverageThe test suite for the
toArrayfunction is comprehensive, covering all possible input scenarios:undefined,null, single value, and array. Each test case correctly verifies the expected behavior defined in the implementation.packages/shared/src/array.ts (1)
1-3: Concise and well-implemented utility functionThe
toArrayfunction is elegantly implemented using ternary operators to handle all possible input cases: arrays, single values, undefined, and null. The TypeScript generic ensures type safety is maintained throughout the conversion process.packages/shared/src/index.ts (1)
1-2: Exports correctly added in alphabetical orderThe new exports for the
argsandarraymodules are appropriately added to the index file in alphabetical order, following the existing pattern of re-exporting all functionality from individual modules.packages/shared/src/args.test-d.ts (1)
1-22: Well-structured type tests for the MaybeOptionalOptions utility type.This test file provides thorough validation for the
MaybeOptionalOptionstype. You've correctly tested both required and optional property scenarios:
- Test case with required property correctly enforces the presence of the property
- Test case with optional property correctly handles undefined values
- Type errors are properly tested with
@ts-expect-errorannotationsThe test coverage effectively ensures that
MaybeOptionalOptionsfunctions as intended in both scenarios.packages/shared/src/args.ts (1)
1-3: Excellent utility type for handling optional parameters based on type emptiness.The
MaybeOptionalOptionstype cleverly uses conditional types to determine whether options should be required or optional based on the structure of the options type. This provides a flexible and type-safe way to handle options in functions.packages/shared/src/types.test-d.ts (1)
1-1: Import statement updated to reflect test focus changes.The import statement has been updated to only import the types being tested (
SetOptionalandIntersectPick). This aligns with the removal of theMaybeOptionalOptionstest case which has been moved to its own dedicated test file.packages/server/src/adapters/fetch/index.ts (1)
1-1: LGTM - Handler module export addedThis addition aligns well with the PR objectives, exporting the
FetchHandlerclass that now serves as the base for theRPCHandler. This change supports the adapter-level plugin interception feature by exposing the necessary handler class.packages/server/package.json (1)
85-85:Details
❓ Verification inconclusive
Dependency switch from light-my-request to supertest
The replacement of
light-my-requestwithsupertestfor HTTP request testing indicates a transition to a more comprehensive testing framework. This change aligns with the PR's broader restructuring to enhance the testing approach.
🏁 Script executed:
#!/bin/bash # Verify that tests have been updated to use supertest instead of light-my-request echo "Checking for any remaining light-my-request usage in test files:" rg "light-my-request" --type ts "packages/server/src/**/*.test.ts"Length of output: 278
Test Suite Verification: Confirm Removal of light-my-request
The switch from light-my-request to supertest in the dependency and tests appears conceptually sound. However, the automated search using the file pattern
packages/server/src/**/*.test.tsdid not locate any test files (resulting in a "No such file or directory" error). This suggests that either the tests reside in a different location or the pattern needs adjustment.
- Please verify that all test files have been updated to use supertest.
- Manually check the test suite directories (or run a broader search such as
rg "light-my-request" packages/server) to confirm there are no lingering references to light-my-request.packages/server/src/adapters/node/index.ts (1)
1-1: LGTM - Handler module export addedThis addition aligns with the PR objectives, exporting the
NodeHttpHandlerclass that now serves as the base for both theRPCHandlerandOpenAPIHandler. This change supports the adapter-level plugin interception feature by exposing the necessary handler infrastructure.packages/client/src/dynamic-link.test.ts (1)
1-1: Type name update consistent with renaming changesThe rename from
ClientOptionsOuttoClientOptionsis aligned with the PR objectives, which explicitly mention this renaming for clarity and consistency. This change correctly updates both the import and the type annotation in the test file.Also applies to: 11-11
playgrounds/svelte-kit/package.json (2)
26-26: Note: TypeScript version pinned to exact version 5.7.3The change from
^5.0.0to5.7.3removes the caret prefix, which means the project now requires exactly TypeScript 5.7.3 rather than allowing compatible updates. This suggests the codebase may use specific features from this version or might have compatibility issues with other versions.Make sure to test the code changes with exactly TypeScript 5.7.3 to verify compatibility, and ensure your development environment uses this specific version.
22-22: Version update for Svelte plugin looks goodMinor version update from 5.0.0 to 5.0.3, maintaining compatibility with the caret prefix.
packages/server/src/adapters/standard/utils.test.ts (1)
1-7: Test coverage for resolveFriendlyStandardHandleOptions is comprehensiveThe test cases effectively verify all the expected behaviors of the utility function:
- Empty input returns an object with empty context
- Input with context preserves that context in the output
- Additional properties (like prefix) are maintained alongside the context
This aligns well with the function's implementation in utils.ts, which ensures context is always present by defaulting to an empty object when not provided.
packages/server/src/adapters/node/handler.test-d.ts (2)
2-3: Import statements updated for type compatibility testingAppropriate imports added for the type compatibility tests between NodeHttpHandlerPlugin and StandardHandlerPlugin.
5-10: Type compatibility tests ensure backward compatibilityThese tests verify that NodeHttpHandlerPlugin and StandardHandlerPlugin types are compatible in both directions, which is critical for maintaining backward compatibility during the renaming refactoring. This ensures existing code will continue to work with the renamed types.
packages/client/src/utils.test.ts (2)
2-2: Updated import to include the new utility functionImport statement correctly updated to include the new
resolveFriendlyClientOptionsfunction alongside the existingsafefunction.
25-29: Comprehensive test cases for resolveFriendlyClientOptionsThe test cases effectively validate that the function:
- Adds an empty context object when none is provided
- Preserves existing context objects
- Maintains other properties like lastEventId while ensuring context exists
This follows the same pattern as the server-side
resolveFriendlyStandardHandleOptionsfunction, creating consistency across client and server libraries. This supports the PR's goal of improving API clarity and consistency through renaming.packages/server/src/adapters/standard/utils.test-d.ts (1)
1-11: Well-written type tests for FriendlyStandardHandleOptionsThis new test file validates the behavior of the
FriendlyStandardHandleOptionstype with different input scenarios. The tests comprehensively check required vs optional context properties, and ensure type safety is maintained.packages/client/src/adapters/fetch/types.ts (2)
1-1: Updated import to use the renamed ClientOptions typeThe import statement has been modified to reflect the type renaming from
ClientOptionsOuttoClientOptionsas mentioned in the PR objectives.
7-7: Updated parameter type to use ClientOptionsThe type of the
optionsparameter in theFetchWithContextinterface has been updated fromClientOptionsOut<TClientContext>toClientOptions<TClientContext>, aligning with the renamed type.apps/content/docs/openapi/openapi-handler.md (2)
102-102: Clarified terminology: "ping comments" instead of "ping messages"The description now accurately describes that the keep-alive mechanism sends "ping comments" rather than "ping messages", which better reflects the actual implementation.
105-105: Moved handler instantiation code to maintain consistencyThe instantiation of
OpenAPIHandlerhas been moved to a different line for formatting consistency, while preserving the functionality. This aligns with the PR objective of relocating Event Iterator Keep Alive configurations to the handler options.packages/client/src/adapters/standard/link.test.ts (1)
56-70: Added test case for plugin initializationThis new test case verifies that plugin initialization functions are correctly called when plugins are provided to the
StandardLinkconstructor. The test ensures that each plugin'sinitmethod is called exactly once with the correct options object.This test is essential for validating the adapter-level plugin interception functionality mentioned in the PR objectives.
apps/content/docs/rpc-handler.md (2)
75-75: Header formatting update looks goodThe removal of the hyphen in "Event Iterator Keep Alive" improves consistency with other mentions of this feature throughout the documentation.
84-88: LGTM: Configuration location update properly documentedThe example correctly shows that Event Iterator Keep Alive settings are now configured during handler creation rather than in the handle method, aligning with the PR's architectural changes.
packages/server/src/adapters/fetch/handler.test-d.ts (2)
1-2: LGTM: Import statements correctly addedThe imports for StandardHandlerPlugin and FetchHandlerPlugin enable proper type checking in the tests.
4-9: Good type compatibility testingThis test correctly verifies bidirectional type compatibility between FetchHandlerPlugin and StandardHandlerPlugin, ensuring backward compatibility after the rename from HandlerPlugin to StandardHandlerPlugin.
packages/client/src/client.ts (2)
1-2: LGTM: Updated imports for new type namesThe import changes correctly reflect the renaming of ClientOptions to FriendlyClientOptions and addition of the utility function.
17-21: Good implementation of type changes with default valueThe function signature update provides a default empty object for options, simplifying the code and properly using the new FriendlyClientOptions type. Using the resolveFriendlyClientOptions utility function ensures consistent context initialization, which is a good refactoring.
packages/openapi/src/adapters/node/openapi-handler.test.ts (2)
1-3: LGTM: Updated imports for simplified testThe imports have been appropriately updated to match the simplified testing approach that focuses on the essential functionality rather than implementation details.
6-16: Good test simplificationThe test has been effectively simplified to focus on core functionality, which aligns with the architectural changes where OpenAPIHandler now extends NodeHttpHandler. This approach tests the public API behavior rather than implementation details, which is a good practice.
packages/server/src/adapters/standard/handler.test.ts (4)
126-126: Ensures interceptors property is initialized in client options.The addition of an empty interceptors array in the
createProcedureClientcall ensures that the client options object always has this property defined, aligning with changes in the adapter-level plugin interception feature.
186-186: Properly initializes interceptors property in error test case.Consistent with the changes made in the success case, this ensures the client options for the error test scenario includes the interceptors array property, maintaining uniformity across test cases.
247-247: Adds interceptors property to decode error test case.This change ensures consistency with the other test cases by adding the interceptors array to the client options, completing the implementation of the adapter-level plugin interception feature throughout all test scenarios.
326-342: Good addition of plugin initialization test.This new test case verifies that a plugin's
initmethod is called with the correct options when a newStandardHandleris instantiated. This effectively tests the new plugin interception capability at the adapter level.The test properly validates:
- That
initis called exactly once- That the options passed to
initmatch the original options objectThis validates the critical functionality introduced in this PR.
packages/server/src/adapters/standard/utils.ts (2)
4-6: Well-designed conditional context type with enhanced developer experience.This type definition elegantly makes the
contextproperty optional only when all fields in the generic typeTare optional. This improves the developer experience by not requiring an empty context object when it's not needed.The conditional type is well-implemented using utility types:
Omit<StandardHandleOptions<T>, 'context'>removes the original context property- The conditional part adds it back, making it optional only when appropriate
8-13: Good implementation of the options resolver function.This function properly handles the potential absence of a context property by providing a default empty object when needed. The comment on line 11 is particularly helpful in explaining why this approach is taken.
The function maintains type safety while providing a more flexible API, which aligns with the PR's goal of streamlining configuration processes.
packages/client/src/adapters/fetch/rpc-link.ts (2)
1-1: Updated import to use renamed ClientOptions type.This change correctly implements the renamed type import as stated in the PR objectives, replacing
ClientOptionsOutwithClientOptionsfor better clarity and consistency across the codebase.
22-22: Method signature updated to use ClientOptions.The call method's parameter type has been correctly updated from
ClientOptionsOut<T>toClientOptions<T>, aligning with the PR's objective to rename types for clarity and consistency throughout the codebase.packages/server/src/adapters/fetch/rpc-handler.test.ts (3)
5-6: Simplified test approach improves maintainability.The test has been streamlined to focus on verifying that the
RPCHandlerworks correctly with the new inheritance structure. This simplified approach better aligns with the class's new implementation that extendsFetchHandler<T>.
8-10: Direct handler test with proper options structure.This approach directly tests the handler functionality with a well-formed request and appropriate prefix option. The test properly validates the adapter-level interception capability by ensuring the handler correctly processes the request.
12-13: Clear assertions for response validation.The test includes appropriate assertions to verify both the response content (contains 'pong') and the HTTP status code (200), providing comprehensive validation of the handler's behavior.
packages/client/src/utils.ts (2)
2-2: Import updates align with new type usage.The updated imports correctly reflect the types needed for the new utility function while maintaining existing functionality.
38-43: Well-implemented type conversion utility.This function elegantly handles the conversion from
FriendlyClientOptions(where context may be optional) toClientOptions(where context is required), ensuring type safety while providing a good developer experience.packages/server/src/adapters/node/rpc-handler.test.ts (1)
1-3: Updated imports reflect simplified test approach.The imports have been updated to include only what's necessary for the current test implementation.
packages/openapi/src/adapters/fetch/openapi-handler.test.ts (1)
1-1: Import statement updated to use simplified server imports.The update correctly imports the necessary functionality from '@orpc/server'.
packages/server/src/plugins/cors.ts (2)
2-2: Import updated to include StandardHandlerPlugin.The import statement has been correctly updated to include the newly implemented interface.
16-16:Details
✅ Verification successful
Interface implementation updated for consistency.
The
CORSPluginnow implementsStandardHandlerPlugin<T>instead ofHandlerPlugin<T>, which aligns with the PR objective of renaming internal APIs for clarity and consistency.Ensure that all consumers of the
CORSPluginare updated to work with this interface change if necessary.
🏁 Script executed:
#!/bin/bash # Let's verify if there are any direct references to HandlerPlugin that might need updating rg -t ts "HandlerPlugin" --glob "!**/node_modules/**"Length of output: 3116
Interface update verified: CORSPlugin now correctly implements StandardHandlerPlugin, and consumers appear to be aligned.
- The file
packages/server/src/plugins/cors.tsimports and implementsStandardHandlerPlugin<T>as expected.- The repository-wide search confirmed that all relevant references now use
StandardHandlerPlugin(including in tests and adjacent modules), ensuring consistency with the new internal API naming.- No obsolete references to
HandlerPlugin<T>were found that would impact consumers ofCORSPlugin.packages/server/src/plugins/response-headers.ts (2)
1-1: Updated imports to reflect the use of StandardHandlerPluginThe import statement has been updated to import
StandardHandlerPluginfrom '../adapters/standard' instead of using the previousHandlerPluginfrom './base'. This aligns with the PR objective of renamingHandlerPlugintoStandardHandlerPlugin.
7-7: Updated class implementation to use StandardHandlerPluginThe
ResponseHeadersPluginclass now implementsStandardHandlerPlugin<T>instead ofHandlerPlugin<T>, which aligns with the PR objective of renaming internal APIs for clarity and consistency. The change maintains the same interface behavior with the plugin'sinitmethod.packages/server/src/adapters/node/handler.test.ts (5)
1-18: Well-structured test setup with proper mockingThe test setup properly mocks external dependencies and includes a
beforeEachhook to clear mocks between tests, following testing best practices. The mocking approach allows for isolated testing of theNodeHttpHandlerclass.
20-49: Good test scenario setup with handler options configurationThe test setup creates a handler instance with appropriate options, including the newly relocatable
eventIteratorKeepAliveCommentconfiguration and adapter interceptors, which aligns with the PR objective of moving configurations from the.handlemethod to handler options.
51-96: Comprehensive test for successful request handlingThis test case thoroughly verifies that the handler correctly processes matched requests, calls the appropriate functions with expected arguments, and returns the expected result. The assertions validate both the result and the interaction with dependencies.
98-135: Thorough test for unmatched request scenariosThe test case verifies the handler's behavior when a request doesn't match any handler, ensuring that the expected response is returned and that
sendStandardResponseis not called. The assertions are comprehensive and validate the proper interaction with dependencies.
137-156: Plugin initialization test validates adapter-level plugin functionalityThis test ensures that plugins are properly initialized with the runtime adapter, which is a key part of the "Adapter-Level Plugin Interception" feature described in the PR objectives. The test verifies that the initialization function is called with the correct configuration.
packages/client/src/dynamic-link.ts (3)
2-2: Updated import to use renamed ClientOptions typeThe import statement has been updated to use
ClientOptionsinstead ofClientOptionsOut, aligning with the PR objective of renaming internal APIs for clarity and consistency.
11-11: Updated parameter type in linkResolver to use ClientOptionsThe parameter type for the
linkResolverfunction has been changed fromClientOptionsOut<TClientContext>toClientOptions<TClientContext>, maintaining consistency with the type renaming across the codebase.
18-18: Updated call method parameter type to use ClientOptionsThe parameter type for the
callmethod has been updated fromClientOptionsOut<TClientContext>toClientOptions<TClientContext>, completing the consistent type renaming throughout the class implementation.packages/server/src/adapters/fetch/handler.test.ts (5)
1-16: Well-structured test setup with proper mockingThe test setup properly mocks the necessary dependencies using Vitest's mocking capabilities. The approach preserves the original implementation while allowing for spying on function calls, which is a good testing practice for validating interactions.
18-33: Test scenario setup includes handler options configurationThe test setup creates a handler instance with the appropriate options, including the
eventIteratorKeepAliveCommentconfiguration and adapter interceptors. This aligns with the PR objective of moving configurations from the.handlemethod to handler options.
34-76: Comprehensive test for successful request handlingThis test case thoroughly verifies that the
FetchHandlercorrectly processes matched requests, calls the appropriate functions with expected arguments, and returns the expected result. The assertions validate both the result and the interaction with dependencies, including the interceptor.
78-114: Thorough test for unmatched request scenariosThe test case verifies the handler's behavior when a request doesn't match any handler, ensuring that the expected response is returned and that
toFetchResponseis not called. The assertions comprehensively validate the proper interaction with dependencies.
116-135: Plugin initialization test validates adapter-level plugin functionalityThis test ensures that plugins are properly initialized with the runtime adapter, which is a key part of the "Adapter-Level Plugin Interception" feature described in the PR objectives. The test verifies that the initialization function is called with the correct configuration.
packages/client/src/adapters/standard/rpc-link-codec.ts (5)
2-2: Consistent import statement updateReplacing
ClientOptionsOutwithClientOptionsin the import is aligned with the newly introduced naming scheme. This change helps maintain consistency across the codebase.
15-15: Refined type usage forurlpropertySwitching to
ClientOptions<T>in the parameter tuple reflects the broader refactoring. The typedValue<>signature is correct, and no issues are evident here.
26-26: Refined type usage formaxUrlLengthpropertySimilarly, using
ClientOptions<T>harmonizes with the other interface properties. This maintains a clear, uniform approach to the client options.
37-37: Refined type usage formethodpropertyThe updated typing is consistent with the rest of the code. No major concerns or improvements needed here.
54-54: Refined type usage forheaderspropertyAdopting
ClientOptions<T>is properly aligned with the rest of the refactor. Looks good overall.packages/server/src/adapters/fetch/handler.ts (7)
1-6: Review of imports and utilitiesThe newly introduced imports from
@orpc/sharedand@orpc/standard-server-fetchappear correctly referenced. Usage ofNoInfer<>for preserving type inference looks thoughtfully applied.
8-8: Definition ofFetchHandleResultClearly distinguishes between matched and unmatched scenarios. This makes the return type explicit and improves readability.
10-12:FetchHandlerPlugininterface extensionProviding a
initRuntimeAdaptermethod is a clean approach for plugin-based initialization. This nicely complements theStandardHandlerPlugindefinition.
14-18:FetchHandlerInterceptorOptionsinterface definitionExtends
StandardHandleOptions<T>while adding fetch-specific properties likerequestandtoFetchResponseOptions. No concerns here.
19-23:FetchHandlerOptionsinterface structureOptional
adapterInterceptorsandpluginsfields provide flexibility for custom interceptors and plugin configurations. This design is nicely extensible.
25-39: Constructor logic inFetchHandlerInitializes plugins and interceptors gracefully. Converting plugin options and interceptors to arrays ensures consistent iteration. This is straightforward and effective.
41-68: Implementation of thehandlemethodLeverages interceptors for request processing and delegates to the standard handler effectively. The final step uses
toFetchResponseif a match is found, preserving a clean, layered design.packages/client/src/adapters/fetch/link-fetch-client.ts (3)
3-3: Import statement aligned with new namingSwitching from
ClientOptionsOuttoClientOptionsaligns with the overall refactor across the codebase. Implementation looks consistent.
11-11: Refinedoptionsparameter type inLinkFetchClientOptionsUsing
ClientOptions<T>for theoptionsparameter in thefetchmethod matches the standardized interface. No issues detected.
26-26: Updated signature incallmethodReplacing
ClientOptionsOut<T>withClientOptions<T>maintains consistency with the new type definitions. This is a clear and logical change.packages/client/src/plugins/retry.ts (5)
2-3: Imports updated for new plugin architecture
These updated imports reflect the shift fromClientPlugintoStandardLinkPluginand fromClientOptionsOuttoClientOptions. They appear consistent with the broader refactoring.
30-30: Refactor to useClientOptions
ReplacingClientOptionsOut<ClientRetryPluginContext>withClientOptions<ClientRetryPluginContext>aligns with the new naming conventions. Please ensure any upstream or downstream usage is updated accordingly.
42-42: Same type refactoring as line 30
52-52: Same type refactoring as line 30
64-64: Class now implementsStandardLinkPlugin
Switching fromClientPlugintoStandardLinkPluginfollows the new plugin interface structure. This should unify plugin behavior across the codebase.packages/server/src/adapters/fetch/rpc-handler.ts (4)
3-4: New imports align with updated handler options
ImportingStandardRPCHandlerOptionsandFetchHandlerOptionsreflects the merged configuration approach for RPC handlers.
7-7: AdoptingFetchHandlerbase class
Replacing a custom or deprecated base handling approach withFetchHandlersimplifies maintenance and aligns with the newly standardized architecture.
9-10: Class extendsFetchHandlerwith combined options
The constructor mergesFetchHandlerOptionsandStandardRPCHandlerOptionsviaNoInfer, ensuring strong type checking. Verify that all references to the old handler structure have been removed or updated.
16-16: Delegation toStandardHandler
Forwarding requests to theStandardHandlerinstance fully leverages the new inheritance model. This should minimize duplication and maintain consistent processing logic.packages/server/src/adapters/node/rpc-handler.ts (4)
3-4: New imports reflect merged Node and standard RPC handler options
Pulling inStandardRPCHandlerOptionsandNodeHttpHandlerOptionsindicates a unified configuration pattern.
7-7: Inheritance fromNodeHttpHandler
Switching to extendNodeHttpHandlerunifies behaviors and reduces implementation overhead. This follows the consistent refactoring approach observed in other handlers.
9-10: Combining standard and Node-specific options
MergingStandardRPCHandlerOptions<T>andNodeHttpHandlerOptions<T>in the constructor enforces a clean, single configuration source. Validate that client code references the new signature correctly.
16-16: Relying onStandardHandlerfor core logic
Passingrouter,matcher,codec, and combinedoptionsensures a modular, maintainable implementation that delegates the heavy lifting toStandardHandler.packages/openapi/src/adapters/fetch/openapi-handler.ts (4)
2-2: Looks good.This new import of
FetchHandlerOptionsproperly sets up the type requirements for handling fetch-specific options.
5-5: Appropriate import forFetchHandler.Switching to a direct import of
FetchHandlerindicates the intent to leverage its built-in request-handling logic more effectively.
9-10: Clear extension fromFetchHandler.By extending
FetchHandler<T>, you streamline theOpenAPIHandlerimplementation and reduce duplicate logic. The constructor signature mergingStandardOpenAPIHandlerOptions<T>withFetchHandlerOptions<T>is consistent with the intended design.
17-17: Constructor invocation matches inheritance design.Passing both the
StandardHandlerinstance and the same options to thesuperconstructor properly cascades all configurations. This cleanly unifies OpenAPI-specific and fetch-specific logic.packages/server/src/adapters/standard/handler.ts (10)
2-2: ImportingInterceptor.Bringing in
Interceptorfrom@orpc/sharedis appropriate for advanced request/response interception logic.
9-9: Use ofintercept,toArray, andtrim.These shared utilities improve readability and guard against undefined or non-array values.
12-15: Expanded interface for handle options.Switching from a type alias to an interface clarifies that
contextis mandatory, and the optionalprefixis well-defined.
19-21: Plugin initialization.Providing an optional
initmethod inStandardHandlerPluginis a neat way to handle plugin-level setup before requests.
23-25: Refined interceptor options.
StandardHandlerInterceptorOptionsnow extendingStandardHandleOptionsensures that every interceptor call has consistent access tocontextandrequest.
28-28: Consistent renaming toStandardHandlerPlugin.This change aligns well with the rest of the refactoring efforts to name plugins more explicitly.
52-54: Explicit typed arrays for interceptors.Using
Exclude<undefined>enforces that interceptors and plugins are always stored as arrays, preventing repeated null checks.
60-60:NoInferusage for options.This pattern preserves inference boundaries correctly when passing
StandardHandlerOptions<T>into the constructor.
66-68: Graceful fallback to arrays.By using
toArray, any undefined interceptors become an empty array, avoiding runtime errors.
73-73: Streamlinedhandlemethod.
- Consolidating interceptors into
rootInterceptorsandthis.interceptorsis straightforward for layered interception.- Forwarding
requestwithin a combined options object clarifies the flow of data into the intercept chain.- Using
clientInterceptorsfor procedure invocation ensures consistent behavior across different routing paths.Also applies to: 75-76, 82-82, 98-98
packages/client/src/types.ts (4)
3-3: Renamed toFriendlyClientOptions.Renaming clarifies these client options are user-friendly and not strictly internal.
9-11: Refined function parameter tuple.Using
FriendlyClientOptionsinClientRestensures the method signature cleanly supports optional input and context.
25-25:ClientOptionsextendsFriendlyClientOptions.Taking on a required
contextprop inClientOptionsenforces that higher-level usage always includes context.
30-30: Accurate function signature.Updating
callto useClientOptions<TClientContext>is consistent with the new naming and ensures a strongly typed context.packages/openapi/src/adapters/node/openapi-handler.ts (2)
2-2: New imports from@orpc/server/node
These imports correctly align with the updated architecture for Node HTTP handling. The references toNodeHttpHandlerOptionsandNodeHttpHandlerappear consistent with their purpose in orchestrating request handling.Also applies to: 5-5
9-17: Inherited design forOpenAPIHandler
By extendingNodeHttpHandler<T>, this refactor centralizes the HTTP request handling, makingOpenAPIHandlerlighter and more cohesive. The constructor’s approach of combiningStandardOpenAPIHandlerOptions<T>withNodeHttpHandlerOptions<T>is logical. Ensure that no unintended configuration conflicts occur when merging these two option types. Otherwise, the inheritance structure looks maintainable.packages/server/src/adapters/node/handler.ts (6)
1-7: Imports and type definitions
IntroducingNodeHttpRequest,NodeHttpResponse, andSendStandardResponseOptionsfrom@orpc/standard-server-nodeis consistent with the new Node-based adapter approach. These imports set the stage for building an HTTP handler seamlessly integrated with the standard server logic.
8-8: Simple result type
TheNodeHttpHandleResultunion type is straightforward for indicating matched vs. unmatched requests. This clarity can help upstream logic quickly determine how to proceed without additional checks.
10-12:NodeHttpHandlerPluginextension
IntroducinginitRuntimeAdapterforNodeHttpHandlerPlugin<T>ensures plugins can do last-mile initialization tasks. This design is flexible and aligns with the existingStandardHandlerPlugin. Nice extension of the plugin system.
14-22:NodeHttpHandlerOptionsstructure
These options incorporateadapterInterceptorsandplugins, which provide an extensible interception layer at the adapter level. This approach is well-structured for advanced behavior (e.g., request/response transformations) and fosters consistent patterns across the codebase.
40-67:handlemethod flow
This method neatly intercepts the request at the adapter level before delegating tostandardHandler.handle. It then sends the response if matched. The design fosters consistent interceptor logic while allowing you to refine the request/response as needed. Looks correct and well-structured, with clear responsibilities.
24-38:Details
❓ Verification inconclusive
Class naming consistency
Definingexport class NodeHttpHandler<T extends Context> implements NodeHttpHandler<T> { ... }could be confusing if an interface of the same name is also in scope. However, if the interface is purely auto-generated or type-aliased and does not conflict, this might be acceptable. Double-check duplication within the same namespace to avoid overshadowing.To confirm, please search for any interface named
NodeHttpHandlerto ensure no overshadowing:
🏁 Script executed:
#!/bin/bash # Searching for a conflicting interface named NodeHttpHandler throughout the codebase rg --context 3 "interface NodeHttpHandler<"Length of output: 45
Naming Conflict Check – Please Verify Manually
The initial search forinterface NodeHttpHandler<didn’t return any results, suggesting that there’s likely no conflicting interface in the repository. However, since the absence of output can sometimes be misleading, I recommend manually verifying that no interface namedNodeHttpHandler(with or without generic parameters) is defined elsewhere in the codebase to ensure naming clarity.packages/client/src/adapters/standard/types.ts (2)
2-2: ImportingClientOptions
Switching toClientOptionsaligns with the revised naming convention and the broader changes replacingClientOptionsOut. This ensures consistency across the client code.
10-10: Aligning thecallmethod signature
UsingClientOptions<T>removes ambiguity and keeps the call flow strongly typed. This completes the transition away fromClientOptionsOut.packages/client/src/adapters/standard/link.ts (9)
3-3: Import type renamed from ClientOptionsOut to ClientOptionsThis change aligns with the PR objectives, which stated that
ClientOptionsOuthas been renamed toClientOptionsfor clarity and consistency across the codebase.
5-5: Added toArray utility importGood addition of the
toArrayutility, which will be used to ensure consistent array handling in the constructor.
9-11: New StandardLinkPlugin interface replaces ClientPluginThe introduction of
StandardLinkPluginwith an optionalinitmethod provides a clearer plugin initialization pattern, aligning with the PR objective to renameClientPlugintoStandardLinkPlugin.
14-14: Updated type reference to ClientOptionsType signature updated to use
ClientOptions<T>instead ofClientOptionsOut<T>, matching the renamed type.
16-16: Plugin type updated to StandardLinkPluginType signature updated to use the newly defined
StandardLinkPlugin<T>interface instead of the previousClientPlugin<T>.
28-30: Improved plugin initialization patternReplaced the previous composite plugin approach with a more straightforward plugin initialization pattern. Each plugin's
initmethod is called with the options if it exists, providing a cleaner extension point for plugins.
32-33: Enhanced array initialization with toArray utilityReplaced manual array initialization with the
toArrayutility function, making the code more robust by ensuring arrays are always returned even when inputs are undefined.
36-36: Updated method signature to use ClientOptionsMethod signature updated to use
ClientOptions<T>instead ofClientOptionsOut<T>, maintaining type consistency across the API surface.
44-44: Updated private method signature to use ClientOptionsPrivate method signature updated to use
ClientOptions<T>instead ofClientOptionsOut<T>, maintaining internal type consistency.
1 participant
Plugins now have the ability to intercept and modify requests and responses directly at the adapter level
Event Iterator Keep AliveWe move configs for
Event Iterator Keep Alivefrom.handletohandler options(define when creating handler)Rename internal APIs
HandlerPlugin->StandardHandlerPluginClientOptions->FriendlyClientOptionsClientOptionsOut->ClientOptionsClientPlugin->StandardLinkPluginStandardHandleOptions->FriendlyStandardHandleOptionsSummary by CodeRabbit
Documentation
Refactor
Tests
resolveFriendlyClientOptionsandresolveMaybeOptionalOptionsfunctions.Chores