tsyringe と typedi は、どちらも TypeScript プロジェクトで依存性注入(DI)パターンを実装するためのライブラリです。これらはデコレータとメタデータ反射を使用して、クラス間の依存関係を自動的に解決し、テスト容易性やコードの結合度を下げることを目的としています。tsyringe は軽量で汎用的なコンテナを提供し、typedi は特に TypeORM などのエコシステムとの統合を歴史的に重視してきました。
tsyringe と typedi は、TypeScript における依存性注入(DI)を支援するライブラリですが、内部の仕組みや設計思想に違いがあります。どちらもデコレータを使って依存関係を定義しますが、コンテナの扱い方や解決方法が異なります。実務でどちらを選ぶべきか、具体的なコード比較を通じて解説します。
依存性注入の第一歩は、コンテナに管理させるクラスを登録することです。両ライブラリともデコレータを使用しますが、名前と挙動が異なります。
tsyringe では @injectable デコレータを使用します。
// tsyringe: クラスの登録
import { injectable } from "tsyringe";
@injectable()
export class UserService {
constructor() {}
}
typedi では @Service デコレータを使用します。
// typedi: クラスの登録
import { Service } from "typedi";
@Service()
export class UserService {
constructor() {}
}
登録したクラスを実際に使用するには、コンテナからインスタンスを取得する必要があります。ここで両者のアプローチが大きく分かれます。
tsyringe はコンテナインスタンスから resolve メソッドを呼び出します。
// tsyringe: インスタンスの取得
import { container } from "tsyringe";
import { UserService } from "./UserService";
const userService = container.resolve(UserService);
// または独自のコンテナインスタンスから取得
// myContainer.resolve(UserService);
typedi は静的な Container クラスから get メソッドを呼び出します。
// typedi: インスタンスの取得
import { Container } from "typedi";
import { UserService } from "./UserService";
const userService = Container.get(UserService);
// グローバルコンテナから直接取得される
クラスが他のクラスに依存している場合、コンストラクタで注入します。両者ともデコレータを使いますが、トークンの扱いが異なります。
tsyringe では @inject デコレータにトークンを指定します。
// tsyringe: 依存関係の注入
import { injectable, inject } from "tsyringe";
import { IUserRepository } from "./interfaces";
@injectable()
export class UserService {
constructor(@inject("IUserRepository") private repo: IUserRepository) {}
}
typedi では @Inject デコレータを使用します。
// typedi: 依存関係の注入
import { Service, Inject } from "typedi";
import { IUserRepository } from "./interfaces";
@Service()
export class UserService {
constructor(@Inject("IUserRepository") private repo: IUserRepository) {}
}
アプリケーションが大きくなると、コンテナの管理方法が重要になります。特にテスト環境やマルチテナント構成ではこの違いが影響します。
tsyringe はコンテナインスタンスを作成できます。
// tsyringe: コンテナインスタンスの管理
import { container, createContainer } from "tsyringe";
// 親コンテナから子コンテナを作成
const childContainer = createContainer();
childContainer.register("config", { useValue: { env: "test" } });
// 子コンテナから解決すると、親の影響を受けずに済む
const service = childContainer.resolve(UserService);
typedi は基本的にグローバルコンテナを使用します。
// typedi: グローバルコンテナの使用
import { Container } from "typedi";
// 基本的に単一のグローバルコンテナを共有
Container.set("config", { env: "production" });
// テスト時にリセットする必要がある
Container.reset();
ライブラリを選ぶ際は、将来のメンテナンス性も考慮する必要があります。
tsyringe は定期的に更新されており、Issue への対応も活発です。
// tsyringe: 安定した API
// 長期間にわたり API の互換性が保たれている
import { injectable } from "tsyringe";
typedi は TypeORM と密接に関連して発展しました。
// typedi: TypeORM との統合
// TypeORM のリポジトリ注入などでよく使われる構成
import { Service } from "typedi";
| 特徴 | tsyringe | typedi |
|---|---|---|
| 登録デコレータ | @injectable() | @Service() |
| 取得方法 | container.resolve() | Container.get() |
| コンテナ | インスタンス作成可能 | 基本的にグローバル |
| テスト容易性 | 高い(隔離しやすい) | 中(リセット必要) |
| メンテナンス | 活発 | 安定だがペース注意 |
| 主な用途 | 汎用 TypeScript DI | TypeORM エコシステム |
tsyringe は、現代の TypeScript プロジェクトにおいて推奨される選択肢です - コンテナインスタンスを自由に扱えるため、テストや複雑な構成にも強く、メンテナンスも活発です。純粋な依存性注入のニーズであれば、こちらを選ぶべきでしょう。
typedi は、既存の TypeORM プロジェクトや、グローバルコンテナで簡潔に済ませたい場合に有用です - ただし、メンテナンス履歴やグローバル状態への依存を理解した上で採用する必要があります。
どちらを選ぶにしても、依存性注入の目的は「結合度を下げてテストしやすくする」ことです - ライブラリの機能以上に、プロジェクトの設計方針に合致しているかが重要になります。
新しいプロジェクトで依存性注入を導入する場合、tsyringe を選択するのが一般的です。アクティブなメンテナンスが行われており、コンテナインスタンスを柔軟に作成できるため、テスト環境での隔離や複数のコンテナ運用に適しています。標準的な TypeScript アプリケーションや、フレームワークに依存しない純粋な DI 構成を求める場合に最適です。
typedi は、既存の TypeORM ベースのプロジェクトで既に導入されている場合に引き続き使用する選択肢です。ただし、メンテナンスの頻度やバージョン間の破壊的変更の歴史があるため、新規採用には注意が必要です。グローバルコンテナを前提とした設計で簡潔に書きたい場合に向いていますが、テスト時の隔離には追加の設定が必要になることがあります。
A lightweight dependency injection container for TypeScript/JavaScript for constructor injection.
Install by npm
npm install --save tsyringe
or install with yarn (this project is developed using yarn)
yarn add tsyringe
Modify your tsconfig.json to include the following settings
{
"compilerOptions": {
"experimentalDecorators": true,
"emitDecoratorMetadata": true
}
}
Add a polyfill for the Reflect API (examples below use reflect-metadata). You can use:
The Reflect polyfill import should only be added once, and before DI is used:
// main.ts
import "reflect-metadata";
// Your code here...
If you're using Babel (e.g. using React Native), you will need to configure it to emit TypeScript metadata.
First get the Babel plugin
yarn add --dev babel-plugin-transform-typescript-metadata
npm install --save-dev babel-plugin-transform-typescript-metadata
Then add it to your Babel config
plugins: [
'babel-plugin-transform-typescript-metadata',
/* ...the rest of your config... */
]
TSyringe performs Constructor Injection on the constructors of decorated classes.
Class decorator factory that allows the class' dependencies to be injected at runtime. TSyringe relies on several decorators in order to collect metadata about classes to be instantiated.
import {injectable} from "tsyringe";
@injectable()
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);
Class decorator factory that registers the class as a singleton within the global container.
import {singleton} from "tsyringe";
@singleton()
class Foo {
constructor() {}
}
// some other file
import "reflect-metadata";
import {container} from "tsyringe";
import {Foo} from "./foo";
const instance = container.resolve(Foo);
Class decorator factory that replaces the decorated class' constructor with a parameterless constructor that has dependencies auto-resolved.
Note Resolution is performed using the global container.
import {autoInjectable} from "tsyringe";
@autoInjectable()
class Foo {
constructor(private database?: Database) {}
}
// some other file
import {Foo} from "./foo";
const instance = new Foo();
Notice how in order to allow the use of the empty constructor new Foo(), we
need to make the parameters optional, e.g. database?: Database.
Parameter decorator factory that allows for interface and other non-class information to be stored in the constructor's metadata.
import {injectable, inject} from "tsyringe";
interface Database {
// ...
}
@injectable()
class Foo {
constructor(@inject("Database") private database?: Database) {}
}
By default, @inject() throws an exception if no registration is found. If you want to have undefined injected when the registration isn't found, you can pass this options { isOptional: true } as the second parameter:
import {injectable, injectAll} from "tsyringe";
@injectable()
class Foo {
constructor(@inject("Database", { isOptional: true }) private database?: Database) {}
}
Parameter decorator for array parameters where the array contents will come from the container. It will inject an array using the specified injection token to resolve the values.
import {injectable, injectAll} from "tsyringe";
@injectable()
class Foo {}
@injectable()
class Bar {
constructor(@injectAll(Foo) fooArray: Foo[]) {
// ...
}
}
By default, @injectAll() throws an exception if no registrations were found. If you want to return an empty array, you can pass this options { isOptional: true } as the second parameter:
import {injectable, injectAll} from "tsyringe";
@injectable()
class Bar {
constructor(@injectAll(Foo, { isOptional: true }) fooArray: Foo[]) {
// ...
}
}
Parameter decorator which allows for a transformer object to take an action on the resolved object before returning the result.
class FeatureFlags {
public getFlagValue(flagName: string): boolean {
// ...
}
}
class Foo() {}
class FeatureFlagsTransformer implements Transform<FeatureFlags, boolean> {
public transform(flags: FeatureFlags, flag: string) {
return flags.getFlagValue(flag);
}
}
@injectable()
class MyComponent(foo: Foo, @injectWithTransform(FeatureFlags, FeatureFlagsTransformer, "IsBlahEnabled") blahEnabled: boolean){
// ...
}
This parameter decorator allows for array contents to be passed through a transformer. The transformer can return any type, so this can be used to map or fold an array.
@injectable()
class Foo {
public value;
}
class FooTransform implements Transform<Foo[], string[]>{
public transform(foos: Foo[]): string[]{
return foos.map(f => f.value));
}
}
@injectable()
class Bar {
constructor(@injectAllWithTransform(Foo, FooTransform) stringArray: string[]) {
// ...
}
}
Class decorator factory that registers the class as a scoped dependency within the global container.
@scoped(Lifecycle.ContainerScoped)
class Foo {}
The general principle behind Inversion of Control (IoC) containers
is you give the container a token, and in exchange you get an instance/value. Our container automatically figures out the tokens most of the time, with 2 major exceptions, interfaces and non-class types, which require the @inject() decorator to be used on the constructor parameter to be injected (see above).
In order for your decorated classes to be used, they need to be registered with the container. Registrations take the form of a Token/Provider pair, so we need to take a brief diversion to discuss tokens and providers.
A token may be either a string, a symbol, a class constructor, or a instance of DelayedConstructor.
type InjectionToken<T = any> =
| constructor<T>
| DelayedConstructor<T>
| string
| symbol;
Our container has the notion of a provider. A provider is registered with the DI container and provides the container the information needed to resolve an instance for a given token. In our implementation, we have the following 4 provider types:
{
token: InjectionToken<T>;
useClass: constructor<T>;
}
This provider is used to resolve classes by their constructor. When registering a class provider you can simply use the constructor itself, unless of course you're making an alias (a class provider where the token isn't the class itself).
{
token: InjectionToken<T>;
useValue: T
}
This provider is used to resolve a token to a given value. This is useful for registering constants, or things that have a already been instantiated in a particular way.
{
token: InjectionToken<T>;
useFactory: FactoryFunction<T>;
}
This provider is used to resolve a token using a given factory. The factory has full access to the dependency container.
We have provided 2 factories for you to use, though any function that matches the FactoryFunction<T> signature
can be used as a factory:
type FactoryFunction<T> = (dependencyContainer: DependencyContainer) => T;
This factory is used to lazy construct an object and cache result, returning the single instance for each subsequent
resolution. This is very similar to @singleton()
import {instanceCachingFactory} from "tsyringe";
{
token: "SingletonFoo";
useFactory: instanceCachingFactory<Foo>(c => c.resolve(Foo));
}
This factory is used to lazy construct an object and cache result per DependencyContainer, returning the single instance for each subsequent
resolution from a single container. This is very similar to @scoped(Lifecycle.ContainerScoped)
import {instancePerContainerCachingFactory} from "tsyringe";
{
token: "ContainerScopedFoo";
useFactory: instancePerContainerCachingFactory<Foo>(c => c.resolve(Foo));
}
This factory is used to provide conditional behavior upon resolution. It caches the result by default, but has an optional parameter to resolve fresh each time.
import {predicateAwareClassFactory} from "tsyringe";
{
token: "FooHttp",
useFactory: predicateAwareClassFactory<Foo>(
c => c.resolve(Bar).useHttps, // Predicate for evaluation
FooHttps, // A FooHttps will be resolved from the container if predicate is true
FooHttp // A FooHttp will be resolved if predicate is false
);
}
{
token: InjectionToken<T>;
useToken: InjectionToken<T>;
}
This provider can be thought of as a redirect or an alias, it simply states that given token x, resolve using token y.
The normal way to achieve this is to add DependencyContainer.register() statements somewhere
in your program some time before your first decorated class is instantiated.
container.register<Foo>(Foo, {useClass: Foo});
container.register<Bar>(Bar, {useValue: new Bar()});
container.register<Baz>("MyBaz", {useValue: new Baz()});
As an optional parameter to .register() you may provide RegistrationOptions
which customize how the registration behaves. See the linked source code for up to date documentation
on available options.
You can also mark up any class with the @registry() decorator to have the given providers registered
upon importing the marked up class. @registry() takes an array of providers like so:
@registry([
{ token: Foobar, useClass: Foobar },
{ token: "theirClass", useFactory: (c) => {
return new TheirClass( "arg" )
},
}
])
class MyClass {}
This is useful when you want to register multiple classes for the same token.
You can also use it to register and declare objects that wouldn't be imported by anything else,
such as more classes annotated with @registry or that are otherwise responsible for registering objects.
Lastly you might choose to use this to register 3rd party instances instead of the container.register(...) method.
note: if you want this class to be @injectable you must put the decorator before @registry, this annotation is not
required though.
Resolution is the process of exchanging a token for an instance. Our container will recursively fulfill the dependencies of the token being resolved in order to return a fully constructed object.
The typical way that an object is resolved is from the container using resolve().
const myFoo = container.resolve(Foo);
const myBar = container.resolve<Bar>("Bar");
You can also resolve all instances registered against a given token with resolveAll().
interface Bar {}
@injectable()
class Foo implements Bar {}
@injectable()
class Baz implements Bar {}
@registry([
// registry is optional, all you need is to use the same token when registering
{token: "Bar", useToken: Foo}, // can be any provider
{token: "Bar", useToken: Baz}
])
class MyRegistry {}
const myBars = container.resolveAll<Bar>("Bar"); // myBars type is Bar[]
You can also add one or more InjectionToken to the registration of your class directly in the @injectable() decorator:
interface Bar {}
@injectable({token: "Bar"})
class Foo implements Bar {}
@injectable({token: ["Bar", "Bar2"]})
class Baz implements Bar {}
class MyRegistry {}
const myBars = container.resolveAll<Bar>("Bar"); // myBars type is Bar[], contains 2 instances
const myBars2 = container.resolveAll<Bar>("Bar2"); // myBars2 type is Bar[], contains 1 instance
You can check if a token is registered in the container using isRegistered().
const isRegistered = container.isRegistered("Bar"); // true
If you have a childContainer and want to recursively check if a token is registered in the parent container, you can pass true as a second parameter of isRegistered().
class Bar {}
container.register(Bar, {useClass: Bar});
const childContainer = container.createChildContainer();
childContainer.isRegistered(Bar); // false
childContainer.isRegistered(Bar, true); // true
Interception allows you to register a callback that will be called before or after the resolution of a specific token. This callback can be registered to execute only once (to perform initialization, for example), on each resolution to do logging, for example.
beforeResolution is used to take an action before an object is resolved.
class Bar {}
container.beforeResolution(
Bar,
// Callback signature is (token: InjectionToken<T>, resolutionType: ResolutionType) => void
() => {
console.log("Bar is about to be resolved!");
},
{frequency: "Always"}
);
afterResolution is used to take an action after the object has been resolved.
class Bar {
public init(): void {
// ...
}
}
container.afterResolution(
Bar,
// Callback signature is (token: InjectionToken<T>, result: T | T[], resolutionType: ResolutionType)
(_t, result) => {
result.init();
},
{frequency: "Once"}
);
If you need to have multiple containers that have disparate sets of registrations, you can create child containers:
const childContainer1 = container.createChildContainer();
const childContainer2 = container.createChildContainer();
const grandChildContainer = childContainer1.createChildContainer();
Each of the child containers will have independent registrations, but if a registration is absent in the child container at resolution, the token will be resolved from the parent. This allows for a set of common services to be registered at the root, with specialized services registered on the child. This can be useful, for example, if you wish to create per-request containers that use common stateless services from the root container.
The container.clearInstances() method allows you to clear all previously created and registered instances:
class Foo {}
@singleton()
class Bar {}
const myFoo = new Foo();
container.registerInstance("Test", myFoo);
const myBar = container.resolve(Bar);
container.clearInstances();
container.resolve("Test"); // throws error
const myBar2 = container.resolve(Bar); // myBar !== myBar2
const myBar3 = container.resolve(Bar); // myBar2 === myBar3
Unlike with container.reset(), the registrations themselves are not cleared.
This is especially useful for testing:
@singleton()
class Foo {}
beforeEach(() => {
container.clearInstances();
});
test("something", () => {
container.resolve(Foo); // will be a new singleton instance in every test
});
Sometimes you need to inject services that have cyclic dependencies between them. As an example:
@injectable()
export class Foo {
constructor(public bar: Bar) {}
}
@injectable()
export class Bar {
constructor(public foo: Foo) {}
}
Trying to resolve one of the services will end in an error because always one of the constructor will not be fully defined to construct the other one.
container.resolve(Foo);
Error: Cannot inject the dependency at position #0 of "Foo" constructor. Reason:
Attempted to construct an undefined constructor. Could mean a circular dependency problem. Try using `delay` function.
delay helper functionThe best way to deal with this situation is to do some kind of refactor to avoid the cyclic dependencies. Usually this implies introducing additional services to cut the cycles.
But when refactor is not an option you can use the delay function helper. The delay function wraps the constructor in an instance of DelayedConstructor.
The delayed constructor is a kind of special InjectionToken that will eventually be evaluated to construct an intermediate proxy object wrapping a factory for the real object.
When the proxy object is used for the first time it will construct a real object using this factory and any usage will be forwarded to the real object.
@injectable()
export class Foo {
constructor(@inject(delay(() => Bar)) public bar: Bar) {}
}
@injectable()
export class Bar {
constructor(@inject(delay(() => Foo)) public foo: Foo) {}
}
// construction of foo is possible
const foo = container.resolve(Foo);
// property bar will hold a proxy that looks and acts as a real Bar instance.
foo.bar instanceof Bar; // true
We can rest in the fact that a DelayedConstructor could be used in the same contexts that a constructor and will be handled transparently by tsyringe. Such idea is used in the next example involving interfaces:
export interface IFoo {}
@injectable()
@registry([
{
token: "IBar",
// `DelayedConstructor` of Bar will be the token
useToken: delay(() => Bar)
}
])
export class Foo implements IFoo {
constructor(@inject("IBar") public bar: IBar) {}
}
export interface IBar {}
@injectable()
@registry([
{
token: "IFoo",
useToken: delay(() => Foo)
}
])
export class Bar implements IBar {
constructor(@inject("IFoo") public foo: IFoo) {}
}
All instances created by the container that implement the Disposable
interface will automatically be disposed of when the container is disposed.
container.dispose();
or to await all asynchronous disposals:
await container.dispose();
Since classes have type information at runtime, we can resolve them without any extra information.
// Foo.ts
export class Foo {}
// Bar.ts
import {Foo} from "./Foo";
import {injectable} from "tsyringe";
@injectable()
export class Bar {
constructor(public myFoo: Foo) {}
}
// main.ts
import "reflect-metadata";
import {container} from "tsyringe";
import {Bar} from "./Bar";
const myBar = container.resolve(Bar);
// myBar.myFoo => An instance of Foo
Interfaces don't have type information at runtime, so we need to decorate them
with @inject(...) so the container knows how to resolve them.
// SuperService.ts
export interface SuperService {
// ...
}
// TestService.ts
import {SuperService} from "./SuperService";
export class TestService implements SuperService {
//...
}
// Client.ts
import {injectable, inject} from "tsyringe";
@injectable()
export class Client {
constructor(@inject("SuperService") private service: SuperService) {}
}
// main.ts
import "reflect-metadata";
import {Client} from "./Client";
import {TestService} from "./TestService";
import {container} from "tsyringe";
container.register("SuperService", {
useClass: TestService
});
const client = container.resolve(Client);
// client's dependencies will have been resolved
Primitive values can also be injected by utilizing named injection
import {singleton, inject} from "tsyringe";
@singleton()
class Foo {
private str: string;
constructor(@inject("SpecialString") value: string) {
this.str = value;
}
}
// some other file
import "reflect-metadata";
import {container} from "tsyringe";
import {Foo} from "./foo";
const str = "test";
container.register("SpecialString", {useValue: str});
const instance = container.resolve(Foo);
The following is a list of features we explicitly plan on not adding:
The library uses the step action EndBug/version-check which requires these two conditions to be met to execute:
Release X.Y.Zpackage.json file.This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.