# tinyhttp: three packages released nine seconds apart, and a Node floor that disagrees with its own manifest

> An Express-like web framework written in TypeScript and shipped as native ESM with no polyfills, organised as a pnpm workspace whose packages are versioned and released individually through changesets. Its README states a Node floor of 16 while the monorepo manifest allows 14.21.3, its install instructions only cover one package manager, and its release script asks for provenance attestations while skipping git state checks.

**tinyhttp/tinyhttp** — 🦄 0-legacy, tiny & fast web framework as a replacement of Express

- Repository: https://github.com/tinyhttp/tinyhttp
- Website: https://tinyhttp.v1rtl.site
- Stars: 2,904 · Forks: 156
- Language: TypeScript
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/tinyhttp-tinyhttp

## Three packages released nine seconds apart

There is no repository-level release. The three newest releases are scoped packages rather than one version of the framework: a response library at 2.2.15, a JSONP package at 2.1.27, and a cookie signature package at 2.1.2. All three were published on 2026-08-10 within nine seconds of each other, at 12:55:07, 12:55:13 and 12:55:16. That pattern is a single publish sweep across the workspace rather than three independent releases, and it is the visible consequence of versioning each package on its own. For a consumer it means the framework and its middleware move independently: installing the application package today and reinstalling a month later can pick up a new patch of one middleware without the framework version changing at all.

## The Node floor is 16 in the README and 14.21.3 in the manifest

The install section says Node.js 16 or newer is required and links a compatibility chart keyed to that language level. The monorepo manifest says something different: its engines field asks for Node 14.21.3 or newer and pnpm 8 or newer. Two releases of Node apart, in the same repository, describing the same packages. The manifest also pins the package manager itself to a specific pnpm release in a separate field, which is a stricter statement than the engine range next to it. Neither number is more authoritative on its face, since the engines field governs the workspace root rather than each published package, and this repository is a private workspace manifest at version 0.0.1. The practical advice is to test the oldest Node you intend to run rather than to pick a number out of the README.

## Express middleware compatibility, ESM only, and no polyfills

The install command is one line:

```sh
pnpm i @tinyhttp/app
```

The feature list is seven items and three of them are about what the framework refuses to do. It is marked as ESM only, it ships no legacy compatibility and no polyfills it calls useless, and it depends on no polyfills or other compatibility layers at all. It targets recent Node versions and is compiled to native ESM. What it does keep is Express middleware compatibility, plus async error handling support, types out of the box, and middlewares for common tasks. The distinction matters: an Express middleware that is written against the Express API can run here, while a module written for CommonJS cannot be imported without a build step. The framework advertises three times fewer dependencies than Express version 5 as its headline, without publishing the counts behind that number.

## The publish step asks for provenance and skips git checks

The release script is one line and it contains two choices worth reading separately. The recursive publish is run with public access, with provenance enabled and with git checks disabled, followed by a changeset tagging step. Provenance is the good half: it asks the registry to attest that the published artefact was built by a specific workflow, which is the mechanism that makes a supply chain claim checkable rather than merely asserted. Disabling git checks is the other half, and it means the publish does not insist on a clean working tree or a particular branch, so a commit can be published from a dirty checkout. Both settings are defensible in a monorepo with many packages and a slow release queue. They are also a decision someone made deliberately, and anyone mirroring these packages should decide the same way consciously.

## Two coverage tools are installed and only one is wired up

The development dependencies include both the Vitest coverage provider and a standalone coverage tool, and the test script runs the Vitest coverage path. So the second tool is installed, unused by the default script, and available if a script is added later. It is the kind of leftover that costs a dependency install and no behaviour, and it is a small but reliable signal of what a repository has tried over time. The rest of the test setup is tidier: a tests directory at the root with a separate helpers directory, a Vitest configuration file, a development watch script, and a prerelease script that lints, builds and tests in that order before anything is published.

## Twenty six examples are the real integration surface

