middleware

Which middleware is the feature for? @hono/zod-openapi What is the feature you are proposing? & - Design Documentation Acknowledgement Before diving into the proposal, I want to express my appreciation for the Hono framework and the middleware. It has been a game-changer for building type-safe APIs, and I really value the work the maintainers have put into this ecosystem. Thanks for providing such a solid foundation! Problems Before Introduction 1. Repetitive Route Registration Before , each route had to be registered individually using the method: This approach led to: Verbose, repetitive code Difficult maintenance when dealing with many routes Poor code organization and readability 2. Type Inference Challenges When routes were defined inline or without proper type constraints, TypeScript struggled with: Inferring the correct handler signature from the route configuration Maintaining type safety across route definitions and handlers Providing accurate autocomplete for request/response types 3. Modular Route Organization Issues Organizing routes across multiple files was challenging: Routes had to be imported and registered one by one Type safety for RPC (Remote Procedure Call) support was difficult to maintain Schema merging for the entire API was fragmented 4. Conditional Route Registration No built-in way to conditionally include/exclude routes: Feature flags or environment-based route registration required custom logic Had to use conditional statements scattered throughout the codebase 5. RPC Type Safety Limitations When routes were registered individually across different parts of the application: The cumulative schema type () was harder to track RPC client type generation was less reliable Type inference for chained route registrations was complex How These Features Solve The Issues Solution Purpose: Provides a type-safe wrapper for route definitions with explicit type annotations. Benefits: 1. Explicit Type Safety: Ensures route configuration, handler, and hook are correctly typed 2. Portable Definitions: Routes can be defined in separate files and imported 3. Conditional Registration: The parameter allows fine-grained control 4. Better IntelliSense: IDEs can provide better autocomplete and type checking 5. Documentation: Serves as a clear contract between route definition and implementation Solution Purpose: Batch registration of multiple routes with full type safety and schema merging. Benefits: 1. Batch Registration: Register multiple routes in a single call 2. Type-Safe Schema Merging: Uses recursive type to merge all route schemas correctly 3. Maintained RPC Support: Full type inference for RPC clients across all registered routes 4. Cleaner Code: Reduces boilerplate significantly 5. Modular Organization: Routes can be grouped logically and imported from different files 6. Conditional Routes: Respects the flag from each route definition Intended Use Basic Usage Pattern Modular Organization Pattern Conditional Routes Pattern With Middleware Pattern Key Design Decisions 1. Requirement The array must be defined as or inline to preserve tuple types. This is necessary for: Accurate type inference for each individual route Proper schema merging using recursive conditional types RPC client type generation 2. Flag The optional parameter provides: Declarative conditional registration Route configuration and business logic in one place Cleaner alternative to wrapping routes in conditional statements 3. Type-Only The function is essentially a type identity function - it returns the input unchanged: Its primary purpose is to provide explicit type annotations and improve developer experience. 4. Backward Compatibility Both features are additive and don't break existing code: method still works as before Routes can be mixed: some registered with , others with No migration required for existing applications Summary These features enable scalable, type-safe, and maintainable OpenAPI route management in Hono applications.