Dependency injection in TypeScript

The coupling to remove is new inside a class — constructor injection takes it out. When a class constructs its own collaborators, it depends on their concrete types and their construction details (connection strings, retry config, clock). It cannot run without them, and it cannot be told to use a different one. The fix is to stop constructing and start receiving: declare what you need as a constructor parameter, typed by an interface.

// BEFORE — the class reaches out and builds the world
class OrderService {
  private readonly repo = new PostgresOrderRepo(process.env.DB_URL!);
  private readonly mailer = new SmtpMailer(process.env.SMTP!);
  place(order: Order) { /* uses this.repo, this.mailer */ }
}

// AFTER — the class declares what it needs and receives it
interface OrderRepo { save(order: Order): Promise<void>; }
interface Mailer { send(to: string, body: string): Promise<void>; }

class OrderService {
  constructor(
    private readonly repo: OrderRepo,
    private readonly mailer: Mailer,
  ) {}
  place(order: Order) { /* uses this.repo, this.mailer */ }
}

OrderService now depends only on the OrderRepo and Mailer interfaces. It has no idea Postgres or SMTP exist. That ignorance is the point: the high-level policy (placing an order) no longer knows about low-level mechanism.

Someone still has to call new — push it to a composition root at the edge. Injection moves the construction up, not away. The buck stops at the composition root: a single place, as close as possible to the program’s entry point (main, the HTTP server bootstrap, the worker startup), where every concrete class is constructed and wired together. The core never sees it.

// main.ts — the composition root: the ONLY place that knows the concretes
function buildApp() {
  const repo = new PostgresOrderRepo(process.env.DB_URL!);
  const mailer = new SmtpMailer(process.env.SMTP!);
  const orders = new OrderService(repo, mailer);   // wire the graph
  return new HttpServer(orders);
}

buildApp().listen(3000);

Now the dependency arrow points the right way: details (PostgresOrderRepo) depend on abstractions (OrderRepo) defined near the policy, and only main.ts depends on the details. Everything below it is pure wiring-free logic. This is what “keep the core unaware of how it’s constructed” means in practice — construction is a leaf concern at the boundary, not a responsibility smeared through the domain.

This is precisely what makes the core unit-testable with fakes. Because OrderService receives its collaborators, a test can hand it trivial in-memory stand-ins instead of a real database or SMTP server. No network, no container, no mocking framework rewriting modules — just pass a different object that satisfies the interface.

test("place() emails the customer after saving", async () => {
  const saved: Order[] = [];
  const sent: string[] = [];
  const fakeRepo: OrderRepo = { save: async (o) => { saved.push(o); } };
  const fakeMailer: Mailer = { send: async (to) => { sent.push(to); } };

  const service = new OrderService(fakeRepo, fakeMailer);
  await service.place({ id: "1", email: "a@b.com" /* … */ });

  expect(saved).toHaveLength(1);
  expect(sent).toEqual(["a@b.com"]);
});

The fake is a few lines because the seam is an interface, not a concrete class you have to subclass or monkey-patch. If you find yourself reaching for heavyweight module-mocking to test a unit, that is usually a smell that the dependency is hardcoded inside instead of injected. DI is what turns “untestable without infrastructure” into “testable with a plain object”.

Manual DI vs a container — and why the container is usually overkill at first. For a small graph, the composition root is a few new calls in dependency order. That’s “poor man’s DI”, and it is genuinely fine: it’s explicit, type-checked, has zero dependencies, and a stack trace points straight at the wiring. A DI container automates this — you register OrderRepo → PostgresOrderRepo once and ask the container to resolve OrderService, and it constructs the transitive graph for you.

// manual: explicit, no magic, type-checked by the compiler
const orders = new OrderService(new PostgresOrderRepo(url), new SmtpMailer(smtp));

// container (e.g. tsyringe): a registry resolves the graph for you
container.register<OrderRepo>("OrderRepo", { useClass: PostgresOrderRepo });
const orders = container.resolve(OrderService); // graph built by reflection

A container starts to pay off when the graph is large, lifetimes matter (singletons vs per-request scopes), and wiring the same dozens of services by hand becomes its own maintenance burden — the kind of thing you hit in a sizeable NestJS or Spring app. Below that threshold a container adds a dependency, decorator/reflection setup, and a layer of indirection that obscures the graph instead of clarifying it. When NOT to apply: don’t reach for a framework container in a small or early app just because “real apps use DI containers” — manual wiring at the composition root already gives you DIP. The container is an optimisation for graph scale, not a prerequisite for injection.