The examples directory is where this project documents itself. There are twenty six of them, and they are not all hello world. They cover the plain case and asynchronous error handling, response caching, a reverse proxy in front of a Caddy server, clustering, cookies, CSRF, a custom view layer, two template engines, Elasticsearch, file upload, a serverless deployment target, GraphQL, HTTP/2, TLS, JSON web tokens, four database and ORM combinations, a no-match handler, and two Prisma based examples. Each one is a working application rather than a snippet, which means the framework's compatibility surface is demonstrated by code that has to run. The no-match handler example in particular implies that catch-all routing is a first class concern, which is exactly the kind of thing middleware libraries usually leave to the user.

## Biome, changesets and commitlint replace the usual lint pipeline

The tooling tells you what the maintainer considers worth the maintenance. Formatting and linting are both done by one tool, with separate commands for lint, format and a combined check, and the version step runs that combined check in write mode so a version bump also formats the tree. Releases are driven by a changeset workflow with three scripts: one to run the tool, one to version and reinstall, and one that chains them. Commit messages are validated by commitlint with the conventional configuration, wired through a husky configuration file. Shared dependency versions use the package manager's catalog mechanism rather than repeated ranges. Two other files at the root are worth naming: a comparison document, which for an Express replacement is the most load bearing page in the repository, and an agent instruction file.

## Conclusion

tinyhttp fits a TypeScript service already on ESM that wants Express-shaped middleware without the compatibility layers, and it does not fit a CommonJS codebase or anyone who needs the framework and its middleware to version together. Four things to check. The module format is ESM only, so a CommonJS build cannot consume it. The declared Node floor is inconsistent between the README and the monorepo manifest, so test on the version you actually deploy. Releases happen per package through changesets, which means your dependency tree can pick up a new middleware version without the framework changing. And the publish command requests provenance attestations while skipping git state checks, which is a deliberate trade worth being comfortable with if you mirror these packages internally.

## FAQ

### What is tinyhttp?

A modern Express-like web framework written in TypeScript and compiled to native ESM, with Express middleware compatibility, async error handling support and types included. It ships no polyfills or other compatibility layers and advertises three times fewer dependencies than Express version 5.

### How do I install tinyhttp?

The install command given is pnpm i @tinyhttp/app, so the documentation assumes pnpm. The README says Node.js 16 or newer is required, while the monorepo manifest separately declares engines of Node 14.21.3 or newer and pnpm 8 or newer, and pins the package manager to a specific pnpm release.

### Is tinyhttp compatible with CommonJS?

No. It is listed as ESM only, described as compiled to native ESM, and stated to depend on no polyfills or compatibility layers. Express compatibility in the feature list means API and middleware compatibility rather than support for the CommonJS module format.

### How are tinyhttp packages released?

Per package rather than as one repository release. The three newest releases are the response package, the JSONP package and the cookie signature package, all published on 2026-08-10 within nine seconds of each other. The release script publishes recursively with provenance attestations and with git state checks disabled, then applies a changeset tag.

### What does the tinyhttp monorepo contain?

A pnpm workspace with a packages directory, twenty six example applications covering databases, template engines, JSON web tokens, CSRF, GraphQL, HTTP/2, TLS, clustering, caching and serverless deployment, a comparison document, a changeset configuration, biome for linting and formatting, commitlint with husky, and both a Vitest coverage provider and a standalone coverage tool in the development dependencies.

### How does tinyhttp run its tests?

Through Vitest, with a coverage script and a development watch script over a tests directory that has its own helpers directory. The default test script runs the coverage path, and a prerelease script lints, builds and tests in that order before anything is published. A fetch based testing library and a template engine are both in the development dependencies.

## Sources

- [License: MIT](https://github.com/tinyhttp/tinyhttp/blob/master/LICENSE)
- [Project website](https://tinyhttp.v1rtl.site)
- [README](https://github.com/tinyhttp/tinyhttp/blob/master/README.md)
- [Releases](https://github.com/tinyhttp/tinyhttp/releases)
- [tinyhttp/tinyhttp on GitHub](https://github.com/tinyhttp/tinyhttp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tinyhttp-tinyhttp