{"id":20827887,"url":"https://github.com/thomwright/di-hard","last_synced_at":"2025-05-07T21:06:11.862Z","repository":{"id":57212122,"uuid":"106468307","full_name":"ThomWright/di-hard","owner":"ThomWright","description":"💉 Dependency injection with namespacing, privacy and lifetimes","archived":false,"fork":false,"pushed_at":"2020-03-25T11:58:31.000Z","size":128,"stargazers_count":4,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-05-07T21:06:03.943Z","etag":null,"topics":["dependency-injection","di","di-container","di-framework","di-hard","die-hard","ioc","modules"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ThomWright.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-10-10T20:34:09.000Z","updated_at":"2022-04-21T12:28:19.000Z","dependencies_parsed_at":"2022-09-06T08:20:33.283Z","dependency_job_id":null,"html_url":"https://github.com/ThomWright/di-hard","commit_stats":null,"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ThomWright%2Fdi-hard","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ThomWright%2Fdi-hard/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ThomWright%2Fdi-hard/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ThomWright%2Fdi-hard/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ThomWright","download_url":"https://codeload.github.com/ThomWright/di-hard/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252954429,"owners_count":21830904,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dependency-injection","di","di-container","di-framework","di-hard","die-hard","ioc","modules"],"created_at":"2024-11-17T23:13:14.811Z","updated_at":"2025-05-07T21:06:11.832Z","avatar_url":"https://github.com/ThomWright.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# DI-hard\n\n[![npm](https://img.shields.io/npm/v/di-hard.svg?maxAge=1000)](https://www.npmjs.com/package/di-hard)\n[![dependency Status](https://img.shields.io/david/ThomWright/di-hard.svg?maxAge=1000)](https://david-dm.org/ThomWright/di-hard)\n[![devDependency Status](https://img.shields.io/david/dev/ThomWright/di-hard.svg?maxAge=1000)](https://david-dm.org/ThomWright/di-hard)\n[![license](https://img.shields.io/github/license/ThomWright/di-hard.svg)](https://github.com/ThomWright/di-hard)\n\nSimple, predictable dependency injection\n\nFeatures:\n\n- clear separation between wiring and application\n- minimal lock-in\n- control over component lifetimes\n- module hierarchy with private and public components\n\nDisclaimer: Despite (now) being written in Typescript, the dependency injection is not typesafe.\n\n## Example\n\n```ts\nimport dihard, {Container} from \"../src\"\n\ninterface InfoGiver {\n  getInfo(): string\n}\n\nfunction myDependencyFactory() {\n  return {\n    getInfo() {\n      return \"(dependency)\"\n    }\n  }\n}\nfunction myServiceFactory({myDependency}: {myDependency: InfoGiver}) {\n  return {\n    getInfo() {\n      return `(service - dependencies: ${myDependency.getInfo()})`\n    },\n  }\n}\n\nconst container: Container = dihard.createContainer(\"application\")\ncontainer.registerFactory(\"myService\", myServiceFactory)\ncontainer.registerFactory(\"myDependency\", myDependencyFactory)\n\nconst myService = container.resolve(\"myService\") as InfoGiver\nconsole.log(myService.getInfo()) // \"(service - dependencies: (dependency))\"\n```\n\n## Terminology\n\n- **component** - a reusable piece of your application\n- **registration** - something which can be registered with the DI container (an _instance_, _factory_ or _module_)\n- **instance** - a static value, or a value created by a _factory_\n- **factory** - a function which creates a (potentially cachable) _instance_\n- **module** - a namespaced set of _registrations_\n- **register** - map an ID to a _registration_\n- **resolution** - the process of mapping an ID to an _instance_ (either externally or through _injection_)\n- **injection** - the process of automatically resolving dependencies for a _factory_\n- **resolver** - object which performs resolution (a [Proxy](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy))\n- **container** - object which contains _registrations_ and cached _instances_\n- **lifetime** - how long a cached _instance_ is expected to live\n- **scope** - which _registrations_ are able to be resolved from a given context\n- **visibility** - whether a _registration_ is private (visible only to other _registrations_ in the same module) or public (shares parent module's visibility)\n\n## Concepts\n\nThe purpose of this library is to enable easy creation of your application's components, without having to worry about those components' dependencies.\n\n### Components\n\nComponents are the individual pieces of your application. They can be functions, objects, classes, strings... whatever you want.\n\nBelow is an example of a component with two dependencies. Here, we have a factory function, which takes an object with named dependencies, and returns an instance of the component (in this case, an object).\n\nNotice that there is no direct dependency on the DI library here. The only requirement is that factory functions take their dependencies as named arguments (an object). This makes the code portable, easy to test, and possible to wire together manually.\n\n```js\n// my-component.js\nconst factory = ({dep1, dep2}) =\u003e {\n  const instance = {\n    get() {\n      return dep1.getSomething() + dep2.getSomethingElse()\n    },\n  }\n  return instance\n}\n```\n\n### Registration, resolution and injection\n\nWhen we have enough components in our application, and the dependency tree starts to get deeper (e.g. `A` depends on `B` which depends on `C` etc.), wiring these components together can become tedious.\n\nWhat we can do instead is register all our component factories with a 'container', and let it be responsible for creating our components (and their dependencies) for us.\n\nHere is how we would register the component factories for the above example, and manually resolve (create) an instance of the component, with its dependencies injected.\n\n```js\nconst di = require(\"di-hard\")\n\nconst container = di.createContainer(\"application\")\n\n// register all component factories\ncontainer.register(\"myComponent\", require(\"./my-component\"))\ncontainer.register(\"dep1\", require(\"./dep1\"))\ncontainer.register(\"dep1\", require(\"./dep2\"))\n\n// resolve an instance of the component\nconst myInstance = container.resolve(\"myComponent\")\nmyInstance.get()\n```\n\nHere we've called `container.resolve()` directly to manually resolve an instance of `myComponent`. But how do `dep1` and `dep2` get resolved? Let's have a look at `myComponent` again, but slightly re-write it to illustrate what's happening.\n\n```js\n// my-component.js\nconst factory = (resolver) =\u003e {\n  const dep1 = resolver.dep1 // resolved when this property is accessed\n  const instance = {\n    get() {\n      const dep2 = resolver.dep2 // lazily resolve dep2\n      return dep1.getSomething() + dep2.getSomethingElse()\n    },\n  }\n  return instance\n}\n```\n\nHere we can see that what actually gets injected is a 'resolver' object. Accessing properties on the resolver is what triggers resolution of dependencies.\n\n### Lifetimes\n\nA lifetime is a statement about how long a container caches a reference to an instance created by a factory.\n\nThere are two lifetimes currently supported:\n\n- `Transient`\n  - no reference cached\n  - one instance created per resolution\n- `Registration`\n  - reference cached in container in which the factory was registered\n  - one instance per registration container\n\n`Transient` is the default lifetime.\n\nTo explicitly set a lifetime, use the `registerFactory` function like so:\n\n```js\ncontainer.registerFactory(\"id\", factory, {lifetime: di.Lifetime.Registration})\n```\n\nIf you have only stateless components, there is very little difference between the two.\n\nGenerally, you can think of `Transient` as being for stateless components, and `Registration` for stateful, though `Registration` can also be used to avoid creating multiple instances unnecessarily.\n\n### Child containers\n\nSometimes you don't want a component to live for the entire life of your application, but also don't want to create a new instance every time it's resolved. For example, in an HTTP server, you might want to create a component which holds some data associated with a request.\n\nFor this, we can use child containers. Create one like so:\n\n```js\nconst di = require(\"di-hard\")\nconst express = require('express')\nconst app = express()\n\nconst container = di.createContainer(\"application\")\n\napp.get(\"/\", (req, res) =\u003e {\n  req.container = container.child(\"request\")\n  // register some components\n  // resolve and use a component\n})\n```\n\nNow, each request can register its own components and have its own instances.\n\nIt is expected that a child container will have a shorter lifetime that its parent. Here, for example, `request` container will live only as long as the request, but the `application` container will live for the lifetime of the application.\n\nWith that in mind, there are two simple rules which dictate how instances get resolved when using child containers:\n\n- *instances get resolved in the container they were registered in*\n- *a container can only resolve dependencies from itself or a parent container*\n\nThis means nothing can depend on something with a shorter lifetime. For example, no components in the `application` container could depend on a component in the `request` container. However, components in the `request` container can depend on instances from the `application` container.\n\n### Modules\n\nSo far we've registered all components into the same namespace. As your application grows, you might want group related components together into namespaces to avoid ID clashes. For this, we use modules.\n\nIt's possible to namespace groups of components by creating a hierarchy of modules.\n\n```js\nconst factory = ({\n  // use nested object deconstruction to inject components from modules\n  my_module: {\n    dependency,\n  },\n}) =\u003e {\n  // ...\n}\n\nconst dependencyDefinition = () =\u003e \"dependencyInstance\"\n\nconst container = createContainer(\"root\")\ncontainer\n  .registerSubmodule(\"my_module\", Visibility.Public)\n    .registerFactory(\"component\", factory, {\n      visibility: Visibility.PUBLIC,\n    })\n    .registerFactory(\"dependency\", dependencyDefinition)\n\n// use shorthand dot-notation to externally resolve components inside modules\nconst instance = container.resolve(\"my_module.component\")\n```\n\n### Visibility\n\nYou can control which components are visible to other components by using visiblity modifiers. Anything registered with the container (a component or a module) can be either `Public` or `Private`. `Private` components are only visible to other components in the same module. `Public` components share their parent module's visiblity.\n\nVisibility defaults to `Private`.\n\nThe top-level (default) module is `Public` (otherwise you wouldn't be able to resolve anything!).\n\nIn the example below, it would be possible to inject `my_module.public_api` into `my_component`, and `my_module.internal` into `my_module.public_api`, but trying to inject `my_module.internal` into `my_component` would throw an error.\n\n```js\nconst container = createContainer(\"root\")\ncontainer\n  .registerFactory(\"my_component\", myComponentFactory)\n  .registerSubmodule(\"my_module\", {visibility: Visibility.Public})\n    .registerFactory(\"public_api\", publicComponent, {\n      visibility: Visibility.Public,\n    })\n    .registerFactory(\"internal\", privateComponent, {\n      visibility: Visibility.Private,\n    })\n```\n\n## API\n\n`const di = require(\"di-hard\")`\n\n### DI\n\n- `di.createContainer(containerName: string) -\u003e Container`\n- `di.Lifetime.Transient`\n- `di.Lifetime.Registration`\n- `di.Visibility.Public`\n- `di.Visibility.Private`\n\n### Container\n\nServices and values can be registered with a container. It is responsible for resolving an ID to an instance.\n\n- `container.registerFactory(id: string, factory: function, options: {lifetime, visibility}) -\u003e registrationApi`\n- `container.registerValue(id: string, value: any, options: {visibility}) -\u003e registrationApi`\n- `container.registerSubmodule(id: string, options: {visibility}) -\u003e registrationApi`\n- `container.resolve(id: string) -\u003e componentInstance`\n- `container.child(containerName: string) -\u003e container`\n\nThe `registerX` functions are chainable, for example:\n\n```js\ncontainer\n  .registerFactory(...)\n  .registerValue(...)\n  .registerSubmodule(...)\n    .registerValue(...)\n```\n\n### Factory functions\n\nFactory functions are used to create the component instances.\n\n- `factory(resolver) -\u003e componentInstance`\n\n### Resolver\n\nThe resolver gets injected into each factory function. It is a [Proxy](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy) which resolves component instances on property lookup.\n\n- `resolver[id] -\u003e componentInstance`\n\n## Further reading\n\n[Inversion of Control Containers and the Dependency Injection pattern - Martin Fowler](https://martinfowler.com/articles/injection.html)\n\n[Dependency Injection in Node.js - 2016 edition](https://medium.com/@Jeffijoe/dependency-injection-in-node-js-2016-edition-f2a88efdd427)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthomwright%2Fdi-hard","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fthomwright%2Fdi-hard","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthomwright%2Fdi-hard/lists"}