Launched this week
InferDI
Next-gen TypeScript DI. The graph is the type.
2 followers
Next-gen TypeScript DI. The graph is the type.
2 followers
InferDI is next-gen DI for TypeScript where the dependency graph is the type. It catches missing keys, wrong constructor deps, and unsafe lifetime leaks at compile time — with no decorators, no reflect-metadata, no plugins, no setup, and zero runtime dependencies. Works anywhere TypeScript or JavaScript runs.
Hey Product Hunt 👋
I built InferDI because I believe TypeScript dependency injection needs a new foundation.
Most DI containers still belong to the decorator / reflection era. They often require reflect-metadata, emitDecoratorMetadata, framework-specific conventions, compiler plugins, custom transformers, or build-pipeline setup.
That worked for a while. But modern TypeScript apps now run across Node, Bun, Deno, browsers, workers, edge functions, Vite, SWC, esbuild, and many different framework stacks.
InferDI takes a different path:
The dependency graph is the type.
No decorators.
No reflect-metadata.
No plugins.
No code generation.
No tsconfig magic.
No runtime dependencies.
Just vanilla TypeScript.
InferDI turns the DI graph into a compile-time contract. The compiler can catch mistakes that usually become runtime bugs:
• missing dependency keys
• wrong constructor dependencies
• misordered constructor arguments
• duplicate registrations
• unsafe singleton → scoped/transient lifetime leaks
It also keeps your business logic clean. Your services stay plain TypeScript classes with normal constructors — no @Injectable(), no @Inject(), no framework imports. All wiring lives in the Composition Root, so your domain code does not become locked to a DI framework.
InferDI still gives you the primitives real applications need:
• singleton / scoped / transient lifetimes
• lazy injection
• child scopes
• test overrides
• explicit disposal with using / await using
• runtime guards as defense-in-depth
The goal is not to build another magical IoC framework.
The goal is to make DI feel native to modern TypeScript: explicit, portable, type-safe, build-tool agnostic, and boring at runtime.
I see InferDI as next-generation DI because it moves the important work out of runtime magic and into the compiler — without asking you to change your build system, decorate your classes, or trust hidden reflection.
I’d love feedback from TypeScript developers, backend engineers, framework authors, and anyone who has avoided DI because it felt too heavy or too magical:
What would make you trust a DI container in a serious production TypeScript codebase?