Conversation
For example, if middleware A accepts unknown as input, B can now specify a more specific input type (e.g., number, { id: string }, etc.).
Previously, both A and B were required to use unknown for the input type when concatenated.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe changes update the middleware documentation and enhance the type system for decorated middleware in the codebase. Documentation is expanded to clarify how to use Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant MiddlewareA
participant MiddlewareB
User->>MiddlewareA: Call with input { input1, input2 }
MiddlewareA->>MiddlewareB: (After .mapInput or .concat) Call with mapped input
MiddlewareB-->>User: Return processed result
Poem
✨ Finishing Touches
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:
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 (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
More templates
@orpc/arktype
@orpc/client
@orpc/openapi
@orpc/openapi-client
@orpc/contract
@orpc/react
@orpc/react-query
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/svelte-query
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
packages/server/src/middleware-decorated.ts (1)
7-79: 💡 Verification agent🧩 Analysis chain
Verify implementation supports the new type definitions
While the type signature changes look good, it's important to ensure the implementation in
decorateMiddlewarecorrectly handles the narrowed input types.
🏁 Script executed:
#!/bin/bash # Check if the implementation in decorateMiddleware can properly handle the narrowed input types # Examine the decorated.concat implementation cat packages/server/src/middleware-decorated.ts | grep -A 20 "decorated.concat = " # Look for tests that verify this behavior fd -t f test -e ts | grep -l middleware | xargs grep -l concat | xargs catLength of output: 1022
Fix
concatto preserve narrowed input typesThe current
decorated.concatimplementation inpackages/server/src/middleware-decorated.tscasts everything toany, which bypasses your new generic signatures and means mapped or narrowed inputs aren’t actually enforced. You’ll need to:• In
middleware-decorated.ts, remove theas anycasts aroundinput,options, and return values indecorated.concat.
• Update the callback signatures to use the proper generic parameters (e.g.UInput,UMappedInput,TInput) instead ofany.
• Add unit tests verifying thatmapInputandconcattruly narrow the input type (for example, assert that passing an incorrect input shape fails at compile time).
🧹 Nitpick comments (1)
apps/content/docs/middleware.md (1)
168-170: Added guidance for concatenating middlewares with different input typesGood informational note explaining that
.mapInputcan be used to align input types before concatenation, which is essential for users to understand when working with the new type narrowing feature.Consider enhancing this section with a code example similar to the first info block, showing how to concatenate two middlewares with different input types. This would provide a more concrete illustration of the concept.
::: info If you want to concatenate two middlewares with different input types, you can use `.mapInput` to align their input types before concatenation. + +```ts +const validateId = os.middleware(async ({ next }, input: number) => { + if (input <= 0) throw new Error('Invalid ID') + return next() +}) + +const validateUser = os.middleware(async ({ next }, input: { name: string }) => { + if (!input.name) throw new Error('Name required') + return next() +}) + +// Concatenate middlewares with different input types +const validateUserWithId = validateId + .mapInput((input: { id: number, name: string }) => input.id) + .concat(validateUser.mapInput((input: { id: number, name: string }) => ({ name: input.name }))) +``` :::
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/content/docs/middleware.md(2 hunks)packages/server/src/middleware-decorated.test-d.ts(10 hunks)packages/server/src/middleware-decorated.ts(3 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
packages/server/src/middleware-decorated.test-d.ts (2)
packages/server/src/middleware-decorated.ts (1)
DecoratedMiddleware(7-79)packages/server/tests/shared.ts (1)
CurrentContext(8-8)
packages/server/src/middleware-decorated.ts (3)
packages/server/src/context.ts (3)
Context(1-1)MergedCurrentContext(9-9)MergedInitialContext(3-7)packages/server/src/builder.ts (1)
middleware(146-150)packages/server/src/middleware.ts (2)
Middleware(46-61)MapInputMiddleware(65-67)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: publish-commit
🔇 Additional comments (17)
packages/server/src/middleware-decorated.ts (6)
30-30: Type parameter enhancement for better input type narrowingThis change allows for more specific input types when concatenating middlewares. By introducing
UInput extends TInput, a middleware can now accept a narrower input type than the middleware it's being concatenated with.
36-36: Updated middleware input type parameter to use narrowed typeThe middleware input parameter now uses the new
UInputgeneric type parameter, allowing for proper type narrowing in middleware chains.
44-44: Return type now preserves the narrowed input typeThe returned
DecoratedMiddlewarenow correctly propagates the narrowed input type through the middleware chain.
58-58: Added same type parameter enhancement to second concat overloadConsistent application of the
UInput extends TInputtype parameter to the second concat overload ensures both methods support input type narrowing.
70-70: Updated mapInput parameter to use narrowed input typeThe
mapInputparameter now maps from the narrowedUInputtype rather than the originalTInput, maintaining type safety throughout the middleware chain.
74-74: Return type consistency with narrowed input typeThe returned
DecoratedMiddlewarefrom the second concat overload also correctly preserves the narrowed input type.packages/server/src/middleware-decorated.test-d.ts (10)
13-13: Updated test input type to a more complex shapeChanged from single property object
{ input: string }to a two-property object{ input1: string, input2: string }to better test the new input type narrowing capabilities.
25-25: Consistent input type update in type assertionsInput type updated consistently in the middleware type assertions to match the type defined for the
decoratedobject.
34-34: Updated mapInput test to work with new input typeThe
mapInputtest now properly demonstrates transforming from a string literal to the new two-property object, testing the type narrowing capabilities.
53-53: Updated concat test to use the new input typeThe concat test now expects
input1property from the input, properly testing the type propagation during middleware concatenation.
74-74: Updated expected type assertion for concat resultThe type assertion for the concatenated middleware result now correctly expects the new input type with two properties.
83-84: Added type error test for incorrect input shapeNew test ensures TypeScript correctly rejects inputs that don't match the expected shape, validating the type safety of the narrowed input types.
108-108: Updated mapInput parameter type in concat with map testThe input type in the mapInput callback now correctly reflects that only the
input1property is needed by the middleware after mapping.
116-116: Consistent input type in concat with map result typeThe expected type for the concatenated middleware with mapInput correctly maintains the two-property input type.
131-132: Added type error test for input mismatch with mapInputThis test ensures TypeScript correctly rejects mapInput functions that use an invalid input type, further validating type safety.
146-146: Updated input types in TInContext testsThe input types in the TInContext tests are consistently updated to the new two-property format, ensuring comprehensive testing of the type system changes.
Also applies to: 157-157
apps/content/docs/middleware.md (1)
124-136: Added helpful documentation for mapInput usageExcellent addition explaining how to adapt middleware to accept different input shapes using
.mapInput. The example clearly demonstrates transforming from an object with anidproperty to a simple number input that the original middleware expects.
For example, if middleware A accepts unknown as input, B can now specify a more specific input type (e.g., number, { id: string }, etc.). Previously, both A and B were required to use unknown for the input type when concatenated.
Summary by CodeRabbit
Documentation
Bug Fixes
Tests