Inferring Hono Env from Middleware Chain Instead of createFactory<Env> — Is It Possible?

[lubiah]

Hey everyone 👋

I’ve been exploring Hono’s createFactory<Env> pattern for building modular apps, and I’m wondering about the design choice of requiring the Env type to be manually declared upfront.

It feels like there might be a more “dynamic” approach by inferring the Env from the middleware chain instead. For example, something along these lines:

Create the app via createFactory().createApp()

Attach middleware using .use(...)

Then infer the final Env type from the resulting app instance using something like:

type AppInstance = ReturnType<typeof factory>;

type Env = AppInstance extends Hono<infer E, any, any> ? E : never;

// Especially since middleware can already declare their own Env extensions, e.g.:

const middleware = () =>
  createMiddleware<{
    Variables: {
      user: User;
    };
  }>(async (c, next) => {
    const session = await auth.api.getSession({ headers: c.req.raw.headers });
    if (!session) throw new APIError("UNAUTHORIZED");
    c.set("user", session.user);
    await next();
  });

So in theory, the Env could be “built up” from all attached middleware rather than declared upfront.

My questions are:

Is there a technical limitation in TypeScript that prevents Env from being inferred this way across chained .use() calls?

Is this primarily a design decision in Hono for explicitness and safety?

Has anyone experimented with a type-safe “Env accumulation” pattern or wrapper around Hono that achieves this?

Would love to understand the tradeoffs here 🙏

[Andrew1326]

Good question — this is fundamentally a TypeScript limitation, not just a Hono design choice.

Why TypeScript can't infer Env from .use() chains

The core issue is that TypeScript's type inference doesn't accumulate across chained method calls the way you'd need it to. Each .use() call returns a new type, but TypeScript resolves the return type of each call independently — it doesn't "remember" what previous .use() calls contributed.

Here's the specific problem:

// What you'd want:
const app = new Hono()
  .use(authMiddleware)    // adds { Variables: { user: User } }
  .use(dbMiddleware)      // adds { Variables: { db: Database } }
  .get('/', (c) => {
    c.get('user')  // should know about User
    c.get('db')    // should know about Database
  })

For this to work, each .use() would need to return Hono<PreviousEnv & NewMiddlewareEnv> — an intersection that grows with each call. This is technically possible in TypeScript (tRPC's .middleware() chain does something similar), but it requires:

1. Each method must return a new, more specific type — not this
2. The generic must propagate through every subsequent method in the chain

Hono's .use() currently returns Hono<E, ...> with the same E — it doesn't widen the type. This is a deliberate tradeoff for simplicity and compile performance.

What actually works today

Hono does infer Env within route-specific middleware chains:

// This DOES work — Env is inferred per-route
app.get(
  '/protected',
  authMiddleware,  // declares Variables: { user: User }
  (c) => {
    const user = c.get('user') // ✅ TypeScript knows about user
    return c.json({ user })
  }
)

When you pass middleware directly to the route handler, Hono's type system merges the middleware's Env with the route handler's context. This is the intended pattern.

Why createFactory<Env> exists

It's the pragmatic solution to the accumulation problem:

// Declare the "full" Env once, use it everywhere
type AppEnv = {
  Bindings: { DATABASE_URL: string }
  Variables: { user: User; db: Database }
}

const factory = createFactory<AppEnv>()
const app = factory.createApp()

// All routes get full type safety
app.get('/', (c) => {
  c.get('user')  // ✅
  c.get('db')    // ✅
})

This is similar to how Express has declare global { namespace Express { interface Request { user: User } } } — you declare the shape upfront because the framework can't infer it from runtime middleware registration.

Has anyone built an accumulation pattern?

tRPC achieves this with its procedure.use(middleware).use(middleware2) chain, but it works because each .use() returns a new builder type (ProcedureBuilder<MergedContext>) — not this. It's a builder pattern specifically designed for type accumulation.

Building something similar for Hono would mean creating a wrapper that returns progressively wider types:

// Hypothetical — doesn't exist today
class TypedHono<E extends Env> {
  use<M extends MiddlewareHandler>(mw: M): TypedHono<E & InferMiddlewareEnv<M>> {
    this.app.use(mw)
    return this as any // the cast is unavoidable
  }
}

It's doable but involves as any casts internally and adds complexity. For most apps, createFactory<Env> with a single type declaration is simpler and more maintainable.

TL;DR: It's a TypeScript limitation — chained .use() calls can't accumulate generic types without returning new builder instances (like tRPC does). createFactory<Env> is the recommended workaround, and per-route middleware inference already works for route-specific context.

[lubiah]

Hello @Andrew1326 , thanks for your response.
In fact, this example works as expected

// What you'd want:
const app = new Hono()
  .use(authMiddleware)    // adds { Variables: { user: User } }
  .use(dbMiddleware)      // adds { Variables: { db: Database } }
  .get('/', (c) => {
    c.get('user')  // should know about User
    c.get('db')    // should know about Database
  })

the context knows about autth and db

[Andrew1326]

You're right, thanks for the correction! I was wrong about the chained .use() case — Hono does accumulate the Env types across .use() calls when they're chained on the same instance. That's actually really nice and means Hono's type system is more capable than I gave it credit for.

So to clarify: the inference does work when everything is chained in a single expression. The limitation would only show up in more dynamic scenarios — like when you attach middleware conditionally or across different files where the type can't flow through the chain.

Good to know Hono handles this well out of the box!

[lubiah]

I don't understand why they don't show this possibility in the docs,

[Rick1330]

The Trade-offs of "Env Accumulation" in Hono

This is a fascinating architectural question! You've correctly identified that Hono's createFactory<Env> pattern is "explicit-first," and you're wondering if we can pivot to an "inference-first" model.

The Technical Limitation (The "Circular Type" Problem):
In TypeScript, once you instantiate const app = new Hono(), its generic Env is "locked" to either what you provided or the default BlankEnv. While .use() can extend the internal state of the application, it cannot "reach back" and mutate the type of the app instance itself without creating a deep chain of ReturnType nesting.

If we tried to infer Env from the .use() chain, every call to .use() would have to return a new instance of Hono with an updated generic:
const appWithAuth = app.use(authMiddleware) // returns Hono<Env & AuthEnv>

Why the Factory Pattern is Preferred:

1. Circular References: Many middlewares need to access the Env to know what variables they provide or require. If the Env is inferred from the middleware, you create a circular type dependency that TS often baulks at.
2. Explicit Contract: In large apps, having the Env declared upfront serves as a "Source of Truth" for what is available in the Context. It prevents the "Mystery Meat" variable problem where you're unsure where c.get('user') was originally set.
3. Performance: Chaining generic inferences across 20+ middleware calls can significantly slow down the TS compiler, leading to slow IDE autocompletion.

How to achieve "Better" Inference:

If you want to avoid redeclaring types, the best approach is to define your Variables in a shared type and use it in your factories:

type MyVariables = { user: User } & { logger: Logger };
type MyEnv = { Variables: MyVariables };

const factory = createFactory<MyEnv>();

Is it possible?

Theoretically, yes, via a Builder Pattern wrapper, but it adds a lot of "Type Gymnastics" that might make the code harder for others to read. Hono prioritizes a balance of "zero-dependency" and "straightforward types."

If this helps clarify the design decisions behind Hono's Env system, please mark it as the answer!