feat(nest): add async configuration support for ORPCModule #916
Conversation
dosubot
bot
added
the
size:M
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds ORPCModule.forRootAsync to enable async configuration via factory and DI (e.g., REQUEST), updates tests to validate per-request context propagation and keep-alive config, and updates docs to show using forRootAsync with REQUEST/express Request. No other public APIs changed. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Client
participant NestApp
participant ORPCModule
participant Factory as useFactory (forRootAsync)
participant Interceptor as ImplementInterceptor
participant Handler as Controller/Handler
Client->>NestApp: HTTP request /ping
activate NestApp
Note over NestApp,ORPCModule: App bootstrapped with ORPCModule.forRootAsync
NestApp->>Factory: Resolve ORPC config (inject REQUEST)
Factory-->>NestApp: { interceptors, keepAlive, context:{ request } }
NestApp->>Interceptor: Apply interceptor with context(request)
Interceptor->>Handler: Invoke handler with per-request context
Handler-->>Interceptor: Result
Interceptor-->>NestApp: sendStandardResponse(result, keepAlive)
NestApp-->>Client: 200 pong
deactivate NestApp
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
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. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
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 introduces asynchronous configuration support for the ORPCModule within the @orpc/nest package. This new forRootAsync method allows developers to configure the ORPC module using asynchronous operations, such as injecting dynamic values like the NestJS REQUEST object, which can then be used to provide context to ORPC interceptors and middlewares. This enhances flexibility for integrating ORPC with NestJS applications that require request-scoped or asynchronously resolved configurations.
Highlights
- Asynchronous Module Configuration: Implemented ORPCModule.forRootAsync to enable asynchronous configuration of the ORPC module, aligning with NestJS's dynamic module patterns.
- Request Context Integration: Demonstrated how to inject the NestJS REQUEST object into the ORPC module's context using forRootAsync, allowing request-specific data to be accessible within ORPC interceptors.
- Comprehensive Testing: Added a dedicated test case to validate the correct behavior and data flow when using ORPCModule.forRootAsync, ensuring the new feature functions as expected.
- Documentation Update: Updated the integration documentation to include an example of using forRootAsync for configuring the ORPCModule with request context.
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 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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
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. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces asynchronous configuration support for ORPCModule via a new forRootAsync method. The changes include the implementation of this method, corresponding tests, and documentation updates. My review focuses on aligning the new forRootAsync method with standard NestJS practices for better usability and maintainability. I've suggested an improvement to allow importing dependency modules, which is a common pattern for async modules in NestJS.
Codecov Report✅ All 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/interop
@orpc/json-schema
@orpc/nest
@orpc/openapi
@orpc/openapi-client
@orpc/otel
@orpc/react
@orpc/react-query
@orpc/experimental-react-swr
@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: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
packages/nest/src/module.ts (1)
33-39: Nice:importssupport aligns with standard Nest async modulesThis addresses prior feedback and enables common patterns (e.g., ConfigModule).
🧹 Nitpick comments (4)
apps/content/docs/openapi/integrations/implement-contract-in-nest.md (1)
229-229: Clarify adapter-specific typingThe comment says “if you use express adapter” which is correct for the
expresstype, but users on Fastify should useFastifyRequestinstead. Clarify with a dual example or a quick note.Suggested tweak:
import { Request as ExpressRequest } from 'express' // Express adapter // import type { FastifyRequest } from 'fastify' // Fastify adapterAnd in
useFactory, type the param to match your adapter.packages/nest/src/module.ts (2)
32-36: Tighten option types to Nest’s built-insUse
ModuleMetadata['imports']andFactoryProvider['inject']for better type safety and IDE hints.Apply this diff:
- static forRootAsync(options: { - imports?: any[] - useFactory: (...args: any[]) => Promise<ORPCModuleConfig> | ORPCModuleConfig - inject?: any[] - }): DynamicModule { + static forRootAsync(options: { + imports?: ModuleMetadata['imports'] + useFactory: (...args: any[]) => Promise<ORPCModuleConfig> | ORPCModuleConfig + inject?: FactoryProvider['inject'] + }): DynamicModule {Add type-only imports:
// at top-level (type-only) import type { ModuleMetadata, FactoryProvider } from '@nestjs/common'
48-49: Consider makingglobalconfigurable (default true)Some apps may prefer scoping this module. Expose
global?: booleanin options and useoptions.global ?? true.Proposed change:
- global: true, + global: options['global' as never] ?? true,And add
global?: booleanto the options shape.packages/nest/src/implement.test.ts (1)
418-464: Strengthen the async-config test to prove per-request scopingTo ensure the config factory runs per request (and isn’t cached), make a second request with different headers and assert the interceptor receives the new
requestobject. Also assert the interceptor call count accordingly.Apply this diff:
it('works with ORPCModule.forRootAsync', async () => { const interceptor = vi.fn(({ next }) => next()) @@ expect(res.statusCode).toEqual(200) expect(res.body).toEqual('pong') @@ - expect(interceptor).toHaveBeenCalledTimes(1) + expect(interceptor).toHaveBeenCalledTimes(1) @@ expect(sendStandardResponseSpy).toHaveBeenCalledTimes(1) expect(sendStandardResponseSpy).toHaveBeenCalledWith(expect.anything(), expect.anything(), expect.objectContaining({ eventIteratorKeepAliveComment: '__TEST__', })) + + // Make a second call to ensure the factory is evaluated per request + const res2 = await supertest(httpServer) + .post('/ping?param=second') + .set('x-custom', 'second') + .send({ hello: 'again' }) + + expect(res2.statusCode).toEqual(200) + expect(res2.body).toEqual('pong') + + expect(interceptor).toHaveBeenCalledTimes(2) + expect(interceptor).toHaveBeenLastCalledWith(expect.objectContaining({ + context: expect.objectContaining({ + request: expect.objectContaining({ + url: '/ping?param=second', + headers: expect.objectContaining({ + 'x-custom': 'second', + }), + }), + }), + })) + expect(sendStandardResponseSpy).toHaveBeenCalledTimes(2)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
apps/content/docs/openapi/integrations/implement-contract-in-nest.md(1 hunks)packages/nest/src/implement.test.ts(2 hunks)packages/nest/src/module.ts(1 hunks)
⏰ 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: test
- GitHub Check: publish-commit
- GitHub Check: lint
🔇 Additional comments (2)
packages/nest/src/implement.test.ts (2)
2-5: Good: explicit typing and DI token import for per-request factoryUsing
type { Request }withREQUESTsets up the async factory ergonomically for Express users.
423-431: Minor: align example names with docsDocs currently show
eventIteratorKeepAliveInterval, while tests useeventIteratorKeepAliveComment. Keep tests as-is (they match the actual API) and adjust docs instead (see docs comment).If the API indeed supports both properties, consider adding an assertion here for the interval variant as well. Otherwise, leave the test unchanged after the docs fix.
Summary by CodeRabbit