Nestia: Compile-Time TypeScript Decorators for NestJS, Plus Generated SDKs

What Nestia replaces in a NestJS codebase

NestJS ships with class-validator and class-transformer as the conventional validation and serialization layer. Those libraries work at runtime: decorators on class properties are read by reflection when a request arrives, and validation happens per request. Nestia takes a different route. Its @TypedBody, @TypedParam, @TypedQuery, @TypedHeaders, @TypedFormData, and @TypedRoute decorators are compiled by a TypeScript transformer, so the validation and serialization code is generated at build time from the type signatures you already wrote. The README states the runtime validator is 20,000 times faster than class-validator and JSON serialization is 200 times faster than class-transformer. Those figures come from the project's own benchmark directory, not from independent measurement, and the repository links to results on an 11th Gen Intel Core i5-1135G7. Treat the multiplier as a claim tied to a specific machine and workload, not a guarantee for your endpoint mix.

The practical effect is that you stop writing two parallel descriptions of the same shape. A TypeScript interface used as a controller parameter type becomes both the runtime validator and the Swagger schema. That is the core proposition, and it is narrower than the README's feature list suggests. Nestia is not a framework replacement. It is a set of libraries that sit on top of NestJS and change how types flow from controller signatures into validation, documentation, and client code.

The compiler plugin is the mechanism, and it is also the constraint

Nestia's typed decorators do not do their work through reflection. They rely on a TypeScript transformer that runs during compilation, reads the type information attached to decorated parameters, and emits validation and serialization functions. This is why the decorators can accept pure TypeScript types instead of classes. It is also why the project cannot work in a plain ts-node or ts-jest setup without configuration. The Nestia setup documentation describes adding the plugin to your tsconfig and ensuring the build step uses a compiler that supports transformers. If your build pipeline runs through a bundler that strips or ignores TypeScript transformers, the typed decorators will not produce their generated code.

This design choice has a second consequence: the type system becomes load-bearing at runtime. A type that TypeScript can express but the transformer cannot resolve, such as certain conditional or mapped types, may fail at build time rather than silently degrade. That is arguably safer than runtime reflection, but it moves failures from request time to compile time, which changes how you debug. The @nestia/sdk package then reads the same controller metadata to generate a client SDK. According to the README, the SDK is a collection of typed fetch functions with DTO structures similar to tRPC, and it includes a mockup simulator described as similar to msw but fully automated. The SDK generator, Swagger generator, and E2E test function generator all consume the same source: your controller types.

Getting it running: packages, CLI, and config

The repository is organized as a set of npm packages plus a CLI. The README lists @nestia/core for decorators and WebSocket routes, @nestia/sdk for Swagger generation, SDK generation, mockup simulation, and E2E test generation, @nestia/e2e for running test programs, @nestia/benchmark for benchmarks built on those test functions, @nestia/editor for a Swagger UI with an online TypeScript editor, and the nestia CLI itself. The setup guide is at nestia.io/docs/setup. Based on the repository layout, installation follows the normal pattern of adding the relevant packages to your project and registering the compiler plugin in tsconfig.

The README does not reproduce the exact tsconfig block or the CLI invocation for SDK generation in the excerpt provided, so I cannot give you the literal plugin entry or the full command list without guessing. What is documented is the existence of a CLI tool named nestia and separate guide pages for the SDK builder, the mockup simulator, E2E test functions, SDK distribution, and the Swagger builder. If you are evaluating Nestia, the setup page and the SDK builder page are the two documents to read before touching your build config, because the plugin registration is the step most likely to conflict with an existing pipeline. The @nestia/editor package is a separate deployment concern: it is a Swagger UI variant with an embedded TypeScript editor, which implies a hosted or served component rather than a build-time-only tool.

Where the design gets in the way

The most obvious limitation is that Nestia assumes TypeScript types are the authoritative description of your API. If your DTOs are classes decorated with class-validator constraints such as @IsEmail or @MinLength, those constraints are runtime metadata that the transformer does not read. You would need to express the same rules through TypeScript types, which cannot capture everything a validator can. A string type cannot say "must be a valid email address" without a branded type or a custom transformer. The README's claim of 20,000x faster validation is real in the sense that generated code avoids reflection, but it is not free: you trade declarative constraint decorators for type-level encoding, and some constraints become harder to express.

