This product was not featured by Product Hunt yet. It will not be visible on their landing page and won't be ranked (cannot win product of the day regardless of upvotes).
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.
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:
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?
No comment highlights available yet. Please check back later!
About InferDI on Product Hunt
“Next-gen TypeScript DI. The graph is the type.”
InferDI was submitted on Product Hunt and earned 3 upvotes and 1 comments, placing #153 on the daily leaderboard. 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.
InferDI was featured in Open Source (68.5k followers), Software Engineering (42.6k followers), Developer Tools (514.1k followers) and GitHub (41.3k followers) on Product Hunt. Together, these topics include over 114.7k products, making this a competitive space to launch in.
Who hunted InferDI?
InferDI was hunted by Max R. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how InferDI stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Max R
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?