injecuteType-safe dependency injection

Where it fits ​

A new module inside a big brownfield system ​

Mature frameworks come with opinions about modules, HTTP, configuration and lifecycle. injecute brings a container and nothing else, so a new module gets exactly the structure it needs and still plugs into the system around it.

A non-typical greenfield project ​

When a new project doesn't fit a framework's template, injecute gives you a set of tools and the flexibility to solve the problems you meet as the architecture grows: forks and modules, tags, lifecycle hooks and your own way to register services.

Code written with coding agents ​

injecute gives an agent what it needs to get the wiring right without guessing:

• The docs of your version, in the package. llms.txt, every guide as Markdown and TSDoc with an example on every export live in node_modules/injecute, so they never drift from the code. An Agent Skill has the rules for writing, reviewing and debugging it.
• Wiring an agent can read. Each registration lists the keys it depends on. There are no decorators, naming conventions or reflection to infer, so the agent reads what will be injected.
• Mistakes caught in the agent's own loop. A wrong key or a missing service fails the typecheck, with "Did you mean". At runtime every error has a stable code, the resolution path and a page that says how to fix it.
• One way per task. Each task has one recommended way, and the docs lead with it, so generated code looks the same across the codebase.
• Short feedback loop. The typecheck shows errors early, before any test runs.

See Using injecute with AI agents to set it up.

Is it the right choice? ​

A quick look ​

import {
  DIContainer,
  startable,
  startLifecycle,
  type ServiceRegistry,
} from 'injecute';

// a module asks only for what it needs and registers its part of the app
const addUsers = (c: ServiceRegistry<{ db: Database }>) =>
  c.addSingleton('users', UserRepository, ['db']);

const app = new DIContainer()
  .addInstance('dbUrl', 'postgres://localhost/app')
  .addSingleton('db', Database, ['dbUrl'])
  .extend(addUsers)
  .extend(
    startable('server', HttpServer, ['users'], {
      start: (server) => server.listen(3000),
      stop: (server) => server.close(),
    }),
  );

app.get('users'); // UserRepository, typed

// start the server; on shutdown, close it, then dispose the container
const running = await startLifecycle(app);
process.once('SIGTERM', () => running.stop());

// in a test: replace the database for the whole graph, without touching `app`
await using test = app
  .fork({ isolated: true })
  .addInstance('db', fakeDb, { replace: true });

No decorators are needed, but if you want them, a recipe builds them on top of the container.

Starts and stops servers and consumers in stages, and closes every connection with one call. Works with Express, Fastify, Hono, Next.js and GraphQL, on Node.js, Deno, Bun and in browsers, with no runtime dependencies.