
Security News
/Research
Wallet-Draining npm Package Impersonates Nodemailer to Hijack Crypto Transactions
Malicious npm package impersonates Nodemailer and drains wallets by hijacking crypto transactions across multiple blockchains.
This library implements dependency injection for javascript.
The container is the place where all dependencies get bound to. It is possible to have multiple container in our project in parallel.
import {Container} from "@owja/ioc";
const container = new Container();
This is the default way to bind a dependency. The class will get instantiated when the dependency gets resolved.
container.bind<ServiceInterface>(symbol).to(Service);
This will create only one instance of Service
container.bind<ServiceInterface>(symbol).to(Service).inSingletonScope();
Factories are functions which will get called when the dependency gets resolved
container.bind<ServiceInterface>(symbol).toFactory(() => new Service());
container.bind<string>(symbol).toFactory(() => "just a string");
A factory can configured for singleton scope too. This way will only executed once.
container.bind<ServiceInterface>(symbol).toFactory(() => new Service()).inSingletonScope();
This is always like singleton scope, but it should be avoid to instantiate dependencies here. If they are circular dependencies, they will fail.
container.bind<ServiceInterface>(symbol).toValue(new Service()); // Bad, should be avoid
container.bind<string>(symbol).toValue("just a string");
container.bind<() => string>(symbol).toValue(() => "i am a function");
This is the way how we can rebind a dependency while unit tests. We should not need to rebind in production code.
container.rebind<ServiceMock>(symbol).toValue(new ServiceMock());
Normally this function is not used in production code. This will remove the dependency from the container.
container.remove(symbol);
Getting dependencies without @inject
decorators trough container.get()
is only meant for unit tests.
This is also the internal way how the @inject
decorator and the functions wire()
and resolve()
are getting the
dependency.
container.get<Interface>(symbol);
To get a dependency without @inject
decorator in production code use wire()
or resolve()
. Using container.get()
directly to getting dependencies can result in infinite loops with circular dependencies when called inside of
constructors. In addition container.get()
does not respect the cache.
Important Note: You should avoid accessing the dependencies from any constructor. With circular dependencies this can result in a infinite loop.
This creates a snapshot of the bound dependencies. After this we can rebind dependencies and can restore it back to its old state after we made some unit tests.
container.snapshot();
container.restore();
inject
DecoratorTo use the decorator you have to set experimentalDecorators
to true
in your tsconfig.json
.
First we have to create a inject
decorator for each container:
import {createDecorator} from "@owja/ioc";
export const inject = createDecorator(container);
Then we can use the decorator to inject the dependency.
class Example {
@inject(symbol)
readonly service!: Interface;
method() {
this.service.doSomething();
}
}
wire()
FunctionIf we do not want to use decorators, we can use the wire function. It does the same like the inject
decorator and we have to create the function first like we do with inject
.
import {createWire} from "@owja/ioc";
export const wire = createWire(container);
Then we can wire up the dependent to the dependency.
class Example {
readonly service!: Interface;
constructor() {
wire(this, "service", symbol);
}
method() {
this.service.doSomething();
}
}
Notice: With
wire()
the property, in this caseservice
, has to be public.
resolve()
FunctionA second way to resolve a dependency without decorators is to use resolve()
.
To use resolve()
we have to create the function first.
import {createResolve} from "@owja/ioc";
export const resolve = createResolve(container);
Then we can resolve the dependency in classes and even functions.
class Example {
private readonly service = resolve<Interface>(symbol);
method() {
this.service().doSomething();
}
}
function Example() {
const service = resolve<Interface>(symbol);
service().doSomething();
}
Notice: We access the dependency trough a function. The dependency is not assigned directly to the property/constant. If we want direct access we can use
container.get()
but we should avoid usingget()
inside of classes because we then loose the lazy dependency resolving/injection behavior and caching.
symbol
Symbols are used to identify our dependencies. A good practice is to keep them in one place.
export const TYPE = {
"Service" = Symbol("Service"),
// [...]
}
Symbols can be defined with Symbol.for()
too. This way they are not unique.
Remember Symbol('foo') === Symbol('foo')
is false
but
Symbol.for('foo') === Symbol.for('foo')
is true
export const TYPE = {
"Service" = Symbol.for("Service"),
// [...]
}
Since 1.0.0-beta.3 we use the symbol itself for indexing the dependencies. Prior to this version we indexed the dependencies by the string of the symbol.
npm install --save-dev @owja/ioc
Now we create the folder services and add the new file services/types.ts:
export const TYPE = {
MyService: Symbol("MyService"),
MyOtherService: Symbol("MyOtherService"),
};
Next we create out example services.
File services/my-service.ts
export interface MyServiceInterface {
hello: string;
}
export class MyService implements MyServiceInterface{
hello = "world";
}
File services/my-other-service.ts
export interface MyOtherServiceInterface {
random: number;
}
export class MyOtherService implements MyOtherServiceInterface {
random = Math.random();
}
Next we need a container to bind our dependencies to. Let's create the file services/container.ts
import {Container, createDecorator} from "@owja/ioc";
import {TYPE} from "./types";
import {MyServiceInterface, MyService} from "./service/my-service";
import {MyOtherServiceInterface, MyOtherService} from "./service/my-other-service";
const container = new Container();
const inject = createDecorator(container);
container.bind<MyServiceInterface>(TYPE.MyService).to(MyService);
container.bind<MyOtherServiceInterface>(TYPE.MyOtherService).to(MyOtherService);
export {container, TYPE, inject};
Lets create a example.ts file in our source root:
import {TYPE, inject} from "./service/container";
import {MyServiceInterface} from "./service/my-service";
import {MyOtherServiceInterface} from "./service/my-other-service";
class Example {
@inject(TYPE.MyService)
readonly myService!: MyServiceInterface;
@inject(TYPE.MyOtherService)
readonly myOtherService!: MyOtherServiceInterface;
}
const example = new Example();
console.log(example.myService);
console.log(example.myOtherService);
console.log(example.myOtherService);
If we run this example we should see the content of our example services.
The dependencies (services) will injected on the first call. This means if you rebind the service after
accessing the properties of the Example class, it will not resolve a new service. If you want a new
service each time you call example.myService
you have to add the NOCACHE
tag:
// [...]
import {NOCACHE} from "@owja/ioc";
class Example {
// [...]
@inject(TYPE.MyOtherSerice, NOCACHE)
readonly myOtherService!: MyOtherServiceInterface;
}
// [...]
In this case the last two console.log()
outputs should show different numbers.
For unit testing we first create our mocks
test/my-service-mock.ts
import {MyServiceInterface} from "../service/my-service";
export class MyServiceMock implements MyServiceInterface {
hello = "test";
}
test/my-other-service-mock.ts
import {MyOtherServiceInterface} from "../service/my-other-service";
export class MyOtherServiceMock implements MyOtherServiceInterface {
random = 9;
}
Within the tests we can snapshot and restore a container. We are able to make multiple snapshots in a row too.
File example.test.ts
import {container, TYPE} from "./service/container";
import {MyServiceInterface} from "./service/my-service";
import {MyOtherServiceInterface} from "./service/my-other-service";
import {MyServiceMock} from "./test/my-service-mock";
import {MyOtherServiceMock} from "./test/my-other-service-mock";
import {Example} from "./example";
describe("Example", () => {
let example: Example;
beforeEach(() => {
container.snapshot();
container.rebind<MyServiceInterface>(TYPE.MyService).to(MyServiceMock);
container.rebind<MyOtherServiceInterface>(TYPE.MyOtherService).to(MyOtherServiceMock);
example = new Example();
});
afterEach(() => {
container.restore();
});
test("should return \"test\"", () => {
expect(example.myService.hello).toBe("test");
});
test("should return \"9\"", () => {
expect(example.myOtherService.random).toBe(9);
});
});
Current state of development can be seen in our Github Projects.
This library is highly inspired by InversifyJS but has other goals:
MIT
Copyright © 2019 Hauke Broer
FAQs
dependency injection for javascript
We found that @owja/ioc demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
/Research
Malicious npm package impersonates Nodemailer and drains wallets by hijacking crypto transactions across multiple blockchains.
Security News
This episode explores the hard problem of reachability analysis, from static analysis limits to handling dynamic languages and massive dependency trees.
Security News
/Research
Malicious Nx npm versions stole secrets and wallet info using AI CLI tools; Socket’s AI scanner detected the supply chain attack and flagged the malware.