Gathering detailed insights and metrics for inversify-components
Gathering detailed insights and metrics for inversify-components
Gathering detailed insights and metrics for inversify-components
Gathering detailed insights and metrics for inversify-components
inversify-react
Components and decorators to connect react with inversify.
inversify-hooks
Wrapper of inversify-props to inject your dependencies in the components, made with TypeScript using hooks.
@ablestack/inversify-react
A copy of Kukkimonsuta/inversify-react - Components and decorators to connect react with inversify - only intended for ablestack consumers
inversify-rn
Components and decorators to connect react with inversify.
Small framework on top of InversifyJS to enable component based dependency injection
npm install inversify-components
Typescript
Module System
Node Version
NPM Version
71.6
Supply Chain
97.5
Quality
75.7
Maintenance
100
Vulnerability
100
License
TypeScript (91.51%)
JavaScript (7.74%)
Dockerfile (0.75%)
Total Downloads
52,783
Last Day
2
Last Week
7
Last Month
85
Last Year
1,181
MIT License
28 Stars
116 Commits
7 Forks
6 Watchers
11 Branches
49 Contributors
Updated on Jun 08, 2025
Minified
Minified + Gzipped
Latest Version
0.5.0
Package Id
inversify-components@0.5.0
Unpacked Size
34.75 kB
Size
10.00 kB
File Count
30
NPM Version
6.13.4
Node Version
10.19.0
Cumulative downloads
Total Downloads
1
2
Small framework on top of InversifyJS to enable component based dependency injection. Each component describes its interfaces and bindings with the help of descriptors, and never accesses the dependency injection container directly. This enables you to:
Install inversify-components and set it as an dependency in your local package.json:
npm i --save inversify-components
1import { ContainerImpl } from "inversify-components"; 2let container = new ContainerImpl(); 3// Also supports options: 4// let container = new ContainerImpl({ defaultScope: "Singleton" });
1import { MainApplication } from "inversify-components"; 2 3class App implements MainApplication { 4 execute(container: Container) { 5 // Start your application using the container! 6 } 7}
1import { descriptor } from "my-component-descriptor"; 2container.componentRegistry.addFromDescriptor(descriptor);
1container.componentRegistry.autobind(container.inversifyInstance);
1container.componentRegistry.lookup(nameOfComponent).addConfiguration({ 2 configurationKey: "configurationValue" 3});
1container.setMainApplication(new App()); 2container.runMain();
inversify-components allows you to basically split your applications into independent components. To achieve this, each component exports
a component descriptor
:
1import { ComponentDescriptor } from "inversify-components"; 2 3export const descriptor: ComponentDescriptor = { 4 name: "name-of-component", // This must be unique for all registered components 5 bindings: { 6 root: (bindService, lookupService) => { 7 // Binding of services is very similar to inversifyJS: 8 bindService.bindGlobalService<TypeOfService>("service-name").to(MyServiceClass); 9 10 // MyServiceClass is now bound to "name-of-component:service-name" and available in all other components. 11 } 12 } 13};
Notice that each binding gets the unique component name as a prefix. This guarantees that there are not duplicate service bindings across all registered components.
You are also able to grab the inversify coontainer in a ComponentDescriptor
:
1import { ComponentDescriptor } from "inversify-components"; 2 3export const descriptor: ComponentDescriptor = { 4 name: "name-of-component", // This must be unique for all registered components 5 bindings: { 6 root: (bindService, lookupService, inversifyContainer) => { 7 // Unbind something.. 8 inversifyContainer.unbind("service"); 9 10 bindService.bindGlobalService<TypeOfService>("service-name").to(MyServiceClass); 11 } 12 } 13};
So if needed, you are always in full control inside your dependency descriptors.
The above component descriptor executes bindings for the root
scope. This is the default scope for inversify-components, which
is executed automatically at autobind
. But you could also register bindings for a specific scope, and execute this scope
at application runtime to a specific point in time:
1import { ComponentDescriptor } from "inversify-components"; 2 3export const descriptor: ComponentDescriptor = { 4 name: "name-of-component", 5 bindings: { 6 root: (bindService, lookupService) => { 7 bindService.bindGlobalService<TypeOfService>("service-name").to(MyServiceClass); 8 } 9 request: (bindService, lookupService) => { 10 // Is not available at application start, but as soon as you open your "request" scope: 11 bindService.bindGlobalService<TypeOfService>("current-session").toDynamicValue(....); 12 } 13 } 14}; 15 16// In your MainApplication / App, as soon as you would like to open the above "request" scope: 17// 1) Create inversify child container 18let scopedRequestContainer = container.inversifyInstance.createChild(); 19 20// 2) Possibly bind some dependent values to this container, e. g. the current request headers and body: 21scopedRequestContainer.bind("request-body").toConstantValue(currentRequestBody); 22 23// 3) Execute scoped "request" bindings in this container 24container.componentRegistry.autobind(scopedRequestContainer, [], "request"); 25 26// 4) Go on in your compoisiton root with child container 27scopedRequestContainer.get(...) // Maybe your request handler?
To enable plugging into your component, you can define extension points. This is done using symbols.
Component A: The component which owns the extension point and wants to load plugins:
1import { ComponentDescriptor } from "inversify-components"; 2import { injectable, multiInject, optional } from "inversify"; 3 4const myExtensionPoints = { 5 "firstExtensionPoint": Symbol("first-extension-point") 6} 7 8export const descriptor: ComponentDescriptor = { 9 name: "component-a", 10 11 // Register all available extension points 12 interfaces: myExtensionPoints 13}; 14 15@injectable() 16class ClassUsingPlugins { 17 // Now you can just inject all plugins registered at firstExtensionPoint and use them: 18 constructor(@optional() @multiInject(myExtensionPoints.firstExtensionPoint) plugins) { 19 this.plugins = plugins; 20 } 21}
Component B: The component which adds a plugin to extension point firstExtensionPoint:
1export const descriptor: ComponentDescriptor = { 2 name: "component-b", 3 bindings: { 4 root: (bindService, lookupService) => { 5 let extensionPoint = lookupService.lookup("component-a").getInterface("firstExtensionPoint"); 6 bindService.bindExtension<ExtensionType>(extensionPoint).to(MyPluginClass); 7 } 8 } 9};
The basic style of configuring components is described in this gist. This style enables you to define default and required configurations without hassle.
You can set a default configuration for your component by adding it to your descriptor:
1const configuration: Configuration.Default = { 2 "configurationKey": "configurationValue"; 3}; 4 5export const descriptor: ComponentDescriptor<Configuration.Default> = { 6 name: "my-component-name", 7 defaultConfiguration: configuration 8}
In all of your classes, you can inject your component meta data, which includes the components configuration:
1import { inject, injectable } from "inversify"; 2import { Component } from "inversify-components"; 3 4@injectable() 5class MyClass { 6 constrcutor(@inject("meta:component//my-component-name") component: Component<Configuration.Runtime>) 7 this.configuration = this.component.configuration; 8 } 9}
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 1/25 approved changesets -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
21 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-06-23
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn MoreLast Day
100%
2
Compared to previous day
Last Week
-80.6%
7
Compared to previous week
Last Month
102.4%
85
Compared to previous month
Last Year
-80.1%
1,181
Compared to previous year