A second limitation is the client story. The generated SDK is TypeScript, built around typed fetch functions. If your API consumers are mobile apps in Swift or Kotlin, or third-party integrators who expect a conventional OpenAPI document, the SDK generator does not help them. The Swagger generator does produce a document, so those consumers are not abandoned, but the SDK's main advantage, end-to-end type safety, only applies to TypeScript clients. The mockup simulator is likewise useful only inside TypeScript test and frontend code.

A third issue is build coupling. Because the transformer runs during compilation, the correctness of your runtime validation depends on the build configuration being right in every environment, including CI, Docker images, and any serverless bundler. A misconfigured build can produce a server that starts but does not validate. That is a different failure mode than class-validator, where validation is present as long as the library is loaded.

How it compares to tRPC and to plain NestJS plus OpenAPI

The README itself points at tRPC as the reference for what the generated SDK feels like: typed fetch functions with DTO structures. The difference is architectural. tRPC typically couples a TypeScript server and a TypeScript client through a shared router definition, and it is not built on NestJS decorators or HTTP semantics in the same way. Nestia keeps the NestJS controller model, including HTTP verbs, status codes, and Swagger output, and derives the client from that. If you already have a NestJS application and want to keep it, tRPC would mean restructuring the server layer. If you are starting fresh and only ever have TypeScript clients, tRPC's tighter coupling may be simpler.

The other comparison is the conventional NestJS stack: class-validator for input, class-transformer for output, and @nestjs/swagger for documentation. That stack requires you to annotate DTOs twice, once for validation and once for Swagger, and it relies on reflection at runtime. Nestia removes the duplication and the reflection cost. The price is the compiler plugin and the constraint that types must be expressible in a form the transformer understands. For a small API with a handful of endpoints, the conventional stack is less setup. For a large API with many DTOs and a TypeScript frontend, the duplication cost of the conventional stack grows, and that is where Nestia's approach pays off.

Maintenance, release cadence, and licence

The recent release history shows v13.0.0 on 2026-08-21, followed by v13.0.1 and v13.0.2 within days, and the last push to the default branch is 2026-09-02. That pattern suggests active development with patch releases following a major version bump. A major version bump in a compiler-plugin project is worth noting: the plugin interacts with TypeScript's transformer API, and TypeScript itself ships breaking changes to that API. Upgrading Nestia may force a TypeScript upgrade, and upgrading TypeScript may force a Nestia upgrade. Budget for that coupling if you pin either dependency.

The project is MIT licensed, which permits commercial use, modification, and redistribution with the licence and copyright notice preserved. That is a permissive licence with no copyleft obligation. It does not, however, come with any warranty, and the README's performance figures are the project's own. The repository also points to a Discord server, a Gurubase documentation chatbot, and an OpenCollective funding page, which indicates a maintainer-supported project rather than one backed by a company with a support contract. There is no commercial support tier described in the material provided.

Who should adopt it and what to check first

Nestia fits teams that have already standardized on NestJS and TypeScript, that treat TypeScript types as the contract for their API, and that want a generated client SDK and Swagger document from that single source. It also fits teams that have measured validation or serialization as a meaningful cost in their request path, since the generated code avoids per-request reflection.

It does not fit teams whose validation logic lives in class-validator decorators that cannot be expressed as types, teams whose API consumers are not TypeScript, or teams whose build pipeline cannot run a TypeScript transformer. It is also a poor fit for a small service where the setup cost of the plugin outweighs the duplication it removes.

The first thing to verify is your build pipeline. Confirm that the compiler plugin can be registered in your tsconfig and that every environment where the server runs, including CI and container builds, uses the same compilation path. The second is your DTO inventory: list the validation constraints you currently express with class-validator and check whether each one has a type-level equivalent. The third is SDK distribution. The README links to a separate guide page on SDK distribution, which implies the generated SDK is meant to be published or shared as a package; decide whether your frontend can consume it that way before committing to the generator. If all three checks pass, the reduction in duplicated DTO definitions is the concrete gain. If any fails, the conventional NestJS stack with class-validator and @nestjs/swagger remains the lower-risk choice.

Editorial conclusion

Adopt Nestia if your backend is NestJS, your DTOs are already TypeScript types or interfaces, and you want a generated client SDK plus Swagger document produced from those types without maintaining a separate OpenAPI file. Do not adopt it if you rely on class-validator and class-transformer decorators as your validation layer, if your API consumers are not TypeScript, or if you cannot add a compiler plugin step to your build. Before committing, verify that your tsconfig and build pipeline can run the Nestia compiler plugin, that your existing DTOs are expressible as pure TypeScript types rather than classes with runtime decorators, and that the generated SDK distribution model matches how your frontend consumes packages.

Official sources

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