finds.dev← search

// the find

marcj/deepkit

★ 3,543 · TypeScript · MIT · updated Feb 2026

modular high-performance TypeScript framework

Deepkit is a TypeScript backend framework built around a custom compiler plugin that keeps type information alive at runtime, so one class definition drives validation, serialization, DI, HTTP routing, RPC, and the ORM instead of three parallel schemas (interface + Zod + TypeORM entity). It's aimed at Node teams who want a structured, NestJS-style framework but are tired of hand-syncing type definitions across layers.

The runtime type reflection is a real differentiator, not just a slogan — intersection types like `string & MinLength<3>` double as both the TS type and the validation rule, which actually kills the triple-definition problem the README opens with. It's genuinely modular: 40+ independent packages mean you can pull in just @deepkit/type for runtime types and validation without buying into the DI container, HTTP layer, or ORM. DI resolves on plain constructor parameter types with no `@Injectable()` decorator, which is an unusual and fairly elegant design choice rather than decorator sugar swapped for different sugar. The performance story isn't just asserted — validation, serialization, and DI are JIT-compiled, and the repo ships its own bench package to back that up.

The entire value proposition depends on a non-standard tsc transformer (`@deepkit/type-compiler`), so you're no longer on a stock TypeScript toolchain — that's friction with esbuild/swc/Next.js and a real lock-in risk if the project stalls. At 3.5k stars this is small next to what it's actually competing with (NestJS, Zod+Prisma stacks), and most of the listed community packages (OpenAPI, GraphQL, Remix adapters) are third-party, individually maintained, and inconsistent in upkeep. There's no migration path from TypeORM, Prisma, or Zod — adopting the ORM or validator means rewriting model definitions from scratch, and the README doesn't address incremental adoption into an existing codebase. It's effectively carried by one maintainer (marcj) across 40+ packages, which is a lot of surface area for a small team and a real bus-factor concern for something this architecturally deep.

View on GitHub → Homepage ↗

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →