{"slug": "wyrly-di-type-safe-dependency-injection-for-modern-typescript", "title": "Wyrly DI: Type-safe Dependency Injection for Modern TypeScript", "summary": "Wyrly DI is a new dependency injection toolkit for TypeScript that uses standard TC39 decorators instead of legacy experimental decorators or `reflect-metadata`. It requires explicit declaration of dependencies through a `deps` array, making dependency relationships visible to code review and static analysis tools. The toolkit supports singleton, scoped, and transient lifetimes, includes web framework adapters that create per-request DI scopes, and provides built-in dependency graph validation to detect issues like singletons depending on scoped dependencies.", "body_md": "We have released **Wyrly DI**, a dependency injection toolkit for TypeScript.\n\nWyrly DI is designed for modern TypeScript applications that want dependency\n\ninjection without relying on `reflect-metadata`\n\n, `emitDecoratorMetadata`\n\n, legacy\n\ndecorators, or parameter decorators.\n\nIt focuses on:\n\n- standard decorators\n- type-safe tokens\n- explicit dependency definitions\n- request scopes for web applications\n- inspectable and validatable dependency graphs\n\nIn this article, \"standard decorators\" means TC39 decorators supported by\n\nTypeScript 5.0 and later. This is different from the older\n\n`experimentalDecorators`\n\nmodel that many existing DI libraries were built\n\naround.\n\n## Links\n\n## Why another DI toolkit?\n\nMany TypeScript DI libraries use runtime metadata to infer constructor\n\ndependencies.\n\nThat can be convenient, but it also means important dependency information can\n\nbecome hidden behind runtime metadata and decorator behavior.\n\nWyrly DI takes a more explicit approach.\n\n``` js\nimport { Injectable, token } from \"@wyrly/core\";\n\ntype User = {\n  id: string;\n  name: string;\n};\n\ninterface UserRepository {\n  findById(id: string): Promise<User | null>;\n}\n\nconst UserRepositoryToken = token<UserRepository>(\"UserRepository\");\n\n@Injectable({\n  deps: [UserRepositoryToken],\n  lifetime: \"scoped\",\n})\nclass GetUserUseCase {\n  constructor(private readonly users: UserRepository) {}\n\n  execute(id: string) {\n    return this.users.findById(id);\n  }\n}\n```\n\nBy declaring `deps`\n\n, dependencies remain visible to code review, static\n\nanalysis, CI, and AI-assisted development tools.\n\nWith standard decorators, Wyrly DI does not try to read constructor parameter\n\ntypes from `reflect-metadata`\n\n. You can still use normal constructor injection,\n\nsuch as `constructor(private readonly users: UserRepository)`\n\n, but the\n\ndependency mapping is declared explicitly with `deps`\n\n.\n\nIn the example above, `UserRepositoryToken`\n\nis used because TypeScript\n\ninterfaces do not exist at runtime. When the dependency is a class, the class\n\nitself can also be used as a token. In other words, you can use typed tokens for\n\ninterfaces and class tokens for classes.\n\n## Type-safe tokens\n\nTypeScript interfaces disappear at runtime, so interface-based dependencies need\n\na runtime token.\n\nWyrly DI provides typed tokens for that purpose.\n\n``` js\nconst UserRepositoryToken = token<UserRepository>(\"UserRepository\");\n\nconst users = scope.resolve(UserRepositoryToken);\n// users: UserRepository\n```\n\nThe resolved value is inferred as `UserRepository`\n\n, so interface-based\n\ndependencies can still be used in a type-safe way.\n\n## Request scopes\n\nWeb applications often need dependencies that are different for each request.\n\nFor example:\n\n- current user\n- request\n- response\n- unit of work\n- DataLoader\n- request-scoped cache\n\nWyrly DI's web adapters are built around this model:\n\n```\n1 HTTP request = 1 DI scope\n1 GraphQL request = 1 DI scope\n```\n\nRequest scope is not the only supported lifetime. The core package supports\n\n`singleton`\n\n, `scoped`\n\n, and `transient`\n\n, so you can model application-wide\n\ndependencies, per-request dependencies, and dependencies that should be created\n\non every resolution.\n\nFor example, the Hono adapter creates a scope per request in middleware, then\n\nlets handlers resolve dependencies from that scope.\n\n``` js\nimport { Hono } from \"hono\";\nimport { createContainer } from \"@wyrly/core\";\nimport { di, getDI, type HonoDIVariables } from \"@wyrly/hono\";\n\nconst app = new Hono<{ Variables: HonoDIVariables }>();\nconst container = createContainer();\n\napp.use(di(container));\n\napp.get(\"/users/:id\", async (c) => {\n  const scope = getDI(c);\n  const usecase = scope.resolve(GetUserUseCase);\n\n  return c.json(await usecase.execute(c.req.param(\"id\")));\n});\n```\n\n## Inspecting and validating the dependency graph\n\nWyrly DI can inspect and validate the dependency graph.\n\n``` js\nconst graph = container.inspect();\n\nconst result = container.validate();\n```\n\nFor example, validation can detect dangerous lifetime relationships, such as a\n\nsingleton depending on a scoped dependency.\n\n``` php\nsingleton -> scoped dependency\n```\n\nThat kind of relationship can cause subtle bugs, such as request-specific data\n\nbeing held by a singleton.\n\nYou can also put graph validation in a test and fail CI when the composition\n\nroot becomes invalid.\n\n``` js\nimport { assertEquals } from \"@std/assert\";\n\nDeno.test(\"DI graph is valid\", () => {\n  const result = container.validate();\n\n  assertEquals(\n    result.ok,\n    true,\n    result.issues.map((issue) => issue.message).join(\"\\n\"),\n  );\n});\n```\n\nThis may be unnecessary for very small applications.\n\nBut in applications that care about boundaries, such as DDD or Clean\n\nArchitecture style codebases, dependency problems become more expensive to fix\n\nwhen they are discovered late.\n\nFor example:\n\n- a singleton service accidentally depends on a request-scoped\n`CurrentUser`\n\n- an application use case becomes too coupled to infrastructure details\n- a composition root grows without anyone noticing an invalid dependency relationship\n\nValidating the graph in CI helps catch those structural problems before they\n\nbecome normal parts of the codebase.\n\n## Published packages\n\nThe following packages are available:\n\n```\n@wyrly/core\n@wyrly/next\n@wyrly/express\n@wyrly/hono\n@wyrly/fresh\n@wyrly/graphql\n```\n\nUse JSR for Deno:\n\n```\ndeno add jsr:@wyrly/core\n```\n\nUse npm for Node.js and Bun:\n\n```\nnpm install @wyrly/core\n```\n\nInstall adapters as needed:\n\n```\nnpm install @wyrly/hono\nnpm install @wyrly/next\nnpm install @wyrly/graphql\n```\n\n## When Wyrly DI may be a good fit\n\nWyrly DI may fit your project if you want to:\n\n- avoid\n`reflect-metadata`\n\n- use DI with TypeScript standard decorators\n- make a composition root explicit in DDD or Clean Architecture\n- use request scopes with Next.js, Hono, Express, or GraphQL\n- make the dependency graph visible in review and CI\n\n## When another tool may be a better fit\n\nAnother tool may be a better fit if you want:\n\n- a full-stack framework with controllers, modules, authentication, and configuration management\n- automatic scanning and registration as the primary workflow\n- parameter decorator-based injection\n- compatibility with an existing app that deeply depends on\n`reflect-metadata`\n\nWyrly DI intentionally separates a small explicit DI core from framework\n\nadapters.\n\n## Examples\n\nThe repository includes runnable examples for:\n\n- DDD composition root\n- Hono API\n- Express API\n- Next.js App Router\n- GraphQL request scope\n- DataLoader pattern\n- dependency graph validation\n\nSee the examples here:\n\n[github.com/valid-lab/wyrly/tree/main/examples](https://github.com/valid-lab/wyrly/tree/main/examples)\n\n## Closing\n\nWyrly DI is a toolkit for making TypeScript dependency injection explicit,\n\nanalyzable, and practical for request-scoped web applications.\n\nThe design principles are:\n\n- explicit dependency definitions over implicit auto-resolution\n- inspectable structure over hidden behavior\n- standard decorators over legacy decorators\n- type-safe tokens over string-only tokens\n- composition roots over automatic scanning\n\nIf that sounds useful for your project, start with `@wyrly/core`\n\nand the example\n\nclosest to your framework.", "url": "https://wpnews.pro/news/wyrly-di-type-safe-dependency-injection-for-modern-typescript", "canonical_source": "https://dev.to/valid-lab/wyrly-di-type-safe-dependency-injection-for-modern-typescript-1c1f", "published_at": "2026-05-23 11:15:57+00:00", "updated_at": "2026-05-23 11:32:50.060994+00:00", "lang": "en", "topics": ["developer-tools", "open-source", "products"], "entities": ["Wyrly DI", "TypeScript", "TC39"], "alternates": {"html": "https://wpnews.pro/news/wyrly-di-type-safe-dependency-injection-for-modern-typescript", "markdown": "https://wpnews.pro/news/wyrly-di-type-safe-dependency-injection-for-modern-typescript.md", "text": "https://wpnews.pro/news/wyrly-di-type-safe-dependency-injection-for-modern-typescript.txt", "jsonld": "https://wpnews.pro/news/wyrly-di-type-safe-dependency-injection-for-modern-typescript.jsonld"}}