Top Related Projects
A powerful and lightweight inversion of control container for JavaScript & Node.js apps powered by TypeScript.
A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript 🚀
Simple yet powerful dependency injection tool for JavaScript and TypeScript.
Extremely powerful Inversion of Control (IoC) container for Node.JS
An addictive .NET IoC container
Quick Overview
TSyringe is a lightweight dependency injection container for TypeScript/JavaScript. It provides decorators and a container to manage dependencies, making it easier to implement inversion of control in your applications. TSyringe is designed to be simple to use and integrate with existing projects.
Pros
- Easy to set up and use with minimal configuration
- Supports both TypeScript and JavaScript
- Provides decorators for clean and intuitive dependency injection
- Lightweight and has no external dependencies
Cons
- Limited advanced features compared to more comprehensive DI frameworks
- May require additional setup for use in non-TypeScript projects
- Documentation could be more extensive, especially for advanced use cases
- Not as widely adopted as some other DI solutions
Code Examples
- Basic dependency injection:
import { injectable, inject, container } from "tsyringe";
@injectable()
class HttpClient {}
@injectable()
class UserService {
constructor(@inject(HttpClient) private httpClient: HttpClient) {}
}
const userService = container.resolve(UserService);
- Registering a singleton:
import { injectable, singleton, container } from "tsyringe";
@injectable()
@singleton()
class ConfigService {
// ...
}
const config1 = container.resolve(ConfigService);
const config2 = container.resolve(ConfigService);
console.log(config1 === config2); // true
- Using factory functions:
import { injectable, factory, container } from "tsyringe";
interface Logger {
log(message: string): void;
}
const loggerFactory = () => ({
log: (message: string) => console.log(`[LOG]: ${message}`)
});
container.register<Logger>("Logger", { useFactory: loggerFactory });
@injectable()
class MyService {
constructor(@inject("Logger") private logger: Logger) {}
}
Getting Started
-
Install TSyringe:
npm install tsyringe reflect-metadata
-
Import reflect-metadata in your main file:
import "reflect-metadata";
-
Use decorators to mark classes as injectable:
import { injectable } from "tsyringe"; @injectable() class MyService { // ... }
-
Resolve dependencies using the container:
import { container } from "tsyringe"; const myService = container.resolve(MyService);
Competitor Comparisons
A powerful and lightweight inversion of control container for JavaScript & Node.js apps powered by TypeScript.
Pros of InversifyJS
- More mature and feature-rich, with a larger ecosystem of extensions and plugins
- Supports advanced features like tagged bindings and contextual bindings
- Offers a more flexible API for complex dependency injection scenarios
Cons of InversifyJS
- Steeper learning curve due to its more extensive API and concepts
- Slightly more verbose syntax for basic use cases
- Larger bundle size compared to TSyringe
Code Comparison
InversifyJS:
@injectable()
class Ninja {
@inject(TYPES.Weapon) private _katana: Weapon;
@inject(TYPES.ThrowableWeapon) private _shuriken: ThrowableWeapon;
public fight() { return this._katana.hit(); }
public sneak() { return this._shuriken.throw(); }
}
TSyringe:
@injectable()
class Ninja {
constructor(
@inject("Weapon") private _katana: Weapon,
@inject("ThrowableWeapon") private _shuriken: ThrowableWeapon
) {}
public fight() { return this._katana.hit(); }
public sneak() { return this._shuriken.throw(); }
}
Both libraries provide similar functionality for dependency injection in TypeScript projects. InversifyJS offers more advanced features and flexibility, making it suitable for complex applications. TSyringe, developed by Microsoft, provides a simpler API and smaller footprint, which may be preferable for smaller projects or those new to dependency injection.
A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript 🚀
Pros of Nest
- Full-featured web application framework with built-in support for various architectural patterns
- Extensive ecosystem with modules for database integration, authentication, and more
- Strong TypeScript support with decorators for enhanced developer experience
Cons of Nest
- Steeper learning curve due to its comprehensive nature
- Potentially overkill for smaller projects or microservices
- Heavier runtime overhead compared to lightweight DI solutions
Code Comparison
Nest:
@Injectable()
export class CatsService {
private readonly cats: Cat[] = [];
create(cat: Cat) {
this.cats.push(cat);
}
findAll(): Cat[] {
return this.cats;
}
}
TSyringe:
@injectable()
class CatsService {
private readonly cats: Cat[] = [];
create(cat: Cat) {
this.cats.push(cat);
}
findAll(): Cat[] {
return this.cats;
}
}
While the code structure looks similar, Nest provides a more opinionated approach with built-in decorators and modules, whereas TSyringe focuses solely on dependency injection. Nest offers a complete framework experience, while TSyringe is a lightweight DI container that can be integrated into existing projects more easily.
Simple yet powerful dependency injection tool for JavaScript and TypeScript.
Pros of TypeDI
- More extensive documentation and examples
- Supports both decorator-based and non-decorator-based dependency injection
- Offers a wider range of container manipulation methods
Cons of TypeDI
- Slightly more complex API compared to TSyringe
- Less active development and fewer recent updates
- Smaller community and fewer third-party integrations
Code Comparison
TSyringe:
import { injectable, inject, container } from "tsyringe";
@injectable()
class Service {
constructor(@inject("Logger") private logger: Logger) {}
}
TypeDI:
import { Service, Inject, Container } from "typedi";
@Service()
class MyService {
constructor(@Inject("Logger") private logger: Logger) {}
}
Both libraries offer similar syntax for decorators and dependency injection. TSyringe uses @injectable()
while TypeDI uses @Service()
. The injection syntax is nearly identical, with both using @inject()
or @Inject()
respectively.
TypeDI provides more flexibility in container manipulation and supports non-decorator-based DI, which can be useful in certain scenarios. TSyringe, being maintained by Microsoft, has more frequent updates and a larger community. Both libraries are solid choices for dependency injection in TypeScript projects, with the choice depending on specific project requirements and preferences.
Extremely powerful Inversion of Control (IoC) container for Node.JS
Pros of Awilix
- More flexible container API with support for various registration methods
- Built-in support for auto-loading modules and creating scoped containers
- Better TypeScript support with less reliance on decorators
Cons of Awilix
- Steeper learning curve due to more advanced features
- Slightly more verbose syntax for basic dependency registration
- Less integration with Angular-style decorators
Code Comparison
Awilix:
import { createContainer, asClass } from 'awilix'
const container = createContainer()
container.register({
service: asClass(MyService).singleton()
})
TSyringe:
import { container } from "tsyringe";
@injectable()
class MyService {}
container.register("service", MyService);
Both Awilix and TSyringe are popular dependency injection containers for JavaScript/TypeScript. Awilix offers more flexibility and advanced features, while TSyringe provides a simpler API with tighter integration for decorator-based workflows. Awilix's container API is more powerful, allowing for various registration methods and auto-loading of modules. However, this comes at the cost of a steeper learning curve. TSyringe, being developed by Microsoft, has good integration with TypeScript but relies more heavily on decorators. The choice between the two often depends on the specific needs of the project and the developer's preference for API style.
An addictive .NET IoC container
Pros of Autofac
- More mature and feature-rich, with extensive documentation and community support
- Supports advanced scenarios like child containers and lifetime scopes
- Offers a fluent API for registration and configuration
Cons of Autofac
- Steeper learning curve due to its extensive feature set
- Larger footprint and potential performance overhead for simpler applications
- Primarily designed for .NET, limiting its use in other ecosystems
Code Comparison
Autofac:
var builder = new ContainerBuilder();
builder.RegisterType<MyService>().As<IService>();
var container = builder.Build();
var service = container.Resolve<IService>();
TSyringe:
import {injectable, container} from "tsyringe";
@injectable()
class MyService implements IService {}
const service = container.resolve(MyService);
Summary
Autofac is a powerful and mature dependency injection container for .NET, offering advanced features and extensive customization options. TSyringe, on the other hand, is a lightweight and TypeScript-focused DI solution that provides a simpler API and easier integration with TypeScript projects. While Autofac excels in complex .NET applications, TSyringe is more suitable for TypeScript-based projects that require a straightforward DI implementation.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
TSyringe
A lightweight dependency injection container for TypeScript/JavaScript for constructor injection.
Installation
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...
Babel
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
yarn add --dev babel-plugin-transform-typescript-metadata
npm
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... */
]
API
TSyringe performs Constructor Injection on the constructors of decorated classes.
Decorators
injectable()
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.
Usage
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);
singleton()
Class decorator factory that registers the class as a singleton within the global container.
Usage
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);
autoInjectable()
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.
Usage
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
.
inject()
Parameter decorator factory that allows for interface and other non-class information to be stored in the constructor's metadata.
Usage
import {injectable, inject} from "tsyringe";
interface Database {
// ...
}
@injectable()
class Foo {
constructor(@inject("Database") private database?: Database) {}
}
injectAll()
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.
Usage
import {injectable, injectAll} from "tsyringe";
@injectable()
class Foo {}
@injectable()
class Bar {
constructor(@injectAll(Foo) fooArray: Foo[]) {
// ...
}
}
injectWithTransform()
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, bool> {
public transform(flags: FeatureFlags, flag: string) {
return flags.getFlagValue(flag);
}
}
@injectable()
class MyComponent(foo: Foo, @injectWithTransform(FeatureFlags, FeatureFlagsTransformer, "IsBlahEnabled") blahEnabled: boolean){
// ...
}
injectAllWithTransform()
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[]) {
// ...
}
}
scoped()
Class decorator factory that registers the class as a scoped dependency within the global container.
Available scopes
- Transient
- The default registration scope, a new instance will be created with each resolve
- Singleton
- Each resolve will return the same instance (including resolves from child containers)
- ResolutionScoped
- The same instance will be resolved for each resolution of this dependency during a single resolution chain
- ContainerScoped
- The dependency container will return the same instance each time a resolution for this dependency is requested. This is similar to being a singleton, however if a child container is made, that child container will resolve an instance unique to it.
Usage
@scoped(Lifecycle.ContainerScoped)
class Foo {}
Container
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.
Injection Token
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;
Providers
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:
Class Provider
{
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).
Value Provider
{
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.
Factory provider
{
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;
instanceCachingFactory
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));
}
instancePerContainerCachingFactory
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));
}
predicateAwareClassFactory
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 Provider
{
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.
Register
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()});
Registration options
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.
Registry
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
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[]
Interception
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"}
);
Child Containers
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.
Clearing Instances
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
});
Circular dependencies
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.
The delay
helper function
The 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
Interfaces and circular dependencies
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) {}
}
Disposable instances
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();
Full examples
Example without interfaces
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
Example with interfaces
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
Injecting primitive values (Named injection)
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);
Non goals
The following is a list of features we explicitly plan on not adding:
- Property Injection
Contributing
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.
Top Related Projects
A powerful and lightweight inversion of control container for JavaScript & Node.js apps powered by TypeScript.
A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript 🚀
Simple yet powerful dependency injection tool for JavaScript and TypeScript.
Extremely powerful Inversion of Control (IoC) container for Node.JS
An addictive .NET IoC container
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot