nestia moves request validation into the type system and publishes on three channels

The pitch is that validation stops being a runtime concern

The headline note on the page is a single line, and everything else follows from it: only one line is required, with a pure TypeScript type.

The architectural claim is that if a value's type is declared once and the compiler enforces it, the runtime validator and the client's type are the same fact rather than two descriptions that drift. So a route parameter annotated with a typed decorator produces both the server-side check and the client-side type.

Performance is the supporting argument, and it is stated with three multiples: a general speedup claim, a runtime validator said to be twenty thousand times faster than a named competing decorator-based validator, and JSON serialization said to be two hundred times faster than a named competing transformer.

Two things about how those numbers are presented are worth noting. They are the author's own measurements rather than independent ones, and the benchmark results are linked to a specific machine, an eleventh-generation mobile processor at a stated clock speed, which tells you the hardware the comparison was made on.

The direction of the result is believable regardless. Removing runtime schema validation does remove work. The magnitude is what you should treat as the author's claim.

Eight decorators cover the whole request surface

The core library is a small set of decorators, and seven of the eight do the same job in different places.

There is a route decorator for ordinary endpoints and a separate one for WebSocket routes, which is the interesting asymmetry because socket routes do not have the request object the others parse from. Then come typed decorators for the body, route parameters, query string, form data and headers.

The eighth is different in kind: a typed exception decorator types the error response rather than anything the client sent. That is the one that changes server design rather than just removing a parse step, because it makes the error shape part of the declared interface.

So the set is a complete replacement for the usual stack of a runtime validator plus a serializer plus hand-maintained client types. What you give up is the ability to accept a shape the compiler cannot express, which is the real trade: you cannot validate a body whose type depends on runtime data without escaping to something untyped.

One readme is copied into every package before publish

The publish pipeline has a step that is easy to miss and explains why a monorepo of nine packages can share one document.

The prepare step builds everything and then runs a small script from the deploy directory that copies the readme into the packages. Every publish command runs that prepare step first, so the documentation a user sees on the registry for any individual package is the repository's single readme rather than a file someone edited in nine places.

There is also a separate command that produces local archives rather than publishing, running the same prepare step and then a script that builds tarballs. So you can get the exact published shape of every package before any of it goes out.

The design is a reasonable answer to a real problem. Nine packages with nine readmes is nine things to forget to update. The cost is that a package-specific note cannot be added to the registry documentation without either editing the shared readme or dropping the automation, and there is a single point of failure: if the copy script breaks, everything publishes with stale documentation.

Publishing runs on three channels with different meanings

There are three publish commands, and the difference between them is the distribution tag rather than the work done.

Each one runs the same prepare step and then publishes every package under a different tag: one for the current stable line, one for prereleases, and one for release candidates. The tag is the only variable.

That is the minimum viable scheme for a library that ships breaking changes, and it matters here because the project is on a version whose minor bump happened recently, with patch releases following over the following ten days. Someone depending on the prerelease channel gets the new major behaviour; someone on the stable channel keeps the old one until they choose to move.

The release command is separate from publishing. It deletes a generated assets directory inside one specific package and then bumps versions across the repository. So the version bump has a build-cleaning step attached to it, which is the kind of detail that breaks a release if the generated directory is left in place and gets committed.

Dependencies are versioned in three places at once

A monorepo with many packages has an obvious failure mode: every package resolves its own version of the formatter, the type checker, the test runner and the linter, and the drift is invisible until something behaves differently in two packages.

This repository addresses that with three layers. There are per-package manifests, a single lock file, and something better: a shared catalogue declared in the workspace file, which the manifests reference by category name rather than by version.

The dev dependencies show the mechanism clearly. The formatter, its import-sorting plugin, its documentation plugin and the type checker all reference one catalogue entry. A set of utilities references another. A development tool from a different organisation references a third, named after the person who maintains it.

That is a meaningfully better answer than repeated version strings, and it is why adding a package does not create a decision about which version of the tooling to use. The trade is a non-obvious indirection: reading a manifest tells you which category a dependency belongs to but not what version it resolves to, so the workspace file has to be read alongside it.

The toolchain uses the author's own type checker

The dev dependency list contains something that will be familiar to anyone who has worked in this ecosystem and surprising to anyone who has not.

Alongside the standard type checker there is a second one, from the same author. Both are present. So the project that provides typed decorators for a TypeScript framework is type-checking itself with a non-standard compiler.

That is a defensible choice for a library whose entire value proposition is what the type system does, and it is also a coupling: the tooling and the product come from one person, so a change in the compiler is a change in the library.

The rest of the list is more conventional and gives a picture of what this project takes seriously. A spell checker with its own dictionary file at the root, which is what you need in a repository with a large generated API surface full of near-identical identifiers. A line counter. An import-order formatter and a documentation-comment formatter. A version bump tool and a cross-platform environment switcher.

One entry is worth decoding: a type package pulled in under an alias pointing at a differently named package, pinned to one version. That is the usual way to reach into a compiler's own types, and you only need it if you are testing against them.

Nothing in the test run stops at the first failure

The root test script has a shape that tells you what the project wants from its own verification.

It builds every package, then runs each package's own test if that package has one, then starts each test package. Three phases, in that order, and every step carries a flag that says do not stop on failure.

So a red test in one package does not prevent the other packages from reporting. For a monorepo that is the right default: you learn the full extent of a breakage in one run instead of playing whack-a-mole across nine packages.

Alongside it there is a separate step called evidence, run across the packages with its own configuration file at the root, also without bailing, and this one runs the packages serially with a concurrency of one. Serial execution for a step like that suggests something that writes to shared state or produces output that must not interleave.

The word choice is interesting. Evidence rather than test implies generated proof rather than assertions, which fits a project that publishes benchmark results and a specification document alongside its code.

Editorial conclusion

Adopt this if you write a typed server in that framework and the repetition of runtime validation on both ends bothers you, because the type and the check coming from one declaration is genuinely the right shape. Two cautions. The performance figures on the page are the author's own and are attached to a specific comparison rather than to a workload you control, so treat them as an indication of direction rather than a number you can plan around. And this is a monorepo publishing nine packages on three release channels, which is a lot of moving surface for one author to hold; if you adopt the core decorators you are adopting the same maintenance burden as the whole set.

Frequently asked questions

Official sources

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