Reviewing files that changed from the base of the PR and between eccbaa4 and 315eccc.

• apps/content/docs/openapi/integrations/implement-contract-in-nest.md (3 hunks)
• packages/nest/src/implement.test.ts (5 hunks)
• packages/nest/src/implement.ts (4 hunks)
• packages/nest/src/module.ts (2 hunks)

• GitHub Check: Agent
• GitHub Check: publish-commit
• GitHub Check: test
• GitHub Check: lint
• GitHub Check: Cloudflare Pages

apps/content/docs/openapi/integrations/implement-contract-in-nest.md (1)

293-315: Solid example for the custom send response pattern.

The interceptor logic correctly demonstrates:

• Validating response status and body type before custom handling
• Falling back to default behavior via next() for non-object/array responses
• Setting status and headers manually on the Express response

packages/nest/src/module.ts (1)

13-22: Configuration interface properly extended for new features.

The ORPCModuleConfig interface correctly extends the serializer option types and adds the sendResponseInterceptors field. Using any for request and response is reasonable here since NestJS supports multiple HTTP adapters (Express, Fastify).

packages/nest/src/implement.test.ts (3)

217-226: Good coverage for dynamic success status.

This test verifies that handlers can override the default/contract-defined status by returning a custom status in the response object. The as any cast is acceptable here for test mocking purposes.

---

493-552: Comprehensive tests for sendResponseInterceptors.

Both test cases effectively cover:

1. Overriding response body while preserving the contract-defined status (202)
2. Overriding both status and body via the response object

---

555-591: Useful compatibility test for Fastify cookie integration.

This test validates that oRPC plays nicely with Fastify plugins like @fastify/cookie when using @Res({ passthrough: true }).

packages/nest/src/implement.ts (3)

58-64: Correct application of HttpCode decorator for contract-defined status.

The HttpCode decorator is properly applied using fallbackContractConfig to ensure the contract's successStatus is respected. This integrates well with NestJS's response handling.

---

160-171: Clean interceptor pipeline for response handling.

The use of intercept with toArray elegantly handles both undefined and array cases for sendResponseInterceptors. The callback correctly distinguishes between Fastify and Node/Express responses using the 'raw' in response check.

---

96-104: Good defensive handling for optional config injection.

The comment explaining why manual defaulting is needed with @Optional() is helpful. The nullish coalescing to an empty object ensures safe property access throughout the class.

Reviewing files that changed from the base of the PR and between 315eccc and 0a6f7cb.

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

• apps/content/docs/openapi/integrations/implement-contract-in-nest.md (3 hunks)
• packages/nest/src/implement.test.ts (5 hunks)
• packages/nest/src/implement.ts (5 hunks)
• packages/nest/src/index.test.ts (1 hunks)
• packages/nest/src/index.ts (2 hunks)
• packages/nest/src/module.ts (1 hunks)
• playgrounds/nest/package.json (1 hunks)
• playgrounds/nest/src/app.module.ts (1 hunks)

• GitHub Check: CodeQL analysis (javascript-typescript)
• GitHub Check: Agent
• GitHub Check: lint
• GitHub Check: test
• GitHub Check: publish-commit
• GitHub Check: Cloudflare Pages

playgrounds/nest/package.json (1)

18-18: LGTM!

