hono-openapi derives an OpenAPI document from a Hono app's schemas

One specification, derived from the schemas you already have

hono-openapi is Hono middleware to generate OpenAPI Swagger documentation, and the mechanism is what makes it interesting.

The library can automatically generate the OpenAPI specification for the Hono app using your validation schema. The schema is not decoration that you maintain next to the routes. It is the same object the runtime already uses to validate the request, and the specification is derived from it.

The consequence is that the API description and the API behaviour come from one place. A change to a request schema changes the published specification, and there is no second copy to forget. The README's stated use for the output is generating client libraries, documentation and more, which is the usual reason to want a specification at all.

The package is published on npm as hono-openapi, its homepage is the Hono Hub documentation at honohub.dev/docs/openapi, the licence is MIT, and the version in the repository is 1.5.0.

The audience is therefore a specific kind of Hono developer: one who has a running app, validates its input with one of the popular schema libraries, and needs a machine readable contract for a frontend team, a partner or a public API directory.

Standard Schema is the integration point, not any one validator

The line in the README that decides the design is that this lib supports all the validation libs which are Standard Schema compliant.

That is a bigger claim than it first appears. Rather than implementing a converter per validation library, the package targets the Standard Schema interface, and the runtime dependencies reflect that. There is @standard-schema/spec, the specification itself, @standard-community/standard-openapi, which is the OpenAPI mapping layer, @standard-community/standard-json, and @hono/standard-validator, which is the Hono adapter for the Standard Schema validators. The remaining dependencies are @types/json-schema and openapi-types, which is the TypeScript type package for the OpenAPI document.

The npm keywords name the validators the project expects to see in use: zod, valibot, typebox, arktype and effect. The development dependencies show them being tested against: @valibot/to-json-schema for the Valibot side, arktype, effect, typebox, sury, which is a Zod alternative, and valibot itself. The test extra in the package metadata adds pytest style tooling rather than a validator, but the dev dependencies are where the matrix lives.

The practical effect is that switching validator does not mean switching documentation tooling, and adding a second validator to a codebase does not mean a second OpenAPI pipeline. That is the real payoff of the Standard Schema route, and it is why the dependency list is short.

A small package built on a small set of community dependencies

The dependency list is worth reading on its own, because it shows how little of the machinery this package owns.

  "dependencies": {
    "@hono/standard-validator": "^0.4.0",
    "@standard-community/standard-json": "^0.3.7",
    "@standard-community/standard-openapi": "^0.2.11",
    "@standard-schema/spec": "^1.0.0",
    "@types/json-schema": "^7.0.15",
    "openapi-types": "^12.1.3"
  },
  "peerDependencies": {
    "hono": "^4.11.2"
  }

Six runtime dependencies and one peer dependency, and the peer dependency is Hono itself at 4.11.2 or later. The package does not bundle a validator and does not bundle the framework, which is what lets it stay out of the way of whatever the application already chose.

The packaging is modern and deliberate. The package is an ES module by type, with a CommonJS build as well: the main field points at dist/index.cjs and the module field at dist/index.js, and the exports map gives a require entry with its own .d.cts types alongside the import entry. The published files list contains only dist, and the publish configuration sets access to public.

The build itself is pkgroll, and the scripts section is short: build runs pkgroll with a clean dist, lint runs biome check, format runs biome check with write, test runs vitest, and prepare runs is-ci or husky. The repository uses Biome for linting and formatting, vitest for tests, husky for git hooks with nano-staged, and it has a separate tsconfig.typecheck.json and a vitest.config.ts.

Where the design came from, and who did the hard part

The credits section is unusually specific, and it explains a lot about the shape of the project.

The idea was inspired by ElysiaJS and their work on generating OpenAPI specifications, and the README links their OpenAPI pattern documentation. The lineage is easy to follow: ElysiaJS is a TypeScript web framework whose selling point is that a route's types and its runtime validation are the same object, and a specification generated from those types is therefore always in step with the server.

The second credit is more specific. The project would not have been possible without the work of Sam Chung and his Zod OpenAPI package. So the OpenAPI generation logic in the Zod case comes from that package, and the Standard Schema and multi-validator support is the part this project added on top.

That is worth knowing before you evaluate the output quality. The mapping from a schema to an OpenAPI fragment is the hard part of the problem, and for at least one validator it is inherited rather than written here. For the other validators, the mapping runs through the community standard-openapi package, which means the fidelity of the generated document for a given validator depends on that package's coverage.

The repository layout supports a project that takes quality seriously for a small package: a src directory, a CHANGELOG.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a SECURITY.md, an AGENTS.md, a .lore.md, a .craft.yml for release tooling, and a pkg-pr-new dependency that produces preview releases for every pull request.

Documentation lives on Hono Hub, not in the README

The README for this package is short, and the reason is stated in it: for documentation visit honohub.dev.

What the repository's own README does give you is the promise, the compatibility claim, the credits and the contribution route, which points at a contributing document in the repository. The usage guide, the API reference and the guides live on the Hono Hub documentation site, and the homepage field in the package metadata points at the same place.

That is the normal arrangement for an ecosystem extension, and it has one practical consequence. The README contains no worked example, no route definition and no middleware registration snippet, so the source of truth for how to wire this into an app is on the site rather than in the repository. If you are evaluating the project from the repository alone, you are evaluating the dependency set and the compatibility claim rather than the API.

The repository does contain a deepwiki badge, which points at a generated wiki of the codebase, which is a reasonable way to get a picture of the source if the site documentation is not what you need.

The release cadence is fast. The recent versions are 1.3.5 on 2026-10-07, 1.4.0 on 2026-10-18 and 1.5.0 on 2026-10-18, and the last push was on 2026-10-18. Two releases on one day is a strong signal that the API is still moving, and the README's own note says the package is still in development and that feedback is welcome through GitHub issues.

Where hono-openapi is the wrong tool

The limits follow from the mechanism, and they are worth stating before anyone writes a client against the output.

First, you need validation schemas. The specification is generated from your validation schema, so an app that validates nothing, or that validates with hand-written middleware, gets nothing from this package. The middleware sits on top of a schema-first design rather than replacing it.

Second, the output is only as good as the Standard Schema to OpenAPI mapping. For Zod the mapping comes from an existing package, and for the other validators it comes from the community standard-openapi package. A schema feature with no OpenAPI equivalent, or a validator whose mapping coverage is incomplete, will produce a document that is thinner than the API. There is no list in the README of what is and is not representable.

Third, the package is a Hono extension, not a general one. The peer dependency on hono 4.11.2 or later means it only applies to Hono applications, and a team running Express, Fastify or a plain Node server gets no benefit from it.

Fourth, and this is the one to weigh for a public contract, the package says in plain terms that it is still in development, and it published two minor versions on 2026-10-18. A specification that is regenerated from schemas can change shape between versions in a way that a hand-maintained contract would not, so if you publish an API for third parties, treat the generated document as an artefact to version and review rather than as something to expose directly from the running service.

Editorial conclusion

Hono teams that already validate requests with a Standard Schema library should adopt hono-openapi, because the specification is derived from schemas that exist anyway rather than from a second description of the same routes, and the output is directly usable for client generation and documentation. It is the wrong tool if your app has no validation schemas, since the specification is generated from them, and it is the wrong tool if you need a stable contract across a long-lived public API, because the package states that it is still in development. Before adopting, read the documentation on honohub.dev rather than the README, check that your Hono version satisfies the peer dependency on hono 4.11.2 or later, and look at the changelog because 1.4.0 and 1.5.0 were published on the same day.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rhinobase/hono-openapi on GitHub