Hono middleware: the @hono namespace for packages outside the core

A distribution point for middleware the core package cannot carry

honojs/middleware is a monorepo that holds Hono middleware written outside the core package and publishes it under the @hono scope on npm. The problem it solves is distribution, not invention. Hono core ships built-in middleware with no dependency on other external libraries, so anything that needs a third-party library, an unusual protocol or a specific platform integration has to live somewhere else. This repository is that somewhere else, and it is where issues and pull requests for those packages are managed. The audience is two groups: application developers who want a maintained package instead of writing their own, and authors who want their work carried under a familiar scope and installed with the same import shape as the framework itself.

Three kinds of middleware, split by dependency footprint

The project's own write-up splits middleware into three types, and the distinction is about dependency footprint rather than quality. Custom middleware is written by the user for their own application. Built-in middleware ships in the Hono core package and, by definition, does not depend on any other external libraries. Third-party middleware is created outside the core package and is allowed to depend on external libraries. That third category is what this monorepo hosts. A middleware named hello lives at packages/hello inside the repository and is distributed as @hono/hello, so the directory layout and the published package name correspond one to one. For a team deciding where to put code the rule is simple: if it needs a dependency, it does not belong in Hono core, and if it should be reusable beyond a single application, this monorepo is the venue the project offers.

Installing an @hono package on npm, and the different Deno route

Every package in the namespace installs the same way, and the documented example is a single command:

npm install @hono/hello

Deno is the exception. The packages are not published on deno.land/x, so the docs point to CDNs such as Skypack and esm.sh instead, and to the npm: specifier:

import { hello } from 'npm:@hono/hello'

The write-up notes that the npm: form will be introduced in Deno itself in the future, which means the CDN route is the current answer for Deno users and the import style there is not identical to the npm one. This is a small but real difference in what a user has to do, and it applies to every package in the scope, not to one package in particular. Anyone planning a Deno deployment should check that path first, because a package that installs cleanly under npm has to be reached differently there.

Acceptance is a discussion, and the author keeps the keys afterwards

Nobody can publish into the namespace unilaterally. The contribution guide describes a discussion first: the Hono maintainers and other contributors talk about whether a proposed middleware is accepted, and only then is it kept in this repository. The proposer becomes the author and stays responsible for it, responding to issues and reviewing pull requests related to that middleware as much as possible. Maintainers may nudge with an @ mention, for example @yusukebe Can you take a look? The concrete flow has three steps: clone the repository, write the middleware with the hello package as the reference, and open a pull request. That split of responsibility defines the model. Acceptance is a community decision, while upkeep after acceptance belongs to the author, which also means the response time you get for a bug in a given package depends on who wrote it and how active that person is.

Changesets, pnpm workspaces and turbo make the release path

Changes are described with changesets, and the command is run at the top level of the repository:

pnpm changeset

When a change is merged into main, a pull request for release is created, and the Hono maintainers merge it to publish the package at the appropriate time. Authors therefore do not publish by hand. The root package.json shows two publish paths, one for npm and one for the Deno registry, plus a matching version step:

{
  "publish": "pnpm publish:npm && pnpm publish:jsr",
  "publish:npm": "pnpm -r publish --no-git-checks && changeset tag",
  "publish:jsr": "deno install --no-lock && deno publish",
  "version": "pnpm version:npm && pnpm version:jsr"
}

The Deno branch of that pipeline is a deno publish, and a separate version:set script drives node scripts/version-set.ts. The repository itself is a pnpm workspace, with pnpm-lock.yaml at the root and turbo.json defining task runs, so a single build command covers every package in the tree.

Vitest inside each package, one toolchain for npm, Deno and Workers

Testing uses Vitest, and the placement rules are specific: test files go in the middleware's own src directory and must include .test. in the file name, for example index.test.ts. The command to run them from the middleware directory is:

pnpm test

The root package.json fills in the rest of the toolchain. The build scripts run tsdown, typecheck runs tsc --build, lint delegates to turbo with eslint, and format runs prettier --check. The devDependencies show what that toolchain has to satisfy, including @cloudflare/vitest-plugin and @cloudflare/workers-types so tests can run against Workers types, plus @arethetypeswrong/core for checking published type shapes and pkg-pr-new for preview publishing. The config files at the root, vitest.config.ts, tsconfig.base.json, tsdown.config.ts and deno.jsonc, confirm that one setup has to work for the npm package, the Deno release and the Cloudflare Workers runtime at the same time.

MIT at the root, but each package belongs to its own author

The licence story has a wrinkle that is easy to miss. The project separates two things: the repository as a whole is MIT, and the root package.json declares it, while the code under packages/ belongs to each middleware author, with the author credited as the copyright holder. Packages are distributed under the MIT license by default, and the repository is authored by Yusuke Wada. The second wrinkle is the namespace itself. Publishing under @hono/ means a user installs anything in that scope with the same command shape, but the Hono maintainers say they merge release pull requests at the appropriate time rather than promising a fixed cadence, so a package's upkeep depends on its author. The release history shows that in practice, with @hono/ua-blocker 0.1.44 on 2026-10-16, @hono/inertia 0.8.1 on 2026-10-15 and a further ua-blocker release on 2026-10-04. The last push to the repository was on 2026-10-19.

Editorial conclusion

The honojs/middleware monorepo is worth adopting when you need Hono functionality that belongs outside the core package, want it published under the @hono scope, and can rely on a named author to answer issues. It is the wrong venue for a small local tweak, since acceptance is a public discussion and every release goes through maintainers, and it is the wrong choice when a dependency-free helper would do, because that belongs in Hono core. Verify three things first: that the package you want is published at the version you expect rather than a fork under another scope, that its own documentation states the runtime and the peers it needs, and that the install route for your runtime is covered, since Deno users get the CDN and npm: path rather than deno.land/x. The last push was on 2026-10-19 and releases ship through changesets, so track the individual package version rather than the repository.

Frequently asked questions

Official sources

1. honojs/middleware on GitHub
2. License: MIT
3. Project website
4. README
5. Releases