Compile hono end-to-end via perry.compilePackages #421

Tracking issue for landing hono (https://github.com/honojs/hono) as a perry.compilePackages target.

Surfaced from a Medusa-vs-Perry compatibility study. Takeaway: a faithful express shim is a tarpit — Express's value is the prototype-mutation contract that ~200 widely-used middlewares depend on, which is fundamentally AOT-hostile. Hono is the modern, actively-maintained, AOT-friendly Express-shaped framework — same design lineage as Drizzle, built for Workers/Bun/Deno and the same constraints Perry has.

Why Hono (vs. an Express shim)

• Express-shaped API — app.get('/', c => c.json({...})) is instantly familiar to Express users.
• No prototype mutation — Express extends req/res prototypes at boot; Hono's Context is a plain object built per request. AOT-natural.
• No req.app circularity — clean dependency direction, no runtime metaprogramming required.
• Trie-based router — fast, no runtime regex compilation.
• Middleware contract is a clean async function (c, next) => {...} — composes statically, no side-effects-on-shared-prototypes.
• Built for portable runtimes from day one — Workers, Bun, Deno, Node, edge. Same constraint set as Perry.
• Growing fast — 20K+ stars, increasingly the default for new TS backends.

Perry already ships fastify in perry-stdlib. Hono complements it: Fastify is the higher-throughput plugin-driven choice; Hono is the lighter Express-shaped choice with the strongest edge-runtime fit. The two together cover most of the modern TS backend space. A full Express shim is explicitly out of scope (see below).

Scope

End-to-end means: user does npm install hono, adds "compilePackages": ["hono"] to package.json, writes a standard Hono program with routing + a couple middleware + JSON request/response, runs perry compile app.ts -o app && ./app, and gets a single-file native binary serving HTTP.

Likely shake-out areas:

1. hono source compilation — pure TS, no native bindings. Designed for portable runtimes, so most should compile out of the box. Standard compilePackages shake-out for any TS-subset features individual modules trip over (same shape as Compile ink (React-based TUI framework) end-to-end via perry.compilePackages #348).
2. Adapter — Hono uses runtime adapters (@hono/node-server, Bun adapter, Deno adapter, Workers adapter). Perry needs a server adapter that hands the listening socket / request stream to Hono's app.fetch. Most natural: build on top of Perry's existing http / fastify plumbing in perry-stdlib to provide a @hono/perry-server shape.
3. Middleware ecosystem — Hono ships official middlewares (hono/cors, hono/jwt, hono/logger, etc.) under its own namespace, all pure TS. These should fall out of (1) for free.
4. Web Standards APIs Hono leans on — Request/Response/Headers/URL/URLSearchParams. Verify Perry's coverage matches what Hono uses; gaps land here as sub-issues.

Acceptance

• A 30-line Hono program (routing + JSON request/response + one middleware — e.g. a logger or a basic auth header check) compiles via perry compile, produces a single-file native binary, serves real HTTP traffic, and matches the same program under node --experimental-strip-types byte-for-byte for response bodies/headers.
• At least one official Hono middleware (hono/cors or hono/logger) verified end-to-end.
• Whatever shake-out fixes are needed in perry-codegen / perry-stdlib to make the dependency tree compile cleanly, land them under this umbrella.
• A @hono/perry-server-shaped adapter exists, either inside perry-stdlib or as a separate package, and is documented.

Out of scope (separate follow-ups)

• A full Express compatibility shim. Express's middleware ecosystem assumes prototype mutation; faithful support is ~20kloc of Rust to track upstream forever, and a partial shim is worse than no shim ("Express-but-not-really" is confusing). The express story becomes "use Hono or Fastify; here's a migration guide."
• A minimal Express subset module (app.get/use/listen + req.params/query/body + res.json/send/status only, scoped to tutorial-grade apps) is possibly worth a separate small issue, only if real demand emerges. Default position: skip.
• Elysia / itty-router / other small frameworks — separate tracking issues if/when demand materializes.

Strategic context

Companion to a Drizzle compilePackages tracking issue (filed alongside this one). Together they cover the modern AOT-friendly TS backend stack — the same selection Workers/Bun/Deno users have converged on for the same reasons Perry has. The thesis is: align with the modern-edge-TS lineage (Hono/Drizzle/Zod/Valibot) rather than chasing legacy-Node compat (Express/MikroORM/Awilix/NestJS).