di4win v1.0.6

Introduction:

By its nature it helps to increase code quality, maintainability and performance (reduce memory usage).

Problem:

• Code is hard to replace if the code base grows over certain levels / class numbers
• Imports start to get a mess and refactoring and reading codes takes more and more time (boilerplate)
• Specific parts of the software have to wait for others, manuel synchronisation gets unreadable and hard testable
• Constructors and functions should wait for async processes, before be initialised (no async constructors in nodejs)
• Patterns like factory and singleton get repeated over and over again
• Testing specific aspects of the software gets challenging over time, because more and more mock code is needed to define simple instances
• Overall complexity by direct links reduces chances to decommission part of the software

Motivation:

• **I wanted a solution which comes without tons of dependencies**
• I want the code to hold as less state as possible to reduce possible side effects and unwanted mutations
• I want the code to be more memory efficient
• I want to create a flexible, easy to use, fast to learn library which supports powerful customisation and uses proven design patterns like singleton and factory, as well as laziness
• I want to have life cycle events when important things happen
• I want config files to allow overrides
• I want to have the chance to deal with edge-cases (legacy code)
• I want config files with build in (key,value) store to be easy to be accessible without second solution
• I want to have the flexibility to change parts of the code with custom implementations which fit the project
• (optional) I want to have config files for different environments

When should I use this library?

:question: You want a dependency free (fat-free), "type-safe", tested and easy to learn library

:question: You are searching for a solution to make dependencies:

• replaceable
• testable
• automatically initialised

:question: You are looking for a solution to run synchronous constructors which depend on asynchronous code

:question: You have implicit dependencies

:question: You want to work with edge-cases like dependencies, which export objects or run commonjs code

:question: You want to use configuration files with (key,value) nature to be easy accessible for you at runtime

:question: You want to have the flexibility to change parts of the code with custom implementations:

For example, you want to load config files which are encrypted somehow etc.

• You don't like to write the same code over and over again to create some instances
• You need to listen for important life cycles event for example when the container is ready to be used or shutdown (async support)

When should I not use this library?

• You don't need this project because you are running a small project
• You are running your software in the browser (but usage is possible was well)

Features

:heavy_plus_sign: Load dependencies with config (file optional) (to overrule, load edge-cases or commonjs files)

:heavy_plus_sign: Includes simple build-in (key,value) store (immutable at runtime)

:heavy_plus_sign: Includes events for startup and shutdown of the container (with async support)

:heavy_plus_sign: Includes events for all major interactions

:heavy_plus_sign: Define implicit require relationships (means wait for a other dependency to be ready)

:heavy_plus_sign: Multi-environment support (default, production or whatever)

:heavy_plus_sign: Auto-loader for dependencies with annotation based system (typescript only)

:heavy_plus_sign: Allow control for dependency at class level with param annotation (id, singleton, lazy, requires)

:heavy_plus_sign: Dump dynamically loaded dependencies to file system (for legacy support or faster start up times)

:heavy_plus_sign: Replace following aspects of the implementation with custom implementation:

• Define how function arguments get parsed (to automatically resolve dependencies by argument names)
• Define how the file system should be scanned (glob etc.)
• Define how dependencies should be named in the container (match coding standards of your project)

:heavy_plus_sign: Debug mode to follow the resolving in cases of errors and conflicts

:heavy_plus_sign: Define custom resolve strategy for conflicts

• Currently supported: omit, fail, overwrite

Available conflict resolve strategies

• Dependency resolve strategies

Available events

• DI Container Events

Available log levels

• DI Container log levels

Examples

• Example one
  • Contains an example with custom static file support with yaml and multi environment setup
• Example two
  • Contains an example with custom injection with annotations

For more details watch the example or test folder