Hono 4.13.10 moves its runtime adapters into separate packages
Victoria Shinder1 min readHono, the small web framework that runs across JavaScript runtimes, has moved its runtime adapters out of the core package. According to the release notes for version 4.13.10, published on 28 September, the adapters are now separate packages: @hono/bun, @hono/deno, @hono/cloudflare-workers, @hono/aws-lambda, @hono/lambda-edge, @hono/netlify, @hono/vercel and @hono/service-worker. The Deno adapter is also published on JSR, the JavaScript registry.
For applications the change is an import path. Code that imports an adapter helper from hono/bun, for example serveStatic, now imports it from @hono/bun instead. The old hono/adapter paths keep working throughout version 4 but are deprecated and will be removed in version 5. One adapter has no successor: hono/cloudflare-pages is deprecated without a replacement package, and the notes point to Cloudflare's recommendation to use Workers with static assets instead.
The rest of the release is mostly tooling. The project moved its package manager from Bun to pnpm, replaced Prettier with oxfmt and ESLint with oxlint, upgraded Vitest to 5.0.1 and introduced Vite+ into its build. The Bun adapter ships as ESM only. Among user-facing fixes, the types now allow returning a Blob as a response body. A follow-up patch, 4.13.11, came out on 29 September.
What it means
Splitting adapters out lets each runtime integration be versioned and released on its own schedule, and keeps runtime-specific code out of the core that every user installs. The practical task for users is small but has a deadline: switch the import paths while v4 still accepts both, and plan a move off the Cloudflare Pages adapter, which will not have a package of its own.