The new @orpc/json-schema dependency is required for the SmartCoercionPlugin used in app.module.ts, and the version tag is consistent with other @orpc/* packages.

packages/nest/src/index.test.ts (1)

1-21: LGTM!

The test correctly verifies that the implement alias delegates to @orpc/server's implementation with the correct arguments and returns the expected value. The mock setup properly wraps the original function with a spy.

apps/content/docs/openapi/integrations/implement-contract-in-nest.md (1)

227-254: LGTM!

The ORPCGlobalContext type augmentation example and the updated configuration options (customJsonSerializers, plugins) are well-documented and align with the implementation in app.module.ts.

playgrounds/nest/src/app.module.ts (1)

24-43: LGTM!

The async module configuration correctly injects the request context and sets up the SmartCoercionPlugin with ZodToJsonSchemaConverter. This demonstrates the new forRootAsync pattern well.

packages/nest/src/index.ts (2)

22-30: LGTM!

The implement alias with ORPCGlobalContext as the default context type provides good developer experience for Nest users by eliminating the need to explicitly specify context types. The implementation correctly delegates to the base implementation while preserving generic flexibility.

---

1-11: LGTM!

Clean separation of imports and explicit re-exports. Removing the blanket re-export of implement from @orpc/server in favor of the custom alias ensures users get the Nest-specific version with proper defaults.

packages/nest/src/implement.test.ts (3)

217-226: Good addition of dynamic success status test.

This test properly validates that handlers can override the default status code at runtime, ensuring the status property in the response is respected.

---

554-641: Good test for plugin cloning behavior.

The test correctly verifies that handler options are cloned before applying plugins, preventing interceptors from running multiple times across requests. The multiple request assertions (res1, res2, res3) effectively validate this behavior.

---

673-709: Good compatibility test for Fastify cookie handling.

This test ensures that the interceptor flow properly integrates with Fastify plugins like @fastify/cookie, validating that response modifications (setting cookies) work alongside oRPC response handling.

packages/nest/src/module.ts (2)

15-28: Empty interface is intentional for module augmentation.

The static analysis hint about empty interface is a false positive in this context. The ORPCGlobalContext interface is intentionally empty to serve as a declaration merging point, allowing users to extend it via module augmentation as documented in the JSDoc. This is a common TypeScript pattern for extensible type systems.

---

30-42: Well-structured module configuration types.

The extended ORPCModuleConfig properly combines multiple option interfaces and adds the new plugins and sendResponseInterceptors configurations with appropriate typing.

packages/nest/src/implement.ts (4)

96-111: Good refactor: codec now instantiated per-instance.

The StandardOpenAPICodec is now created once in the constructor and stored as a class property, avoiding unnecessary object instantiation on every request. This addresses the previous review feedback.

---

132-140: Good defensive cloning of arrays before plugin initialization.

The comment explains the rationale well. Cloning interceptors and plugins arrays prevents plugins from mutating shared state across requests. Consider tracking this TODO for future improvement.

---

147-158: Well-designed interceptor pipeline for response handling.

The intercept utility with sendResponseInterceptors provides a clean extension point for customizing response behavior while maintaining proper support for both Fastify and Node.js response types.

---

146-159: Based on my verification of the codebase, I can now provide a comprehensive rewritten review comment:

Handle unmatched routes explicitly instead of returning undefined.

The current code implicitly returns undefined when result.matched is false. While this shouldn't occur in normal operation (the hardcoded match callback always succeeds and no prefix is configured), other adapters like FastifyHandler and NodeHttpHandler explicitly return or propagate the unmatched status. For consistency and defensive programming, add explicit handling:

if (result.matched) {
  return intercept(
    toArray(this.config.sendResponseInterceptors),
    { request: req, response: res, standardResponse: result.response },
    async ({ response, standardResponse }) => {
      if ('raw' in response) {
        await StandardServerFastify.sendStandardResponse(response, standardResponse, this.config)
      }
      else {
        await StandardServerNode.sendStandardResponse(response, standardResponse, this.config)
      }
    },
  )
}

// Handle unmatched case explicitly
throw new Error(`Route not matched for ${req.method} ${req.url}`)

This prevents silent failures if the route configuration changes in the future.

Reviewing files that changed from the base of the PR and between 0a6f7cb and f58dd47.

• packages/nest/src/module.ts (1 hunks)

• GitHub Check: lint
• GitHub Check: Cloudflare Pages

packages/nest/src/module.ts (3)

3-8: LGTM!

The new imports correctly support the extended configuration options for serializers, codecs, plugins, and response interceptors.

---

15-28: LGTM! The empty interface pattern is intentional.

This follows the standard TypeScript module augmentation pattern, allowing users to extend the global context via declaration merging. The Biome lint warning can be safely ignored—empty interfaces are the idiomatic approach for this use case.

---

30-42: Perfect! I now have enough information to verify the review comment. Let me check one more thing about how the interceptor is actually called to ensure the any typing is truly necessary:

#!/bin/bash

Look at the actual implementation of how sendResponseInterceptors is called

sed -n '145,155p' packages/nest/src/implement.ts

Based on my investigation, I have verified all the necessary information:

Key Findings:

1. File context: packages/nest/src/implement.ts imports both Request, Response from 'express' and FastifyReply, FastifyRequest from 'fastify'
2. Actual usage (line 149): The interceptor receives { request: req, response: res, standardResponse: result.response } where req and res are the actual Nest.js handler parameters
3. Platform agnosticity: The module is designed to support multiple HTTP platforms (Express, Fastify)
4. Nest.js pattern: @nestjs/common provides Req and Res decorators but does not export a single typed Request/Response interface because it's platform-agnostic

Conclusion: The any typing is intentional and justified. Nest.js handlers work with platform-specific request/response objects (Express.Request vs Fastify.Request), and there is no single type that covers both. Using any is the pragmatic and correct approach for framework-agnostic module configuration.

---

The any types for request and response in sendResponseInterceptors are justified and necessary for Nest.js platform agnosticity.

The module intentionally supports multiple HTTP platforms (Express and Fastify), which have incompatible Request/Response types. Nest.js does not provide a unified type abstraction for these, so any is the appropriate choice here. No changes needed.

Reviewing files that changed from the base of the PR and between f58dd47 and 0ec130a.

• apps/content/docs/openapi/integrations/implement-contract-in-nest.md (3 hunks)
• playgrounds/nest/src/app.module.ts (1 hunks)

• GitHub Check: publish-commit
• GitHub Check: lint
• GitHub Check: test
• GitHub Check: Cloudflare Pages

apps/content/docs/openapi/integrations/implement-contract-in-nest.md (1)

223-236: LGTM!

All necessary imports are present, and the module augmentation correctly extends ORPCGlobalContext with type-safe request property. This addresses previous review comments about missing imports.