Skip to main content



Please know, that the docs is still work in progress. Many features or use cases are probably already in the lib but not documented well. We are working on it.


work in progress

No async support

Existing libraries like inversify and others don’t support asynchronous code.

They either provide a promise to your constructor or require one to imperatively execute all potentially async code before the binding phase.

This is far from ideal.

Heavy use of decorators

Secondly, they rely on decorators and reflect-metadata

Decorators create unnecessary coupling of an application business logic with a framework. The whole idea of DI is to decouple the application business logic. Coupling classes with a DI framework is still coupling and turns DI into a service locator.

Also, decorator support is an experimental feature in Typescript and current implementation is not compatible with the TC39 proposal. This will probably cause problems for any non-trivial decorators and babel hacks.

In addition to that it is very hard to use reflect-metadata with starters like CRA, Next.js etc. To use reflect-metadata you need to tweak your compilers (babel, typescript, esbuild, swc etc.) configuration. So if you can’t use reflect-metadata you can’t use inversify or tsyringe.

Comparison with inversifyjs, tsyringe and others

Inversion of Control (IoC) is a great way to decouple code and the most popular pattern of IoC is dependency injection (DI) but it is not limited to one.

In JavaScript there is not way to create a dependency injection without mixing application business logic with a specific IoC library code or hacking a compiler (reflect-metadata).

inversifyjs and tsyringe use decorators and reflect-metada

import { injectable } from "tsyringe"

class Foo {
constructor(private database: Database) {}

// some other file
import "reflect-metadata"
import { container } from "tsyringe"
import { Foo } from "./foo"

const instance = container.resolve(Foo)

typed-inject uses monkey-patching

import { createInjector } from "typed-inject"
function barFactory(foo: number) {
return foo + 1
barFactory.inject = ["foo"] as const
class Baz {
constructor(bar: number) {
console.log(`bar is: ${bar}`)
static inject = ["bar"] as const

With Iti your application business logic is not mixed with the framework code

import type { Ingredients } from "./store.ingrediets"
import type { Oven } from "./store.oven"

export class Kitchen {
constructor(private oven: Oven, private ingredients: Ingredients) {}

// provider / factory
import { IngredientsService } from "../services/ingredients-manager"
import { Kitchen } from "../stores/"
import { Oven } from "../stores/store.oven"

export async function provideKitchenContainer() {
let oven = new Oven()
let ingredients = await IngredientsService.buySomeIngredients()
let kitchen = new Kitchen(oven, ingredients)

return {
oven: oven,
ingredients: ingredients,
kitchen: kitchen,

Notable inspirations:

Questions and tips

Can I have multiple application containers?

Yes, no problem at all. If you want, they can even share tokens and hence instances!

Why getContainerSet is always async?

This is temporary(?) limitation to keep typescript happy and typescript types reasonable sane