exceeds the maximum length error caused by middleware

[inducingchaos]

I know this is expected, and probably just something to deal with - but wanted to note it for future optimizations in oRPC v2.

Problem & Context

Okay first, the error:

error TS7
056: The inferred type of this node exc
eeds the maximum length the compiler wi
ll serialize. An explicit type annotati
on is needed.

And the relevant code (errors on appRouteFactory):

const publicRouteMiddleware = logError.concat(onError(logValidationError)).concat(checkVersion).concat(dbProvider)
const protectedRouteMiddleware = publicRouteMiddleware.concat(requireAuth)
const appRouteMiddleware = protectedRouteMiddleware.concat(appContextProvider)

export const publicRouteFactory = apiFactory.use(publicRouteMiddleware)
export const protectedRouteFactory = apiFactory.use(protectedRouteMiddleware)
export const appRouteFactory = apiFactory.use(appRouteMiddleware)

Where apiFactory is just the implemented contract:

export const apiFactory = implement(contract).$context<APIContext>()

A glimpse of the context definitions:

export type APIRequestContext = { request: { headers: Headers } }
export type APIDatabaseContext = { db: Database } // typeof drizzle(...)
export type APIAuthContext = { auth: AuthContext } // typeof betterAuth(...).$Infer.Session
export type APIAppContext = { app: AppContext } // { selectedBrainId: string }

export type APIInitialContext = APIRequestContext
export type APIContext = APIInitialContext & Partial<APIDatabaseContext & APIAuthContext & APIAppContext>

export type PublicRouteFactoryContext = APIDatabaseContext
export type ProtectedRouteFactoryContext = PublicRouteFactoryContext & APIAuthContext
export type AppRouteFactoryContext = ProtectedRouteFactoryContext & APIAppContext

The contract is still very lightweight:

export const contract = {
    thoughts: thoughtsContract, // ~5 CRUD operations, input/output validation with ArkType, IO types are ~5 basic properties
    experimental: experimentalContract // Really nothing
}

And the seemingly most problematic part, appContextProvider (note the use of $context):

export const appContextProvider = apiFactory.$context<APIDatabaseContext & APIAuthContext>().middleware(async ({ context, next }) => {
    const selectedBrainId = await getSelectedBrainId({ userId: context.auth.user.id, db: context.db })

    if (!selectedBrainId) throw new ORPCError("NOT_FOUND", { message: "No selectable Brain found. This edge case should be handled by always creating a Brain during the onboarding flow, and enforcing the creation of a new one if it is deleted." })

    return next({
        context: {
            app: {
                selectedBrainId
            }
        }
    })
})

What I've Read/Tried

• https://orpc.dev/docs/advanced/exceeds-the-maximum-length-problem

  • Option 1: Not ideal for a monorepo with multiple packages/apps
  • Option 2: Done in contract
  • Option 3: Not sure how to properly split contract, doesn't matter anyways because context is the issue

• Read thread https://discord.com/channels/1308966753044398161/1404009710088359957

• And thread https://discord.com/channels/1308966753044398161/1399616334760775710

• And thread https://discord.com/channels/1308966753044398161/1345370986303848499

• Upgraded all packages and apps to Typescript 5.9.3

What Works For Now

Passing the AppRouteFactoryContext aggregate type directly to the use call:

export const appRouteFactory = apiFactory.use<AppRouteFactoryContext>(appRouteMiddleware)

However, none of the fixes for the "exceeds the maximum length" error seem to be a truly permanent fix. Maybe I don't understand Typescript quite well enough, but splitting up the router and reconstructing it in multiple places doesn't seem optimal to me, and could introduce inconsistencies.

1. Is there any way to fundamentally avoid this, or maybe a mental frame for preventing it?

2. How might one split up the router contract (maybe it's not needed because the middleware was most of the problem here, but in the future if the overall "length" needed to be reduced)?

3. What if the procedures of each router start exceeding the length limit, and it's not optimal to split them into separate routers?

Apologies if any of these questions are irrelevant, I'm just trying to think ahead if this is going to be an issue using oRPC long-term. Kind of hoping for a happy path here.

If I'm using the wrong pattern in any of these places please make a recommendation.

Thank you!

[dosubot[bot]]

There’s no fundamental way to avoid the TS7056 “exceeds the maximum length” error in TypeScript when using highly compositional patterns like oRPC’s middleware/context stacking—this is a TypeScript limitation, not an oRPC bug. The best way to prevent or manage it is to use explicit type annotations at key points (like your workaround with apiFactory.use<AppRouteFactoryContext>(...)), which helps TypeScript avoid deep inference and serialization issues ref.

For middleware, always use the dependent-context pattern: each middleware should only add the fields it is responsible for, and avoid spreading the entire context (i.e., don’t do { ...context, newField }). This keeps type growth manageable and avoids conflicts ref.

If router or procedure types start hitting the limit, split large routers into smaller ones and compose them, or move logic into separate modules with explicit types. You can also explicitly type your handlers using the ProcedureHandler type (or a custom utility) to localize type errors and keep complexity out of the router ref.

For monorepos, set "declaration": false in your app’s tsconfig.json and "declaration": true in packages, use TypeScript project references, and avoid alias imports to reduce type complexity ref.

Your current workaround and patterns are in line with best practices. If you keep explicit types at boundaries, use dependent-context in middleware, and modularize routers as they grow, you’ll avoid most headaches—even if it’s not a “forever” fix. There’s no “happy path” that avoids this entirely, but these strategies are what oRPC and tRPC maintainers recommend for long-term maintainability ref.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[inducingchaos]

Referenced discussion in Discord: https://discord.com/channels/1308966753044398161/1456795944321552558

[unnoq]

Because you are using contract-first approach so you only need reference: true in contract package, so please disable it in implement package to avoid this issue.

[inducingchaos]

I'm sorry I looked around, and I'm not sure what you mean by reference: true.

Is this a config value on implement or contract somewhere, or are you referring to TypeScript Project References?

[unnoq]

Option 1 for implement package, because orpc client only need contract

[inducingchaos]

Okay maybe I'm crazy but I looked everywhere for this

• https://github.com/search?q=repo%3Aunnoq%2Forpc+%22reference%3A%22&type=code (no results)
• https://github.com/search?q=repo%3Aunnoq%2Forpc+implement+reference&type=code (went through all results, nothing relevant)
• https://github.com/search?q=repo%3Aunnoq%2Forpc+%22reference%22&type=code (also nothing relevant)

Nothing matching reference: true in the codebase. Could you be a bit more clear, or point me to what you're talking about?

[unnoq]

I mean this: https://orpc.dev/docs/advanced/exceeds-the-maximum-length-problem#_1-disable-declaration-true-in-tsconfig-json