This fork has been made to manage changes necessary to use with an embedded JavaScript framework called ModdableSDK. There are five main changes:
- Addition of a ttypescript module to
allow for compiling with the command
ttscusing the required DI transformer. Also updatedpackage.jsonto use apostinstallscript to load the required modules. - Addition of a new singleton for
DIContaineras static memberDIContainer.container(). Primary intended use is for libraries where the library wishes to be consumable from code that might not use or instantiateDIContainer. By having the library import code define the injections using the shared singleton instance, the library can operate stand-alone, while still working with other libraries or main application that consumesDIContainer. - Addition of a
manifest.jsonfile required by Moddable to control the build. This file is similar to apackage.jsonfile used by Node, but has a different format and technique to include files. - A change to
di-container.tsto resolve a typescript error due to a missing cast. - Remove
distfrom .gitignore so that we can check in the typescript compiled files. This is a bit of a hack, as we should publish a package. Hopefully once this is resolved the changes can be pulled intowessberg/dito avoid all of this! - Improved some error handling, with better hints when the transformer isn't working and constructor exceptions now throw the original error rather than one that is likely less descriptive.
Using this requires changing the typescript compiler from tsc to ttsc in the Moddable manifest.json file, and setting
up the TypeScript to use the di tranformer. This is done by adding the following to manifest.json:
"typescript": {
"compiler": "ttsc",
"tsconfig": {
"compilerOptions": {
"plugins": [
{
"transform": "$(PROJECT_DIR)/node_modules/@cmidgley/di/ttypescript/src/transformer.js"
}
]
}
}
}
Don't forget to add this package to your package.json file, such as:
"dependencies": {
"@cmidgley/di": "https://github.com/cmidgley/di"
}
A compile-time powered Dependency-Injection container for Typescript that holds services and can produce instances of them as required.
This is a tiny library that brings Dependency-Injection to Typescript. There are several competing libraries out there, but this one is unique in the sense that:
- It is seriously small.
- It does its work on compile-time. The only runtime dependency is the
DIContaineritself. - It doesn't ask you to reflect metadata or to annotate your classes with decorators. "It just works".
- It maps interfaces to implementations. Most popular dependency injection systems for TypeScript doesn't do this. This allows you to truly decouple an abstraction from its implementation.
- It supports the .NET generic reflection flavour:
registerSingleton<Interface, Implementation>(). No need for anything else.
This library provides constructor-based dependency injection. This means that your classes will receive dependency-injected services as arguments to their constructors.
This library is a runtime dependency, but you need to transform your code with the
DI Custom Transformer as part of your Typescript compilation step to make
the reflection work.
 |
 |
 |
 |
 |
|---|---|---|---|---|
| Bubbles Twitter: @usebubbles |
Christopher Blanchard | Ideal Postcodes | Xerox | Trent Raymond |
$ npm install @wessberg/di
$ yarn add @wessberg/di
$ pnpm add @wessberg/di
This library is meant to be super straightforward, super simple to use. The following examples hopefully shows that:
To register services, simply instantiate a new service container and add services to it. Here's several examples of how you may do that:
import { DIContainer } from "@wessberg/di";
// Instantiate a new container for services
const container = new DIContainer();
// Register the service as a Singleton. Whenever the 'IMyService' service is requested,
// the same instance of MyService will be injected
container.registerSingleton<IMyService, MyService>();
// Register the service as a Transient. Whenever the 'IMyService' service is requested,
// a new instance of MyService will be injected
container.registerTransient<IMyOtherService, MyOtherService>();
// Rather than mapping a class to an interface,
// here we provide a function that returns an object that implements
// the required interface
container.registerSingleton<IAppConfig>(() => myAppConfig);
// You don't have to map an interface to an implementation.
container.registerSingleton<MyAwesomeService>();...Works completely automatically. As long as your class is constructed via a DIContainer, and as long as the services
it depends on are registered, the class will receive the services as arguments to its' constructor:
class MyClass {
constructor(
private myService: IMyService,
private myOtherService: IMyOtherService,
private myAwesomeService: MyAwesomeService
) {}
}The true power of this library in comparison to others is that all of this mapping happens on compile-time. This is what enables you to depend on interfaces, rather than objects that live on runtime.
Sure, you can do that if you want to:
// Gets a concrete instance of 'IMyService'. The implementation will
// depend on what you provided when you registered the service
const service = container.get<IMyService>();Do you want to contribute? Awesome! Please follow these recommendations.
 |
|---|
| Frederik Wessberg Twitter: @FredWessberg Github: @wessberg Lead Developer |
It may look like it, but I assure you it is quite simple. Read this answer for an explanation.
Sure. You can instantiate as many as you want to, as long as you make sure the Custom Transformer for DI get's to see the files that contain them.
MIT © Frederik Wessberg (@FredWessberg) (Website)