{"_id":"addict-ioc","_rev":"87-c00454d9115d5b1f97bd723d23d88773","name":"addict-ioc","dist-tags":{"feature~fix_resolution_context_handling":"2.5.1-8e3dddf1-b1","feature~replace_clone_with_merge":"2.5.2-a7a910cd-b2","feature~fix_class_type_validation":"2.5.2-6aeffa58-b1","feature~add_details_to_registration_validation_errors":"2.5.4-951816ec-b1","feature~update_gulptraum_typescript":"2.5.6-a5d0200a-b1","develop":"2.5.6-aa216cb5-b18","latest":"2.5.6"},"versions":{"1.0.0":{"name":"addict-ioc","version":"1.0.0","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"Sebastian Meier","email":"sebastian.meier@5minds.de"},"license":"ISC","_id":"addict-ioc@1.0.0","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"13b55ef78b88d5d39e77346788ed90a08ae7a46c","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-1.0.0.tgz","integrity":"sha512-gxzkbj4oyvrvMKfWPbAbT+Z6ZaLjm56NsAlc07ofdMF272TG0WBAZ/CxpRW6aNlbGGtV7ww2Rdu/rgBaww7M1g==","signatures":[{"sig":"MEUCIQDcNHBie/iZJtzYNnyAKLG7IVQezzeTFKiro6zsqOzscAIgHgsLfPv6Cil+75+UYksgzULRUoTMJA/750AVvupaZpo=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"13b55ef78b88d5d39e77346788ed90a08ae7a46c","gitHead":"895bce923547e2e99e5e78bba4e6a91bc88d2cd2","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"This version is no longer maintained. Please consider updating to v2 or higher.","_npmVersion":"3.10.8","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"6.9.1","devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-1.0.0.tgz_1485351531340_0.8484653164632618","host":"packages-12-west.internal.npmjs.com"}},"1.0.1":{"name":"addict-ioc","version":"1.0.1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"Sebastian Meier","email":"sebastian.meier@5minds.de"},"license":"ISC","_id":"addict-ioc@1.0.1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"fa39ac857ec3c25705749cae04478fca378738e6","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-1.0.1.tgz","integrity":"sha512-lWa8W/wpKPtqeg4ihrTKvNYhRaIoGEpOvTQNgvXO6sln/SfgU8bPc4WuxveDzNdQJ1pcVNhGY0aP1FTGHwLIMA==","signatures":[{"sig":"MEYCIQCF2vr+Vc/5C3l4qW3X8HRQNqW7g24fC792+TUzy89BWwIhAITWw8RJfHLWiCsisHVv3uPoLyYGc/v82Y3YgxxrZNcV","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"fa39ac857ec3c25705749cae04478fca378738e6","gitHead":"b14f1d81faba25120eadef2df090675d5181b161","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"This version is no longer maintained. Please consider updating to v2 or higher.","_npmVersion":"3.10.8","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"6.9.1","devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-1.0.1.tgz_1485356774368_0.9490512837655842","host":"packages-12-west.internal.npmjs.com"}},"1.0.2":{"name":"addict-ioc","version":"1.0.2","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"Sebastian Meier","email":"sebastian.meier@5minds.de"},"license":"ISC","_id":"addict-ioc@1.0.2","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"3c587c88cb261ede5f532d82785ee2f821f30ca8","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-1.0.2.tgz","integrity":"sha512-xR7yWB2RQyoLyyw8FDEiMJ93QaKhYrez6Jkruc+FciOdH+79S/gMD1X9M2lY1RX8yxGa+Prw4T7ymBW4QwRJUw==","signatures":[{"sig":"MEQCIC/+ugpvt+5pz105ZsomF8Yqo3Du6V+fC/3LlvcWaFopAiByt3bz2D8ZQQ0T8O9XMsMxDbR/+c+XE7UAMwUf0P5BoQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"3c587c88cb261ede5f532d82785ee2f821f30ca8","gitHead":"7cd6a3c1997cf6844c0829c9f43ce2c99de6dc9c","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"This version is no longer maintained. Please consider updating to v2 or higher.","_npmVersion":"3.10.8","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"6.9.1","devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-1.0.2.tgz_1485358835745_0.04679394466802478","host":"packages-12-west.internal.npmjs.com"}},"1.0.3":{"name":"addict-ioc","version":"1.0.3","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"Sebastian Meier","email":"sebastian.meier@5minds.de"},"license":"ISC","_id":"addict-ioc@1.0.3","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"dead24b92cd3cc5658f7a196dd1574e222051fac","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-1.0.3.tgz","integrity":"sha512-IYBbMM3kPQ8mldQRE8nlmmIPUUvZcKxqty2KXQJDGFokjTNKnaLhazUbbP8f48SYVG0ghMMz3+AFJACmJNnHNA==","signatures":[{"sig":"MEQCIFidvfSv8PVO3T4+0YR9dpotnrow/aF2Cw/9bGA8kg07AiBaoppyybQvYGxaZBwURw5YcBqBFWuSoPrr+PIuR6ioMA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"dead24b92cd3cc5658f7a196dd1574e222051fac","gitHead":"a62bf7ab07a7a2951021b6c489e0d98b7278875f","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"This version is no longer maintained. Please consider updating to v2 or higher.","_npmVersion":"3.10.8","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"6.9.1","devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-1.0.3.tgz_1485785057502_0.3786150792147964","host":"packages-12-west.internal.npmjs.com"}},"1.0.4":{"name":"addict-ioc","version":"1.0.4","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"Sebastian Meier","email":"sebastian.meier@5minds.de"},"license":"ISC","_id":"addict-ioc@1.0.4","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"67cc6930a1d4ba9e32bd8dff2cc67a8cdeba03dc","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-1.0.4.tgz","integrity":"sha512-yfN8n6hmHQCMRHzrUKSmclsQ5E4GfMaAvorrOWJRKx2qQs6FG/yN4WDX04f6TVPXlEtVDLP3Q81Z7Gu59C0Tig==","signatures":[{"sig":"MEUCIFheNDFJyjKpC9erEZvhFwaPc2aurJ3t5uVDKhQM4iRKAiEA1R68g5edD9uuEL1MdY0vDlEqYzUDSAt7+tTOxGJ0F/s=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"67cc6930a1d4ba9e32bd8dff2cc67a8cdeba03dc","gitHead":"9645fcd057b1909ff1d768f269c4a991b2ca1332","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"This version is no longer maintained. Please consider updating to v2 or higher.","_npmVersion":"3.10.8","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"6.9.1","devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-1.0.4.tgz_1485798757545_0.4945859641302377","host":"packages-18-east.internal.npmjs.com"}},"1.0.5":{"name":"addict-ioc","version":"1.0.5","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@1.0.5","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"b7e8f86d7c0707ffcc71f8ffb9145c55ee38a96c","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-1.0.5.tgz","integrity":"sha512-sMVGyUOOVm4efKfdvUs4NMiuCkBEjp9kzE0QFj7gqzSUp28EbYE30WuTkEXhKAZbQZyQfYwip/UYg6+s3AWZOg==","signatures":[{"sig":"MEQCIBmbzZHy9d6YXFAqkf/IRNj1KoZ+7ETOY+zPgwW/j6R8AiBHf91NhWKLNU3Nsl+ymT4NNkxuqHGzURoob8naLAfXBg==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"b7e8f86d7c0707ffcc71f8ffb9145c55ee38a96c","gitHead":"05e8c03fc6b293fde6f41175e1f56c8cc8ebec44","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"This version is no longer maintained. Please consider updating to v2 or higher.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.8","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"6.9.1","devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-1.0.5.tgz_1485853972867_0.10419717780314386","host":"packages-12-west.internal.npmjs.com"}},"1.0.6":{"name":"addict-ioc","version":"1.0.6","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@1.0.6","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"55b0b04f3734f4275758895c0d015cc0cae078ba","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-1.0.6.tgz","integrity":"sha512-IOS+H78s3xUHTkGKqL4IsDYXcJWWE0zfjcRnrLLRnSa49l2uAOKER4PxjVphTTS973QZlp/vg9w6rnv3xenVZA==","signatures":[{"sig":"MEUCIQD1LXZWB9AHaDhuMjXUj0SDNnTRkO5oM+Z1NlqdGsdB8QIgeJbIK1rMS7nkdra1MWqIpHq5kCEFX5rJjitc3uOgLII=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"55b0b04f3734f4275758895c0d015cc0cae078ba","gitHead":"28e633a092f4676582a1be951b4ff4a74d5967af","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"This version is no longer maintained. Please consider updating to v2 or higher.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.8","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"6.9.1","devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-1.0.6.tgz_1485965219184_0.2523029076401144","host":"packages-12-west.internal.npmjs.com"}},"2.0.0-pre4":{"name":"addict-ioc","version":"2.0.0-pre4","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.0-pre4","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"ea1e09420fc6f4f5edbaebec3142ac925fd3ea9b","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.0-pre4.tgz","integrity":"sha512-SZ2x9Zy15PlexowLb4OXeGRuAto2F8ygU2u07JqWvhjDrKxtoao7C0OrqAutt1MnGV/DvDxcNXBnkVMH/h8yLQ==","signatures":[{"sig":"MEUCIG1ZfdnvpEjd+wRG7HD5kyc1K+KeonJaKWH6CHV6SxxXAiEAldbZyXJhnwkCiW+CKC4yxTZz3OG1Xr2dyKjKJklBkEE=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"ea1e09420fc6f4f5edbaebec3142ac925fd3ea9b","gitHead":"b3b63ad4ad8168434cdf9f933322789dc4f1a15c","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.1.2","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{},"devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.0-pre4.tgz_1495207281003_0.23073103209026158","host":"s3://npm-registry-packages"}},"2.0.0":{"name":"addict-ioc","version":"2.0.0","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.0","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"d9e207ab1296e0bf125ed337b317350f26d54aa6","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.0.tgz","integrity":"sha512-OkYIvyiHU6LJQQH1xyS1mPV4kM3WW72Y1/5BuBoKc79sSQUoRtQqrmJjO+zRBeJmGHq6SKCdw2alSjQS3UHMGw==","signatures":[{"sig":"MEYCIQD6qMgEG/tMW0IGnMbC7FAJCKRfAhiUlNtOGFXXwo7PlAIhAL336OoYKleLI6Stmu/KAmmEQkb+O+E3q/wB3h/GQn8u","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"d9e207ab1296e0bf125ed337b317350f26d54aa6","gitHead":"e36a91e3f55186efcaf9374010bc1279d7b31b74","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.1.2","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{},"devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.0.tgz_1495207326169_0.9388406225480139","host":"s3://npm-registry-packages"}},"2.0.1":{"name":"addict-ioc","version":"2.0.1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"9ec27f6e0aa60433a8ab0c7e1ba579daec0ab976","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.1.tgz","integrity":"sha512-dWH2rIOOVGvxgr+jORjLYsxEf8LMCATlrGWdTaZA3tPao2aM1Dfmtok/yaEYWRmaD0P+o8sPlts2ZPYR7ciciw==","signatures":[{"sig":"MEQCIGmexaOB0UULAU3rCtkehwXGsV7Lv1KiIVGZAEm9y/crAiAjINzFa9Nt57AgjkSuuNik1wBHjAqetV5vsydHPARexQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"9ec27f6e0aa60433a8ab0c7e1ba579daec0ab976","gitHead":"9beb188cc79560b0082a2b8b82fd0cc61ac450d2","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.1.2","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{},"devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.1.tgz_1495268467259_0.7941629535052925","host":"s3://npm-registry-packages"}},"2.0.2":{"name":"addict-ioc","version":"2.0.2","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.2","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"4f21cfeb43c8263a5f9e209a6b646789a2009073","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.2.tgz","integrity":"sha512-Drrz4Or9LaXzXhfLzbW3cjPqP5zAT9gWPTCZiHh0sZGolI0qu2kLzf198FCcDsvDzxQHBIUHyoUDgpyb3QzaHQ==","signatures":[{"sig":"MEUCIAN/auaEnY07D7eD3sGEHNHjLG1m2CqhT2pDCgLRMOa/AiEA2Z8jCJqWuAb5LL/Ubu5zcEdLy/7YdzaiJe5tG38IQHo=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"4f21cfeb43c8263a5f9e209a6b646789a2009073","gitHead":"7115aa406a5fb9e1980f08792d4ee160b4f40598","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.1.2","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","tsconfig":"^6.0.0","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.2.tgz_1496164290822_0.48036454524844885","host":"s3://npm-registry-packages"}},"2.0.3":{"name":"addict-ioc","version":"2.0.3","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.3","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"abcdaa682be9fb569e194170649d4ac6ce5fe80a","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.3.tgz","integrity":"sha512-QkgbnnUIojM6IcG78DcOYH4gR4rHXE4tlMXoKeHOoBhpz5fzZhd2vsJ6iEtPV+vX/4ElodGXn4Iz+PpHGI6dHg==","signatures":[{"sig":"MEMCICCwEMPWOXPYGMzP+lPWAlIljX8EMXu7i7ekc1rSYH1XAh9EX9QOqQFk7MxKjhmneGyjBndWys2WodrTAXMGTPao","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"abcdaa682be9fb569e194170649d4ac6ce5fe80a","gitHead":"70821a25cb3b692d2c1086931abc521fb5d9d753","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.1.2","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","eslint":"^3.9.1","tsconfig":"^6.0.0","gulptraum":"^1.2.0","eslint-config-5minds":"0.0.5","eslint-plugin-import":"^1.16.0"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.3.tgz_1496165849558_0.7865629203151911","host":"s3://npm-registry-packages"}},"2.0.5":{"name":"addict-ioc","version":"2.0.5","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.5","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"1cf8f79714ecc793cfa17572843276d5ebadd136","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.5.tgz","integrity":"sha512-lDg0H8nIrLnBE5fNJ36nHKKXzD8G6uYzPD9N2q+EmAqPARxWokxH71MYWmF1ZNSkALwA1XtY8K7CpC1WYFGfUA==","signatures":[{"sig":"MEQCIAI2HkyGsqeHOYhwHcnZPI2J0b0KfvTMR1ziURVAZJzXAiAD4hyzCt2Eq5lbde9z2575P9FTbO7XzbOksOAJDTCf1Q==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"1cf8f79714ecc793cfa17572843276d5ebadd136","gitHead":"545b64dafdd84f3d1082dc54ddeab62bfa6cce0f","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.5.tgz_1501485960094_0.9905269364826381","host":"s3://npm-registry-packages"}},"2.0.6":{"name":"addict-ioc","version":"2.0.6","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.6","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"e064ad963cf63af8fc8e365087d11c493513c847","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.6.tgz","integrity":"sha512-YY/Yl9qcONR6BIJEi5/KrAM8BL+YGYC7Pc03YXgehF2VDjngqfCJ2nJlv7R2Rij+RdX3LRb+8dL7xIc6igT1mw==","signatures":[{"sig":"MEYCIQDOKWnXsJoIR3Itk1AJCUkkFf0oiXNzcaE74wa3K86ibwIhAJrn/znB6Z3qvuZayHt5ahVVC5HsrxL1n1+HlRbzRRJ6","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"e064ad963cf63af8fc8e365087d11c493513c847","gitHead":"405a43a696371926d978210d805ed668796deaee","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.6.tgz_1501492926470_0.2593156599905342","host":"s3://npm-registry-packages"}},"2.0.7":{"name":"addict-ioc","version":"2.0.7","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.7","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"0d9d20612ce0e7d8dfa7b3a8c961940ddd0ddd89","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.7.tgz","integrity":"sha512-3Vb8C/2uGu5FXwna4x+VMa0bb6DMS32Wy0eRKIGanlJ1YIO15esj307pihbWEvFpMvreLkyqpYhdHEI0mPJAsw==","signatures":[{"sig":"MEQCIBLNFnxMcv4gZiIvwLQqIxvJUXUCVuFXtFIeuK/i/jjnAiAvPUOgpMAP1Fwc9sOrioYWblPE1NmNwl0Gg0b5fWHPCQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"0d9d20612ce0e7d8dfa7b3a8c961940ddd0ddd89","gitHead":"6988f07f32c33f8f8055fd9f2ce7e1d6f9a4b5f7","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.7.tgz_1501601534061_0.5577607369050384","host":"s3://npm-registry-packages"}},"2.0.8":{"name":"addict-ioc","version":"2.0.8","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.8","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"410aad3a2cedb1e3c92b831ef8a9924a17595bc7","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.8.tgz","integrity":"sha512-nRCfCRCQ1laOOulTHLSoXn3iqbGwS7wFft45HDuX4y8Tpu0NMrXQ+89eu5ZFpTFhoGp32mQ3jVNywFgNGKmn/g==","signatures":[{"sig":"MEYCIQCjk8+mXSz8eFRb6V8yUpNXV4/PK5SvOGX3hbNiDuWaZQIhAJ4OtzKaigHDb5nHw2EfpPVQSvTBWV/ACMDgkUQ0LgVt","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"410aad3a2cedb1e3c92b831ef8a9924a17595bc7","gitHead":"fca4f8636e4dd3239ee432ae9d226bfef1a3a6d4","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.8.tgz_1502199971574_0.7860920452512801","host":"s3://npm-registry-packages"}},"2.0.9":{"name":"addict-ioc","version":"2.0.9","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.9","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"4ba2cfcaccaf3326bffbcd7395b07a08a77bc664","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.9.tgz","integrity":"sha512-cQ1gr3FBby7Q5TCk84eIbPjpFl+sKMmuwxMC8FfpYL5ZiE5ZNXqWXJK6qAD0xF4/MZ7v9vRPRCqmepwMEvN5qA==","signatures":[{"sig":"MEUCIQCvEfv/Ne7XeBFZRgK+pWnm3B/rxEM9EeCAjNyWk6VOdQIgY3/TsAjW7+EnBxFottYCb8sOPbP+91JahWdn9Kn48ss=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"4ba2cfcaccaf3326bffbcd7395b07a08a77bc664","gitHead":"cf469f13437afabf5bb449cf30535fb66e59b2f6","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.9.tgz_1502352044697_0.7936343345791101","host":"s3://npm-registry-packages"}},"2.0.10":{"name":"addict-ioc","version":"2.0.10","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.10","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"93cb4ca694329665bcbcbd384e05f340d9a47ee1","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.10.tgz","integrity":"sha512-gMM+UpC2wRG4sLxW51IrXyxwS4h9Bz0v6VeQzlODA+oCPcUDn9o6Ll9fvvJIUSAjii+2fN9XVihXUsfIiB2ktw==","signatures":[{"sig":"MEQCIFTIRZCTJcNDODWDBvqI4r02s0YtyNGGhbTwzoFatw2JAiB8ndP4nEF3uZy9zbfHp1HyYfFYxRMkYVF7Ha3szh+aMA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"93cb4ca694329665bcbcbd384e05f340d9a47ee1","gitHead":"865a737e78fce59d98f14a9593285234ff3b43e5","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.10.tgz_1502355799585_0.0760546294040978","host":"s3://npm-registry-packages"}},"2.0.11":{"name":"addict-ioc","version":"2.0.11","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.0.11","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"560f756e5048e0ca381b4634e689e6ed2c4c536c","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.0.11.tgz","integrity":"sha512-jyu7rFMHy21L6dOIdYIRIinVEqJYPl5hp7d4j6OVD4svcGgZFAwtKOD91fPu9LQvs6MOmodqL3yKspTctLKfJw==","signatures":[{"sig":"MEYCIQCWtA2EWaNN5wBcSEB86OeIdeiwuf/JomxsD+WsLVrQfAIhANFk5aM5Mw/eZMF8nc4UmpwmBe4APB7zzY9tBnNUviFE","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"560f756e5048e0ca381b4634e689e6ed2c4c536c","gitHead":"68a944637c1ad4db1b2aceb824ddd8c1ae98497f","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.0.11.tgz_1502368482622_0.0003523612394928932","host":"s3://npm-registry-packages"}},"2.1.0":{"name":"addict-ioc","version":"2.1.0","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.1.0","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"65bfc6d1b25722bb864db11ca1f465ae7dd64149","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.1.0.tgz","integrity":"sha512-tGGsa2d/ULfR3AmKgnMjNdLUABbwbMRmovIWHJl4dlDFuIzFjcVWW5SP/NUkV5k26wnSXEqY0/vlSdkp/28V1A==","signatures":[{"sig":"MEQCIAJda+unM+hhGrEWM5FWDtixqOYCzz2+aKd9frUyXDt3AiAaTLziQ8xM3je8u5XvWAL4m2Fef9F/uIs4QfVbglRAYQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"65bfc6d1b25722bb864db11ca1f465ae7dd64149","gitHead":"644560d234ff7a483434905e1272ca9862ea7d27","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.1.0.tgz_1502450831236_0.5852361454162747","host":"s3://npm-registry-packages"}},"2.1.1":{"name":"addict-ioc","version":"2.1.1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.1.1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"6ef1fb06e67fa996ff117de0eae6d5176b5c268c","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.1.1.tgz","integrity":"sha512-8b+lVC1nX8aFHt2HGkFBwy822rzNlyGi8ELFbANqCT+nS2hrTmDHnAEJDIW0Xrqm4i9Wj6gYXvKjhiwxGE3KiQ==","signatures":[{"sig":"MEYCIQDij6JcMVxqSkeHHs2hGr+cq1hwXwsQffHGOT2B7ApQZwIhAIu2ZctskpLjajbpxrCP+AvIX8g7pdysH7eD9IdMRbKl","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"6ef1fb06e67fa996ff117de0eae6d5176b5c268c","gitHead":"2a968ca04d2fe9efc676be5f68812593140eb69e","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.1.1.tgz_1502452573829_0.7355383124668151","host":"s3://npm-registry-packages"}},"2.2.0":{"name":"addict-ioc","version":"2.2.0","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.0","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"e18716f5ee6384f0f91a624f9e293b1f7555ec08","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.0.tgz","integrity":"sha512-iDoKhGyPGCxNMfyGIGDxyAMb4lEy8mjVp0q9Qbb4+dcN89mq4hNlNGQICjQ6SMjU5RelbhTDjNM2iimd1hEs1g==","signatures":[{"sig":"MEYCIQDEMS4PH9ugIPX2p7SkOTlvj8wT6sPhEdWVpoxaJG/68gIhANaOfpcmJXi5PBhKml/fA6OwcbV5Fk36Xa6hwk7DVXnA","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"e18716f5ee6384f0f91a624f9e293b1f7555ec08","gitHead":"074a3e37187996a23ff5a9edd9486ad271540b55","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.0.tgz_1502463973826_0.4574722631368786","host":"s3://npm-registry-packages"}},"2.2.1":{"name":"addict-ioc","version":"2.2.1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"8bb7aca6461e516e8a19fd1b2738346a91a62b75","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.1.tgz","integrity":"sha512-6vim6EbP3H3oTnXV2Kn04P+RJicKrsxIbl9KXSlIfmK/VKbivC8+K+LEJE6g+f9it/sDN3PMqEDwjLSmgQguvg==","signatures":[{"sig":"MEQCIHlvh60z7IVpJ6CQTGiVjo3MyL2y+N204qXgGJ5hgBDFAiA9xs8h1GbgK1rIDfS2KyrbWqhjzh+M9zEpjlybQv2yaA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"8bb7aca6461e516e8a19fd1b2738346a91a62b75","gitHead":"b746eabdba1d663fd51811f4841a07bc665ebb90","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.1.tgz_1503067371127_0.39458886277861893","host":"s3://npm-registry-packages"}},"2.2.2":{"name":"addict-ioc","version":"2.2.2","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.2","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"90e26ed6a07d298bfa4af6e58bd96b0fe45540b5","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.2.tgz","integrity":"sha512-Lse5xEmOsFgre7bset4Gu7DkjReSuI+pKBKRmJFD/EQTaY3ff4YnzDUUQsNNBrEMUJimIA4L3cNseG3vpFSR+g==","signatures":[{"sig":"MEQCIA1Viis95ikPtta23mrg9/Hk5m0bYTSjPTKQL3ykVqUbAiA5uSd4USN9tIuGjI3iTKqYybAjEr0bOXk46ssXYFIrhw==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"90e26ed6a07d298bfa4af6e58bd96b0fe45540b5","gitHead":"a60224dce938baaa968fb289a06e9fa2212e1c31","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.2.tgz_1503389299529_0.08117578295059502","host":"s3://npm-registry-packages"}},"2.2.3":{"name":"addict-ioc","version":"2.2.3","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.3","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"17ee1c5014ab3353221c3e3418a87f89b418e34c","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.3.tgz","integrity":"sha512-V/KWv5/b6lM/e7hIn5RlnRb8tCmu9EFYcgLqi4Mq4DRY6W8YuMkwP/d1nmc9xSml+7PQi3MRnS7jbJuuMs/BXg==","signatures":[{"sig":"MEUCIHmvyJjfkxMmD20QuMhIxA/+9vO0KWe7N3urSUUvTSOzAiEAkkWBvWksAmcUMBKP4oNTd3JuX0Oi8vZ6gNxuor+7nM4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"17ee1c5014ab3353221c3e3418a87f89b418e34c","gitHead":"8caffca9c6f8608533265e1bf844c9d21d4ca7a3","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.3.tgz_1504011524832_0.688406074186787","host":"s3://npm-registry-packages"}},"2.2.4":{"name":"addict-ioc","version":"2.2.4","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.4","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"9347a1858eece428709b42e79c1781ac489e2078","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.4.tgz","integrity":"sha512-JLoMZ+jePPkiftUkAPv4MrTBl9o2SBsEkhDv+J7+5ezMVnuxzUCB4doTfcZLB+9x349FMeOBk8EYmwkw43nvxQ==","signatures":[{"sig":"MEYCIQDhJDGtiC3kUbg2uTsUfLWFZ5dLiXf9hkiHKLdruuT9gQIhAJ2zKmSHqZqVRT/NHEd79EXvUXpK9dla8EOAIuQ4dxNj","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"9347a1858eece428709b42e79c1781ac489e2078","gitHead":"a028b179c66de7b646e35f7b022f47317490b853","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.4.tgz_1504016670823_0.10979465302079916","host":"s3://npm-registry-packages"}},"2.2.5":{"name":"addict-ioc","version":"2.2.5","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.5","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"e802f5a526f356e2291dfda0b1bc3c84ba7d48a3","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.5.tgz","integrity":"sha512-2D4e1AMYaJO9U4N/rpkuzb/vyNFhydl8N0zbIdXKirmn+nh/bLuAX9SKlC4S/3hiROn9qz+6TGyHJJFo0IKdbg==","signatures":[{"sig":"MEUCIFqKvlOOA0IkEn3qOBIEvw/xd/epWQbAH5C3LOn4A6UFAiEA7vyxtouviUVWvyxDHfASbQJ/KxBFlejfira5zbheUdg=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"e802f5a526f356e2291dfda0b1bc3c84ba7d48a3","gitHead":"60dae8aa5846acb25c1700bf9ef54249250d7fcf","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.5.tgz_1504020438515_0.22760114562697709","host":"s3://npm-registry-packages"}},"2.2.6":{"name":"addict-ioc","version":"2.2.6","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.6","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"a29461694a448f5b624ae2acca961dfa6449f377","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.6.tgz","integrity":"sha512-sNEPDCm5OInp82zpSHUDSzR3ds9jUeKfPjq6ZtQ3H0Kx/8XxgwM1iVEMtWqK5NV6B1ysKUzncp+bUBHUkvRwNw==","signatures":[{"sig":"MEQCIEZrk3IZ9MLivNq4rqhgjj6t23RFId8+y3hMPbsCDKdwAiAlQXxo4k+/Uf2VhzwjpjZrQAjO7GoD+/GvOWbeyuo2tA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"a29461694a448f5b624ae2acca961dfa6449f377","gitHead":"e7522209542379032a1430354e922030e29ccd0c","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.6.tgz_1504075929658_0.10558619815856218","host":"s3://npm-registry-packages"}},"2.2.7":{"name":"addict-ioc","version":"2.2.7","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.7","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"068365897ee306e4201a99ff158f6437cc781f0d","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.7.tgz","integrity":"sha512-fatL/nsiANpkWJ+yPoh9981OSGQkVcf39AYEFd7zfG93soWNgPyq168bUmZ5UyUYjB+M6Ocox6h4qb063ENkYQ==","signatures":[{"sig":"MEUCIQCmsMycCu8VAquWa/eNvQGP3UVvuBhyBr1bD1FKBIHCtgIgar1HJSIfqDiTALSXrgjxKOn2K60bkbEVAoBYzfn2xo4=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"068365897ee306e4201a99ff158f6437cc781f0d","gitHead":"34272299dccf6c6269d277b22b136b8f4039d270","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"3.10.10","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","sinon":"^3.2.1","should":"^11.2.1","tslint":"^5.4.3","gitbook":"^3.2.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gitbook-cli":"^2.3.2","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3","gitbook-plugin-collapsible-menu":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.7.tgz_1504255165982_0.5424513195175678","host":"s3://npm-registry-packages"}},"2.2.8":{"name":"addict-ioc","version":"2.2.8","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.8","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"8d99eae038275a4fb3a052486051ba8ec3205b26","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.8.tgz","integrity":"sha512-CNICsaFm3aDaN//PkK2ChqSTESOFlNy7NOicF+0P4RRqASyXf0yjCi0eUSuKuBp1yRv9hXpsMxRj1Ia2t349JQ==","signatures":[{"sig":"MEQCIExa+eI8D8kZ6+cVHKQGRCpdmTXdgMMqXlQZXGm55ta2AiB+w4KdIGMya/Im3/ZUIHMkITW0Ni7X4d1toVd+JtFdbQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"8d99eae038275a4fb3a052486051ba8ec3205b26","gitHead":"680d8df1a97eb634b9669cd0ba8cd162f403cd8a","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.6.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.8.tgz_1504891607034_0.12880450580269098","host":"s3://npm-registry-packages"}},"2.2.11":{"name":"addict-ioc","version":"2.2.11","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.11","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"8b9401663a0fd59d6ef0086e91f8e78050738c42","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.11.tgz","integrity":"sha512-mp3VQMrwxUNwDY93WkMi2MnmXsej5h3iYY5nMcxUVbLAuDG+aew5UbcJ09iMQMTEA7oaH5M0CP4B80aDf3mhkg==","signatures":[{"sig":"MEQCIBuXIj+DwblXpe799bEpRTb1ncQSvNT6qQEeVPTrJVufAiAyv8hRSNTCszvg/8C6Uu2z3qOFRT6//XDLS+DNAJEQFw==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"8b9401663a0fd59d6ef0086e91f8e78050738c42","gitHead":"1d5bd80165f168c1c833c3e59d78be00c98cc295","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.6.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.11.tgz_1506972184711_0.5189860954415053","host":"s3://npm-registry-packages"}},"2.2.12":{"name":"addict-ioc","version":"2.2.12","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.2.12","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"34f04f2f27fbe973c1df7ebd8d31ee79e31c6520","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.2.12.tgz","integrity":"sha512-v38GZZvSq3PIg8w6V2h9uFI5nnvExnCWCiFiVan0G+v0izh9/sybj68GZXzBY4r7Tmte1SejWtGHITTHgpoNhw==","signatures":[{"sig":"MEUCIQDOQvap6gfuyj7MliiJBFxZQJcQonmnoAEiXKqspzyWdQIgX9maLchivA4AWtokHFg7Va6BWT89r7hCeDDH9bpFK6w=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"34f04f2f27fbe973c1df7ebd8d31ee79e31c6520","gitHead":"e3e52bd14bdfe085fbeb2d7fe9a43d00ccd08983","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.6.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.2.12.tgz_1507013375836_0.42073159688152373","host":"s3://npm-registry-packages"}},"2.3.0":{"name":"addict-ioc","version":"2.3.0","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.3.0","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"c552ad9c167dc6f97a0c72dd631e86ca55f8ffe2","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.3.0.tgz","integrity":"sha512-1dNxmzv4QerXoQ6ejMsuLgYPNPLRtRYnv+uSifj8EWbimYwYTHjvIV3YKQOarEg4YMHt0zH8QaV+OMuIfIiPIA==","signatures":[{"sig":"MEYCIQDCYSHLdBl+a4hwBe+389jfrqt/tJxNZd2jaUpk8McKaQIhAPttenXsUODG5S3/sH0Fg0ewDXjuTYBHBl8tcL8eRzkt","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"c552ad9c167dc6f97a0c72dd631e86ca55f8ffe2","gitHead":"65014aba86120933ff0e70a89da1c6e8f67c1dc7","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.6.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.3.0.tgz_1508339425677_0.18099355977028608","host":"s3://npm-registry-packages"}},"2.3.1":{"name":"addict-ioc","version":"2.3.1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.3.1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"0629afe1409ac3680e349edf2a8e720339a33986","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.3.1.tgz","integrity":"sha512-Xt+o0K2xQ+VRucTx6GN09oc0LD2ghiLfhgy0VR4bMGnwwQVi0pGRPitQIG5MvmfYeitfrTXBHwFOFg4ai9A1sw==","signatures":[{"sig":"MEQCIBAtk9o5C3S0X8XQiJpNsU+qw5lghIvV6FppMowpT7fcAiByiCoPaEeSEXgsKiZ9n99bj+WKDyfFA7+ZRv2I9CfLwQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"0629afe1409ac3680e349edf2a8e720339a33986","gitHead":"d7de4df5db99f6d0c5915718a1b826c305f3ec0e","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.6.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.3.1.tgz_1508339797155_0.25001978827640414","host":"s3://npm-registry-packages"}},"2.3.2":{"name":"addict-ioc","version":"2.3.2","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.3.2","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"11d2d1c922e714b83a8aa1a496a4a2401c8db9d0","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.3.2.tgz","integrity":"sha512-0bQ3xiISMIE4JGBMmWl8vByXvi0YYmy0PnktQ4DY1VV5PiKgU1/nqJAD97MmxlGFchTtIOrNVydyNB3Zq9YKfg==","signatures":[{"sig":"MEUCIQCLAYHQjvicixGWsdbHJuS5WhUXqt88QqMtP/UURWsPbgIgHljbXEXApqk9mFhhU1MlL49VVgMvpv8tC5ExGAHluus=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"11d2d1c922e714b83a8aa1a496a4a2401c8db9d0","gitHead":"ed2216c02771a5ec68835c56cbf0593367d9c072","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.6.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.3.2.tgz_1508340303374_0.36359146190807223","host":"s3://npm-registry-packages"}},"2.3.3":{"name":"addict-ioc","version":"2.3.3","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.3.3","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"aaead0982263b3fd47d359fa3eef9ed84204f524","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.3.3.tgz","integrity":"sha512-5FmyjZqotPkavBgFA6jkeuEmByyjO8TY/55LkiNMWq6BiEcz0uec1dBJ+Qyohc2MrJnRW58zLUXtfgw9lwMIyg==","signatures":[{"sig":"MEYCIQD62k6dV12O3wQc7NxFAezFz8/nCO3PtWM9mnWehXe8CwIhANQFaKpADRdJGHpaf5Itm3VfHZhhiGfiNVlZTG5ejN9l","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"aaead0982263b3fd47d359fa3eef9ed84204f524","gitHead":"7907ec931d3dffc4147ca7d526ca4807f0291cb3","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.6.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.3.3.tgz_1508343461700_0.7128372739534825","host":"s3://npm-registry-packages"}},"2.3.4":{"name":"addict-ioc","version":"2.3.4","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.3.4","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"5b76962689e205397f6ac53e85ce387ed9435e80","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.3.4.tgz","integrity":"sha512-nvGdVjvUDDCBcq8U5qfqMnJgeYE2EPpFiV4JlL8m2aRDEufITxbSsEF4XXtSFK6w1IdgjmH+XqM1RIx0AOiZlw==","signatures":[{"sig":"MEUCIC9ip3HNOXmd9d4G8+wf4DmCefgBkHkbzr79WoszFqStAiEA8rwtinh2p8AG+8HAIrvfZABNZIX9nKAoNYhRYon0mUQ=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}]},"main":"dist/commonjs/index.js","_from":".","_shasum":"5b76962689e205397f6ac53e85ce387ed9435e80","gitHead":"81cb2aabe4072a4a5b06a969a186e307ede8c55c","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"4.6.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"7.6.0","dependencies":{"node-uuid":"^1.4.8"},"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc-2.3.4.tgz_1508344347375_0.31787820532917976","host":"s3://npm-registry-packages"}},"2.3.5":{"name":"addict-ioc","version":"2.3.5","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.3.5","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"894d980ad1a3544027b090cff6742ec6f7d17d61","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.3.5.tgz","fileCount":186,"integrity":"sha512-hY9URs8B75zN7qBEll7GCguS6cBeB5IXsiTmjjX617byjOufGKiq+EuJ/YIJWLGCzyo72NLroI0GL/kJRIx1Pw==","signatures":[{"sig":"MEUCIQCiOk+ufX/vdhBUoiiH6EzcS1d+NAS56ClIPOjW4Le7BQIgaC7IBj76NN043psY/1somyY7wLPvVEWZFxt27qw15iY=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":3585364},"main":"dist/commonjs/index.js","gitHead":"977e8219ec6245eb3335df7b4cecdb6ed72ea26f","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.9.4","dependencies":{"node-uuid":"^1.4.8"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.3.5_1518452166482_0.46295717746834786","host":"s3://npm-registry-packages"}},"2.3.7":{"name":"addict-ioc","version":"2.3.7","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.3.7","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"b9b4a496e4d99931af46ae836eaaef42d6167f9a","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.3.7.tgz","fileCount":186,"integrity":"sha512-+xVFqe3mpDFM6VyGMVXdoFGnP6zGE2RAbqbfJWS4KLgLO3ZaPq0kV+AJO2/mVc1HFZUhttrXKNHlluAoOzST2w==","signatures":[{"sig":"MEYCIQDdHh7pUj5wqqnJB2zXuKLy+uFw2C4N6xdDqtaxxXnTRQIhAOzy89x2RTcM1tru+wIkSHrpDARtkRRaDq3Wp06Jiqe4","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":3587219},"main":"dist/commonjs/index.js","gitHead":"9ec0e8adfab1b6b07b611061ac47499340cefe0b","scripts":{"test":"mocha test/**/*"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.9.4","dependencies":{"node-uuid":"^1.4.8"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"^3.9.1","should":"^11.2.1","tslint":"^5.4.3","bluebird":"^3.5.0","tsconfig":"^6.0.0","gulptraum":"^2.0.0","gulptraum-typescript":"^1.0.0","tslint-config-5minds":"^1.0.3"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.3.7_1521131182849_0.9447472122002627","host":"s3://npm-registry-packages"}},"2.4.0":{"name":"addict-ioc","version":"2.4.0","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.4.0","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"29b94a34d68ac4b3e338a5d91a2f4763bb247962","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.4.0.tgz","fileCount":100,"integrity":"sha512-dtJHkxEGqDMcTnhP5L308ik11kgO2HLLEUbe/olhOIM+w88Suoec88INCmlgjTpOzO1ZHUg8k47RVU+rpX6XUw==","signatures":[{"sig":"MEYCIQCeW2O/oUEVfPbjJ9l4YX0yo/BttXRrojmWEfDGju0FiwIhAKuYa0E9iavQWj4hCwKq207xj+RLhTvSDim38moi1/Fc","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":567228,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb2afxCRA9TVsSAnZWagAA5GAQAIgoOE5hAIHKuP3PqVrR\nQPlK/WWm78AeK1pn+AmMSEq/k4YDxP6vvRHb+aFiWZopw379bgKbhVS7NevO\nb+h6to5isjXQ6zBNvxnOnZ2+JZ+stzdCbYF5sQj6JzwdowPIHdFAYxbE4ZcY\nMTaupWYIhu8G2YYcjfGjXRxZ30N5BBcjAtlfxcb9VxX9bAnE5w4P8IJnPd9Q\nZFOCzTl3BwlBcVuflsPdJwMi3kPMe5wz5z+dD+suF+X3xjtkmkOztIwSr5Uv\nJ5Dl0WVp3IwqeST4mOYQAT/CGIiy+vv9//xSLCJgO4i/qqELEAwbKWg2tEn+\nBxw2I0LOSdadxWQ57SoTQ+WlNeLMb8T7SD9EUd/rpkpZyqhtIn4LxT3ZUrLG\nGzBpfRjyYttF1I1fpIldTxYN0bIywwvn9tQFQ1DIZ3HysDuVYISxxaRowDU7\n5nMgf0TMzBqSkR3x+cpM+BPhOJuMv9o9EX/S/tUQ1oR1zhS0Fw07eIZHiJ9d\nAOSpKHDaOcUNLZvBiNW2GPf95R+vyg2Lxy4EoIqNkquKX7rynQISkgied9L7\nLHorugigzzBjtCqv7SJMmos5RNlJzVFRKWNA3lV4sXXh1qDG1ckz57NjiBlW\nSAwohGEXKPJI6mlj+4N/rRTUSOXQSvdbEOMhS2uF0FSZ3oVEa6rd0BxDwGjb\nwxt9\r\n=DWT1\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","gitHead":"4de4101636f0f2f9ee49c5e3dd552e044356a0e4","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.10.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.9.4","dependencies":{"node-uuid":"1.4.8"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","typescript":"3.1.4","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.4.0_1540990960824_0.6362742612005519","host":"s3://npm-registry-packages"}},"2.5.0":{"name":"addict-ioc","version":"2.5.0","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.0","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"e7b6281734206334aaafedede3c55e861d3261b7","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.0.tgz","fileCount":102,"integrity":"sha512-ojNRP/MgjX8hdmTNtK4kapV8wIQWodm18inHb8V2TxJQvQBkB4VgMtlomL0j/eVhlMrFALBzY+sPlMuYPmJ7gQ==","signatures":[{"sig":"MEQCIBvcrBqvoesJSXELxghh5nMKUsdX9tBd8lovZKxjE+jVAiBu2DWRxNIQ6KWy7me3TuZk4oFPiRn1MP8xKU2tGkhp8A==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635483,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4VVUCRA9TVsSAnZWagAAYWoP/iqP3SGbmXamXbKqqlB6\njwMv6JOiP3G8Dx/uq3bpo4MM2hP7Jb1e61RgDRjgiTYzFUnc8OkAB0D8kDPF\nG3D7T2zBkoct5NokO/53hcWLNFug1ecSZkZ1abhNNGzfOQyg1ZKM0f9s8dHD\nsPV0NgAK1Ci/9nBym0ZFE2vdot08S2jpt9AIOHae9TWWONFdTqqgvL5F0S2F\n6Wmt8NSyjFkrJd/RcvbY+wL0HveFKDvfnvEaMyZWWB5P3EWs8fs+NhYkOzGF\n8QnRp4I+3wCG8PWuSZ/zoUXGqExFpf4YIl422dxg/cQtrxwHjNAHTFWpYe4s\n3Fp35YX6f6CBLzsT50ACPkcazyfSGT/Btl7FRMHAD3chMkzU8gKjvsT5mxly\n0gnXkjnGaDJK5RvtgNsEUY0C1EWDJbbPAoLfcL+XhwAVj1QsmG035WN/mMlu\n11ahEIYCJr9Iaj9D8rYD5ssVwerrVmgxpC1iyfftkOcMwju4S3NdV/eQSseA\ngy1AihDGraaeqQJRBkGZ1i18uFrWYR1VqgHfIXDyurY6vQJrw83KeUwGtvFE\nDQE/upI30UXSUsxieF+pn2LdegnQ8jSRhWWUUUiBlhhTY9z9yAjS+XCyLj/u\nbgwBw17F6Z/8/0agcr1B0KuQCDPmxoWedCCimM/0ysziSH3timB72oKDF/J7\nOKJN\r\n=r8Zk\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","gitHead":"5c2de7cb29c0e9216dc7294c05a9da15ee12979e","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"obivarg","email":"christian.werner@5minds.de"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"6.4.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.9.4","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.0_1541494099871_0.2710437766276266","host":"s3://npm-registry-packages"}},"2.5.1-8e3dddf1-b1":{"name":"addict-ioc","version":"2.5.1-8e3dddf1-b1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.1-8e3dddf1-b1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"95c12f0ae2fe7d387c876d6d521766b3ba4246a7","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.1-8e3dddf1-b1.tgz","fileCount":102,"integrity":"sha512-T/Jiq1nW6/p5+hR0RYjK/C7Q+FLqM0g+F6fOS8j2n+z5e5zzO8EGj3k1VIH4U9HyT3KEvJd9oWS907V/Lpq+tA==","signatures":[{"sig":"MEQCICHjkcVtwYdJlANbBhvk8Im+Fv0hRNcMViKJX/CB/B98AiAvf+63w5Fav2P5E8Hd22jtPMdTsISeWtfgOO+cGE1fYw==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635571,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4psgCRA9TVsSAnZWagAAXncP/AsWxH6qwjAnmcw25U3O\nON+duvMVLLkk+GIWYX08BKdFE1sKjmVg8j0jUPL2eYQkcqam2jd1fii8Uvf1\nBT7A+7GOPdReFM2D9P4dDQbz0DAK5s/yXMa/qyyL/EKD22C6NkEOsbWgTHU6\nJ3XDGs2c7fNepUCIenaofVSGDzK7BLWTlg+vPvJJatEPvcP7ERu2OnWiCuIa\nhcee7ZfGXB5AEh8BtoDl9mV9A3cJEHeQJgROLq4BsQPKcuOImM6S7F37tNuy\ntWqwXn28BZjVg9UdTG6ewIIPBahsK+Va8OoSKEvyd++Ek/hdnv1Myz3nc8tc\noXPU7XAg5fzuUJE27lCqpGTX51yx2XFby9W6UBIb+cWP2pEFwkEwn+OX6JxO\nlGD4bIWRdlwaN7xUOQpXazl1z0/wJXpSIoK8UHI14aiukucWAKehPdWwxyT9\n5PqfW3un6r19QRmBtvzBZYOIeR9OgFTF3P/ASJDAxwllzFYqK/f9DUAV4g1e\nXajxiG362JAx+QKh+KcKk9sYBwUdL7GQezkjbpjrpFDGwgdw2oUK1ck0abX8\nOxgNkJpWfP1LoKTUH/ZEdUPxtLU+M4ITHgviWSsPPTi+fvsKx8lGVQ95UlrL\nzoZIG42sotvzKH76Nq4AYOai9P7yCF/bSVItdnAbFHn/xkaIJlODB8MhBv3R\nZsnm\r\n=BTKY\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"8e3dddf14b7e7c2748983983a27e2a054392eb30","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.1-8e3dddf1-b1_1541577503431_0.49953878955695186","host":"s3://npm-registry-packages"}},"2.5.0-5c2de7cb-b4":{"name":"addict-ioc","version":"2.5.0-5c2de7cb-b4","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.0-5c2de7cb-b4","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"1d2c1a4bf432eb54444675f49f1374fc0c33c3d2","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.0-5c2de7cb-b4.tgz","fileCount":102,"integrity":"sha512-fveehGbUm1P8n21BJO9mkUxw3no8pINx26vh93rRUTmqaZLzICx5e1CwlsSebjlsb77fceh8F+WCIolhdQqvzw==","signatures":[{"sig":"MEUCIQDhukCPG654Pn5RZa5RnlcyZGOuksJipuhF6OGq7ttJzwIgMS1S/W6LIvwEn9MZmGII5D5fD3E3Ihvj6W/SRhlGMV0=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635495,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4pspCRA9TVsSAnZWagAAEegP/iBXP6zmLLQIhXt8bkL7\nnKQTKJObgdN5Xsp/nsh98JksaoD8FJvqziSfNl5CBxthwNNVFBfXhhPsKSar\na+PdgUrKW8MjQpUfXGKzmh8DkyCveGG5vX5qZLScbSE/DjUROX8tpK8L1VNj\ny2vBG6xgUE61YjTwftTFJr9AI8pyA7+cGMGc2kROyT7osqmr/WFcPcQzt58h\nX/9C620h9hGv6RkeHN8G4UaBLrOXcKFOR7FkywH8Y6THi8CxVJ/bvEkYSWrH\nZwaQe85BGDbbo8a1GUJyPPodAt+r3HbZTCJEMMbUAQDDpkCltauFBuDxDmRP\njIXiIiu6WyYajDyDhuBdVrVfZ6kzr1i6Cg9YXjPX43LfGeHgvLfA8fs7z4Q5\nbOXEPOIcyqnHxxC2HO2c1ykjP3lGD9ixkc9frZjBj5Pz4rxzO+wny51SMGDf\nqJ23NF0sV3TvxsbBVz3O7uAoWXU2PHQgxLy3KBa6kGb0Ck6VaoRnVOmGC2xW\nY7JyS2IkTimIFjFCNqZTxSQ0vW2NNVVg/wgLAB0Fs8PE2B020eEpTLkXBTuv\nlB9FbtS61ztfllx3Lik/YUECBdERe7irZsgp7+wAfJUWvJHJH7hB9Y5brGEF\nT3n1/jtA6/C3aZB4kPvAJhZA4cZD/cNMm1Nag8XCelak+UqD+UGu17564m2x\nCKFG\r\n=vbc0\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"5c2de7cb29c0e9216dc7294c05a9da15ee12979e","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.0-5c2de7cb-b4_1541577512514_0.6417145300021756","host":"s3://npm-registry-packages"}},"2.5.0-5c2de7cb-b5":{"name":"addict-ioc","version":"2.5.0-5c2de7cb-b5","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.0-5c2de7cb-b5","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"432d48debacf9a476fe415ca352b7de0db391d37","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.0-5c2de7cb-b5.tgz","fileCount":102,"integrity":"sha512-al+DntfM9MLVgj3e5pJ7jxZkaI4abJA+wyWbF0hzJkZ8hDxIHwqfvuQD1iYhuAYvAw+8iRGtOz1X5YMr+YXCCA==","signatures":[{"sig":"MEQCIGQ/Ndl3ltARHVz5wf52z+MZwVaRw6U/FJKZvO502whmAiBiQ0cAYF0KT56OC9CmTH+zXUckQKC6Ome0wrP1Zg9vig==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635495,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4pvJCRA9TVsSAnZWagAAwgMP/Aup/mAjWGsW5kfBvYwn\nsLx476DnaN+XSMEpmU+E3RPy39NptecYlFMOdcmP+dlu7ZiP8bPkDtIbjcz7\n+XoPJ/sE4K0MrO+dtpq+hGHfntpKt+bs0pcrOjjUGjmnSRh+jO4VziavtHs8\niuq0qAIU99t+UsMe0aI3maTaazHm2ZmJutNUN+7Y+9CMYTaHfOxQmIaLNec4\nqS7GwL15udWnR2v+BQiNm9/dN4Nnt2q0DhMGTXT2x9IMpf//d72+Am78OBOJ\n6P/m7v0GlmbiWzPICQIIRXm7jYgUEtfwZkhU1wchT4qF1Ik2FOPi6VOr7VyT\nBeLr0g9p3HtRCsR/78vBlyBIugm7ZGHgJe+XZL3RpKtQ69InYcYSqQ9ze5hl\n9DKWdKQtZkoQKAGc21XjadjSDuOJhPAG7zwbfzbbSJ0oa6vG61eMoVooM09d\nCthUoxUOhaKWhHrb3b8fGyugGIInyvwc3GdMmbRF80P8uBulQsQU32k99I80\nlWIVrhZ9Zdl8+VG2Flc8jlHvgm3nJUwkLFUGCUJhBfnQKCM1bDymWRfhwBgR\nCYcKZusYGV9wekRvpooJ9i3QYuseqKKkSwBZtcSHoSjC5GOEH3GhP+32rF8P\nqO9Ef8QARcZ9axWPD2lm5i0r2JxoUfFx0HtdLtqnNckE/jFyUu+YID2KmFwZ\nkigI\r\n=xiqZ\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"5c2de7cb29c0e9216dc7294c05a9da15ee12979e","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.0-5c2de7cb-b5_1541577672335_0.08194229576191181","host":"s3://npm-registry-packages"}},"2.5.0-5c2de7cb-b6":{"name":"addict-ioc","version":"2.5.0-5c2de7cb-b6","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.0-5c2de7cb-b6","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"7eafe90d2a644b2202d73c7d7a23d46861ea2515","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.0-5c2de7cb-b6.tgz","fileCount":102,"integrity":"sha512-O3JgPXCdOGOLHclErgBetEFbZIUu1Nmoz03UUcbd8Y744GiG1Pxgfm4QZkhZsE0qaQaO2GASmcgxzCggL0coQg==","signatures":[{"sig":"MEYCIQDZcTiKVnZviplDLfyEyCLAaSbGwfYp1L5WA5vj3KI/XwIhAJi8vZcwrqxaQo3bPQul7l7pAXLbPnXBUF12uaPyXozc","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635495,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4pw7CRA9TVsSAnZWagAAov0QAKNSKBtMBe6sAkQFag1g\nmVZkKR5snxxpkhZK/PFsIXbORMZdv54RNbjthKMVJVAoywGmq56vmzgthtQV\nDBPuiBHGTMYE0RXgXP5a/ZSiSvKLv8PNqthXgV/pLEzLvUrJFcK294qEnIX6\nZ4LDJbFFO/Q2XKNLeWLeBUP9RIv6egR4aEIbQ7yZYiho6x6QgDoaFcps7x+b\nbAa9T6CjRmbrcLVgaY+W+NQaC/rnmzX35i9c52UTMT9GquNNWt9WIFs6jWSq\npxeIbkagM6CrXEyIJ4RSD0fZWJBGuugNXMarjMz4g99LoReN1P3E9YyAw03o\nuujYhtY1wToRtkzJIPzhUJ6odAayU2F3ns/7tyV5dADViS82YbkEotsY2cK9\n2nJeuNZieCXj04hG1STRxKtU98gQKb+dl6zmR3QwDa6KJHQowLN+pD/6eEAu\nMDfD4isZc6H9X73DdnvIVsvDDFHiKDxWuEfkmB5L0P/6UlEk07JsT6qnVaho\noXSLhMKeFls4g4FxrLiy9XA0iNxgPjKNKd5hdv82ZCcVjt0HGFWXs2H7PND2\nQKxn3nndsIk6cQYgJjomtQxHHNGUXcwZsJTK9+pyEsZBRD9Wd6LcAAOmFaSF\nenYmKsdpbp/PQnYzrCubhPL0da4QgJ2/IiCLubkhFthlrfJORcg64lgcnF/Z\nx7Ir\r\n=dqAa\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"5c2de7cb29c0e9216dc7294c05a9da15ee12979e","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.0-5c2de7cb-b6_1541577786602_0.6815342849141908","host":"s3://npm-registry-packages"}},"2.5.0-5c2de7cb-b7":{"name":"addict-ioc","version":"2.5.0-5c2de7cb-b7","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.0-5c2de7cb-b7","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"9546f5fbfbbf5d8affdcfcfc4a5e99549f5dcc8f","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.0-5c2de7cb-b7.tgz","fileCount":102,"integrity":"sha512-I9urhw5seErn5/1pxABX0G40aAjY2RKrP1rEWOFk6PCeLFDdyn0XMKuPnPanxUQukXo6uQG6F5mQXKzSBuRNPg==","signatures":[{"sig":"MEUCIQChobVsu5NfbvMRHakU7AS6KPhd+lOxaF13+Zr4B/I42wIgHflEQ4JV51TlIbhn2ohUmX5HEB9yM4ti8+bcA38zcQU=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635495,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4pzMCRA9TVsSAnZWagAASjMP/2d8FacarMevpnwzVyto\nM/9iQalyunVHrnkr7pAc/BRAfQjNW+b5aZp+BCizx4aqH48gVRGit+UApfbd\n6XXvJRXPVW9E+qhFkRfOmPct+MgG880qz+oQNntNgtg/+DRLAqXn6jTUK8XD\nTjdsstyHhHFXIfd84IXuYXb2/u9W7a0Fvk/A1cJoDTPOVOzcvnAG5qt4BMhw\nuvxqyxYtJzni1SM8dW5E4g5c9uB7XrQuHhESnEkEbltBZ+8DFJSthsNOcuJi\n9y0MSLhNLtyQL6GKDch5V5l+iCGiZ4AO2OOsyeRFyu77I0889w+eAh3hGLEY\nP+D0fJ1lHyS3oy0OZvIoATWdTv04OfXCtqUIVPTFkCNq3HPfG44GXiXWhvS5\ntMGI5GoMwy7h5I9qs+k1PElfMQQ53z1e/T0z8+X5nwor+NP0C/bLQnQWzVj4\nxUgJkUwYroXwm5fdYocrlbQojEobX41/YgU8FfF10DOUqtjVHSrzQ83AubY0\n7bKtN4fJzJ7g3+biMN8lbP2Kty+doV5bdaUVuZN5PYcs4liOGa9Dywbb6y9D\nSvQJJArf5NUEmgH7mC0Dt2Mp5YfvKy+Qp5KJ4TIjQI10p/+n37SK/PygG76i\nuzLTxrZuM4IZu0B09DARpAHbqTcG4mR6NWEzyvBGgM2o65GWhoH/Us7mCjdO\ni4rv\r\n=XPhM\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"5c2de7cb29c0e9216dc7294c05a9da15ee12979e","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.0-5c2de7cb-b7_1541577930798_0.43246332616078864","host":"s3://npm-registry-packages"}},"2.5.0-5c2de7cb-b8":{"name":"addict-ioc","version":"2.5.0-5c2de7cb-b8","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.0-5c2de7cb-b8","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"c33339e78b3e174d6a6ecdb60385fb4a02b06f3f","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.0-5c2de7cb-b8.tgz","fileCount":102,"integrity":"sha512-muWwQDnMSvKcsz/CQvBieMrZCCHKa8Aw833JCEz/HJXb/6zWXi8Ild0ms9OW0tjJ4QssTBJZVJFit8cvJRXxQw==","signatures":[{"sig":"MEYCIQDzBS5TufLYbTtPNEo3Xe00PTxn+qO3NXmFoD4ZycFgzAIhANktKk3/fqdl5u883WpYE1/nVpOckyupTaAp1VLe2SS8","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635495,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4p0RCRA9TVsSAnZWagAADEoP/1zLfJoXpRFooSMDYmp+\nDg8jjNrtqRvq/Jlk1nBQOobZJCFxOjYyeZ1GKNHp3pXbob96Ma/PyJ8HKUFM\nMFbQxRESRBVKelJ0Hk5aFvgHjbcIoM5HRLLfjbI3L0HiCILSQGeUeAUMrqFK\nkZEhzgrpZBTy40us5eO7SAS1VZRl2Iqqlm2xTFYWp2G5h50bRqAP3BcIpW30\nPJUfPZaIPnaSFDCycshrMRwx7ZRPRQ5VEEKcMq25gF6J+LXNYke9Kh4Mo/yp\nHZHcGzusj+XiPdy2nlmC7BGtYI56Mp3k4pF4AaDrPCepKqCQfcx/SYIkMWdj\nddX3PERFF/Em8V3qxFGf6bUC1v9gZNqTft+ZuVlN2O+2sFLi80FUSTzNHSu6\nsLZTGSZfrYOQKrUo2Qbdzv5BvXeTD5rxz36bZCZoo7dR//D1fMBKjQTjJCGY\n8nHCaaY4yPNmm2bMNWmZfleR0ebLQWwWiFfjzZSaVhdFKL2QzaXmG8l37Ww9\nuG78riD8XEEYTV5RE4dP9YTmCwYzb0AI8n2NS2832xgH8pYfcY6e0ZqVyQoT\nt8iU8oXI7GzsXxuA5nt0KXc5D2w2DKp+kyUBilLD5otC2+Cc+KsygNXf1l1w\nfYEejLV4dkUtC4BykVdb5osGfj6XAAra+g6G0KE3wxI+JVSuiVcAxGOyci2Y\nalPr\r\n=p8Hs\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"5c2de7cb29c0e9216dc7294c05a9da15ee12979e","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.0-5c2de7cb-b8_1541578001006_0.575518400215439","host":"s3://npm-registry-packages"}},"2.5.1-fb73abb3-b9":{"name":"addict-ioc","version":"2.5.1-fb73abb3-b9","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.1-fb73abb3-b9","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"b985b4f02fbdd350cb861bcdb24d71a97717443d","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.1-fb73abb3-b9.tgz","fileCount":102,"integrity":"sha512-ce24HYjW175RSaYBcPU6GOjc3DQGHQzcIkii91Xot66nsY3GQ/K/mMPCLQSErRkYX4A+vqqn+Oy7ygGEAU4dvQ==","signatures":[{"sig":"MEYCIQC0I4ot4kl+DEgU8o8++etrbd3AzBDuccfhokxMWsWDmwIhAMyqMxdP6ENL/hMYY8Nw9c8Mga+slUT+XHq+wqdAkpeg","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635571,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4qF2CRA9TVsSAnZWagAAlLIP/1UIgIA5M4EK1CNNGq7y\nsTIlLudeYDz+0jVtggvl88y9cWhYAR470V7vPeqUtNuI9oBllE8dGaU1Dw04\nyxk6fbA5duDSTmk2bgwfQjmyOgC2Utp394hqm6Xe2pAdK4OuHatG4hIl0Kbt\n6CN1H4CzacMPYo9GFXgikgk7foIhZ/trAj2PhZTq4eJkNgSBGPHHqS8f5sYX\nW/F6hMzVQ7OLRHlrm7OUcnTzoAeSh3qGpQ4aOqDgby/rZb4uUqYoNJCHfb8S\nGP+hc9L4rlJ4j1vjLp23j/r4LUhTI48Rx7dPCdshbYgPF3E75wuzlZXFAw/y\nIHX21PSgnsk9Hf4iZrXz+bRY9TQTqsh7YWaEOx1FiTVvZE+NmHTuUt2Cf4pI\nu8daQK7TVzx5oc3l+NjV3fF4FPdCk1y8Fi3E9hS79Hlr6Y54xTWricCfEcsf\nyZk4NbIjVrbOg4OTu+sBR5aH4wVS00cHTcVIfBV9Xpz8qdg+Oy5BzILqFIK7\nFQC7MBPCQnq8+R/BsToSCncfjvQDa0AGyvcJ/bg5MBTRNoROa1zIj8e57Bh9\nECwqYf6+jSo8+zQwH3QIOCAbiH5kT6ehvdQL+DBJ1JGQqKMXHReHhEwsxDn6\nJZxX4/DPyrdP6LIqzkRfeClWKOLuLKdwGIPyK/ueSNafVqb9IFFSK5/pCldV\nuWHN\r\n=/2o7\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"fb73abb36eae4899394139d0f2b161e60929cde2","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.1-fb73abb3-b9_1541579125746_0.12035857776124881","host":"s3://npm-registry-packages"}},"2.5.1-830a581f-b10":{"name":"addict-ioc","version":"2.5.1-830a581f-b10","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.1-830a581f-b10","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"858003f4244ca4604e46add2a3a4880ef9e2b932","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.1-830a581f-b10.tgz","fileCount":102,"integrity":"sha512-TPaRkj4kh5Hrled6slTncSFyLW8eQgz/P/Ah9/dfgOjMx9wAiTWZA8wajaavYLACETSakouPeUFlf8PaVVp99g==","signatures":[{"sig":"MEQCIEpuLwE4RwXjCi4pZ1+3WFSqt7QRJkhS7vX5w06Ma1rgAiA/uYmlBxJWxlfPuQfYlGIjHBGJLh+PCewJBE2fT+/6pQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635572,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4qIYCRA9TVsSAnZWagAAOk0P/0ifhkhFpsRgQyUQZiTs\nsNkWWxcslDkVMJv6lNgLw3iwoGyxkTQCWlUL7HNjVOsXHAkuCvwoSi7Nlozh\n/03VNdocQlip5HobMOfMhYfLBN6Lk3VqSGiOLS0VYRkzxzVaCjZcuWUhFjGL\ng5VltvFLV15j9DduBPJVPgks1be4JHrFRiyYMp20/NuKJyZZC2rmalpeBGH2\nVs/57rr+x2tqjv5toHhhOW6iA8I5pRzS+f19xCaRYr/8B0qpQaBZLoohJCYd\nDIVkId9bKJcuMogXqcvuFhSAyin16ZKjhMD0T8/3jmRlALcOI3U2OiMRUWaY\nEPEZF6M7G8d692cQ/GBPIkFP8pMYdx0iJsOAxUpjV55QAYYBE/QfRYFkesZB\nejZTqdTJN9IPrQ/CphXSD//L1+rS1lcryQ66gWwNQvC2pVIkcSvMxDOTBVYv\nxwFSdgaEBORtehww29CDJsCC5sVg7I8I9pS6c56XCSlppug+WmZLk2PsLODu\novpRZLMYJlThQf3Wqeoco1bfkT3Qznm2qgoP9KRsuQD49hTacduJ7RBuHcyG\n1ys5Bh6O0OmgqJl6xIr5h+L6hvIIF3AVY4Laibhy7aX9dddrzr7/hINE7UiX\nTZMxRWyAirzik8fPPJ/sFTpfp1OVYqOciVmFilCN9oA75fDpjQwZ0efwkjsM\nfdTM\r\n=74UY\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"830a581fdaf2b0edb69753013c337f2b6711b660","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.1-830a581f-b10_1541579288122_0.626165933567508","host":"s3://npm-registry-packages"}},"2.5.1":{"name":"addict-ioc","version":"2.5.1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"b7c169566b631ab2d44db5a7f28cb46f3478f3e1","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.1.tgz","fileCount":102,"integrity":"sha512-oMQtL5Z2P0ujoqYvwXdRUAlPpHAlftNTIwJ272fLFYoejW86fqx3XSMaCzYsl+5LOTnkgMwQuX5Z1pw27exClw==","signatures":[{"sig":"MEYCIQDdhg7HPuJZ5BXBF79era52WuOYZMmhPwlN/AWnp7cdcwIhAM8gLsXMtk08mgVvgEyhO/R489Nm76++VBMWOIq4YCnn","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635559,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4qIqCRA9TVsSAnZWagAAdA4P/A0x6+K/u8wu3R9h41T8\niiP9vb/onTmlIuljYNvvzefDzaWPmQ7Keod3uoXTtdeHfG8GyFHAuoSN7fmE\nry0tyggeDcQy8tRzib1ikbeKaok1pu19d3fnZZ+5N29gN3gT16Tvx70FnCZ5\nrL4+ODc+8Lf57t6ofqH0sFmbslaLu6YoGsewXIqA00PHUEs0qBhUdNXT/E+i\nQHfLf//CnMyZyqflUm4FeAwe1CORJOwwKKokaaW0Xg/nluh/LGwRvGAOLm2c\nW7pZDhwovYAOOTnBuSw+aAMVGTap/hOZ3eHIwFEn/lYqeb/KFnhj4QU/Ck43\nZunevNImF2EnUfHwplm/jSzxDCbd9ZVnujxFcKQ5XN7vw0pFmveJ6Mic9E4n\nMmOIqyfn8JF6YnYCmt+pgzPXcN0oqpSCfQ8Xhkf/NrcfVaLHD0ij0h4svq+s\njhhUC+lGdq9IXPkAcPalFitHvOu2JeeYIWxb+yuLNeJEyXNnXi0zbjjVHWyZ\nG0Flo6jYAqh4XZzYoLCaE6y78P4EwMVCJWO2Fjj7bYTNttGhpNqWg2e5xgPK\n6cZobSOp9IY0qLuvmkSxtWVERXKAAWOW/gSRDVrq0hE4nD/7AS2k54istvs5\nCY8ttHt8MiLYyseaMxFs85JOEWZpL7uqDNcK3/wDLu15loKzZ5Am6HaLKN2V\nsFVK\r\n=yMFL\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","gitHead":"830a581fdaf2b0edb69753013c337f2b6711b660","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"uuid":"3.3.2","clone":"2.1.2","should":"13.2.3"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"4.0.0","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.1_1541579305303_0.7807501379481698","host":"s3://npm-registry-packages"}},"2.5.2-a7a910cd-b1":{"name":"addict-ioc","version":"2.5.2-a7a910cd-b1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.2-a7a910cd-b1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"41a0e48c09f3504d4eaf5ca98ab250922f2f757f","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.2-a7a910cd-b1.tgz","fileCount":102,"integrity":"sha512-A1T9hrp0yCLckfVwLaQtumRFDZT9QNVzrynFQ07imC4A+Jm206X+g8tA2tQn7hxk1dWUJrRrIrOaatI2i2OJmg==","signatures":[{"sig":"MEYCIQDqS7eDo01zb1HHiDyPTycTb4uq5Xpf3gAxYBoA7Cf7SwIhALnsIc4XixfxX0BIGuSJEWrOoRjsOq7A381HVfXk61EK","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635895,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4/bMCRA9TVsSAnZWagAAG6wP/RAu7H5EHveVLsBkwfJ6\nJRofjguoCuRc4yugr5vPee0XfPkJifKm9G4qjTpXHWreUs8m5L/j0E0FudZo\nREFC2CCoTlPh4P9LB6MQpDrkLTKjTHYHqZ/O1QzgwzLdNwHqWFLi9o/ehNeZ\ntavPFqGSYRxfFh3GNPfCmtNSyLmDkatsWSGET+jTe03V30DhoyryHOVFhqEs\nZYnMmxopAlchzVSfJNkFNhaezL3bhOwYII/Jt79+3GmDZEFogcOD4aJOl7MM\nH4C6LSze4rp4BdhtyTmVaa6toJGhlY4nC1SsEWEbcfVdLhtTaZ5u+MLuUFIy\nMQFkabKMSJe3wcPQwmEFo7CqXV1AkRVDGRhAoQhbDpKoI89aH3FG7fKiML32\ntNE16hSrcBN1EBaBCguR2YEIwkkdpSnYCM4t7Trx43l767vWnIWlKb6twmV3\nzRprHJpUiRAUOxHDg4d52ivr5q2+X8SpnKjSbyzi3X2iHkoon1WhfIvKEpqQ\nlojm41SlSWLLxfArSHOZI0OXqCSg9Qk9AVCvN7/WDLW9BMOPiVz3ZsbTu9Q2\n0x9+iZANsxOv+ZXc/3Fqj6/Pt58ydmq2HXatxkKEfoIkyRWBk/WWXjQdqrzj\nDX72VMgyypzw6ZuTpkxBwmZnLlaDowHtYVORJv/47Cxsscx10/gPyy7TOV+p\nUU+D\r\n=4VyQ\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"a7a910cd816d1eac5548336e548452e36e80dcac","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.2-a7a910cd-b1_1541666507617_0.3867520009752068","host":"s3://npm-registry-packages"}},"2.5.2-a7a910cd-b2":{"name":"addict-ioc","version":"2.5.2-a7a910cd-b2","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.2-a7a910cd-b2","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"15b3fe10071a8792083f06c71882fabd339e9651","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.2-a7a910cd-b2.tgz","fileCount":102,"integrity":"sha512-Zhj5KmRRyetOYVdiuNNTKlTexlSiidU35PofgcQqT6CrtFo1+414CvfVYrYiV1nDD4hxhyjVDOzJvvOgiR0DBw==","signatures":[{"sig":"MEUCIQDO7pXAVQ6tdmLZxbOljOr19RF7GkkFjAUVUSEdti/jXwIgXdxmKn6Gqc21SCyt3CAaPCIilH6jEEM3SPzX6dH3+b8=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635895,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4/bRCRA9TVsSAnZWagAA6/YQAJE5VUjcaO71cfPtSSG6\nA3PqnA68KW//Bwr4Iy21vLe1l6ymJU+ZvB8mWzH2cy8NQ+iXkl1VmHGtgROp\nujk0LzjbBtYKhpe3MC1ds7ugdTUxjmyBd0xCS/9Q+xNsD8OPYE/jDa25yX+6\nR/ud7z0ZgKcJYSZ1UZZQUTMIZn+hhFJy6FpKWAziu6IRUTz0AJ38sKBIqmsJ\nzl5dfxgLZ4eVTssS22ApFWv1Xmwii41Ou3DmeSKnYZFzBpmD5MQDii6gBn/p\nXEVlMx581or57Ce65MOpGRzNUGMPjxSqad61rj7eoGU8u6vnbG+7hQiSoXf6\nV6OGW8v1M5EHFAbtbFSwyjNmTrAaN3+fgS6P/bc+Za9+4/8Vf44iuwXHF7/2\nuBgSMCGE6/MPFsXbTXTHkaNvDF+r5jNPgkLoZyW2nKThqMCc/rx8tDR+rqqV\nD/h/vbZik2KE2Mfx0lrTD6L/OHrY22/YJ6dgBEvKnXDM/O6zSlPME0Fb2Zc5\ntl8TtirN5EIqIA6FzyzeWY7eZF6fGMQRwm/uX1qOXoIYo/lJH7TQcbvVzYwf\n6sU3ryGhyf62C8bEi8hJzVvZlODMT3t3jlj68yr9FoUJy+pyyR9+6/HsHiyW\nlJY+hV+/Ogf9M+hi/SSd/oUEKf0tdi3rrihYcii6Gwn0oat8BfFg7GfOqaI6\nKUAY\r\n=hSuj\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"a7a910cd816d1eac5548336e548452e36e80dcac","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.2-a7a910cd-b2_1541666512514_0.7988923988181027","host":"s3://npm-registry-packages"}},"2.5.2-05db85ab-b11":{"name":"addict-ioc","version":"2.5.2-05db85ab-b11","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.2-05db85ab-b11","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"5b7810e33290007d99cea3c58b51d4a1f7197bb5","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.2-05db85ab-b11.tgz","fileCount":102,"integrity":"sha512-oPPa0At61eYIFA24rx79fM6S62zt4PW9bPQcNGFGoDezPvXnymS7KG3S7aE85MIHCbJ2lqZCl6/Q9EPpcBBl1Q==","signatures":[{"sig":"MEQCIEj/xYGririC1Zl1BR4HS6Y0izotyBCs3LiNhTHr7FnNAiAWRIDurACW0yR2qYCc6SPmPxDuAD1kqkE2Ov5DpcWKig==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635896,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb5ADHCRA9TVsSAnZWagAAV4EP/2KunwLFwOO830g6zJW/\n8ZygOGAHuUDdHUCx+7w6dvHBSMgf4o4UPs4Hc15ThcpMkmeYIIRNezYDhTOd\nAFkqrzSKg7zY/aGM7wE1wqCaHVYGgCjo5WcXp+sL+T61m7y7cvpS67aig01M\nLTU5CEWniebKhETq9+Zia21l61CFS43WM/AZVbRnm8JIAghRRZoxjx/XS2DA\nHV680BugiyCSkHTOJ4oNZCJUEKdmmpjSwgEpcCmLvxFGiW/Hpr0zigAxJ2MA\nhQYTPwrSyFzORAQZcf/lJMd70t2kw5CtmqPSYRnDuBnmmv9hkhmbQSz1m8Dc\nITPUBPIB5iG8uZyA9p4zTnxCcnXDuz6xUiWAnF4Du3qdh7X4eCTplyMogS72\n+60mZVR5V6UHpNElLNC6Py4DJYVExLPZhIztkz3GjCqsJPEEO1foDicl/7w2\nTh7WMdYTfcy8h7mK8pnzbyLgm5OOa7RsZL7gmoJio//A0b5YZU2oIj8uB+FZ\nce6EjwmtOLM2pcJaZNORjNFDgRxj2TLxCAj/qlYqt81nTnbECS02pNsnPkJV\n+tBqKt3pWnRNg1kc+l+tjLtiS+WIKl882Kt2JBWzHjdKcceP/n/eQ2+4jUi9\nCPkBlY05mQP01U8UoJYpVoird0fcYa1dnK5s8dWYAZcEFmdrNtZ2JHa85U9n\nLMgt\r\n=ZfGX\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"05db85ab89387e52238018ac56aa14aea79c3c50","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.2-05db85ab-b11_1541669062891_0.8866967113991775","host":"s3://npm-registry-packages"}},"2.5.2-c01554f2-b12":{"name":"addict-ioc","version":"2.5.2-c01554f2-b12","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.2-c01554f2-b12","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"cb223545c6669b377c47025ce87a77ed2ae20f69","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.2-c01554f2-b12.tgz","fileCount":102,"integrity":"sha512-zW0z9RO6fB+5UA1z+xmcn+xgxNGMlZdaG3UujOQmoq8s0Q2SMONPy0lkIIa3115sGEdRYYrW4/p10hgPfTPy2g==","signatures":[{"sig":"MEQCIBEExRRB1SjHoxL+wu4HI9h1WsXkvOmu5PHkkUfSsdK+AiAdoh6hLxI7dDcNwa5We6XVQDY4GcQNL/OegO307GjkWA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635896,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb5AEtCRA9TVsSAnZWagAAKoMP/3P9YUgAevyScv9wYSCu\nSKIUW9wiWcwCHu/cbC4bTkfmaHdDpNPEVaHGVeCt6s8Z936fuNzblEdkl+B6\nPgYKntuc6dEG6O08h9asR+fnXhV77eBrcGAzq0cdGipOm5xVtGWBMihmDuBd\nfeKhz2yb7wWKxvaMLmrQG2TtH7TFqwRhQ6+c5Q//E5E0lFSqeOtpTj5qaiYs\n7jEhRsV6KI5xv+6nJLbSGaxihcsFEmZv/jrP3q2w7jymyDmdzmTDF5MxSD7h\nCai1TMnbvwHfrHBHP++/HkgFdVzeQvleck5uYKXAeHYAGtrHYWEZSowQtDjc\neUMQ3E8H98whsjO4nGrW4wyw0aBIf+P78CjBfCByKA/VtcxK5ihdkc8xBrdj\nxbnRBr5/TWLVpyCaN6UE6OUCKblOoq1Agdp8SgOkth7OYHH7fyypd4t+t0us\nFOWbeBsG9Du50fFbk4m2urYFEzLxegLLLy1ACKyCHY8DZYcTB9SxL3XWGB7t\nWqby00TbvRSQoeMHw/inV6Z53XZ/Fjb+gQC5kC+RhX+k974f6rCISY8nKorM\ntlu3CeHixpsj1Q5CSkAQtx8p64EiPEht0Quh18r30CojbHulhcIsjsDgOqit\nImLBN9EhL25A0izCv1nOUCiZqdLV1P64RNjDQvkqSytb+XDqekZ1GSay+Izb\nwMLa\r\n=52gm\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"c01554f2a40d1091f84621ec26f9ef42deeacf0c","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.2-c01554f2-b12_1541669164340_0.3182126333630926","host":"s3://npm-registry-packages"}},"2.5.2":{"name":"addict-ioc","version":"2.5.2","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.2","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"63c3b578872bccf35494e52e3e18e7f389fdc72b","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.2.tgz","fileCount":102,"integrity":"sha512-pvTcnNiU4nmPMsBC5qmNB5asUVxBAPSlmP+BR5qTrhcKqk63GcSWW7fQyCSUaN6CiLtMDw+SbWey/oNcB1wbbQ==","signatures":[{"sig":"MEQCIEYMRYXr41ogZ+KQw1asjp1i6k3+SxohB+nf+ppk1ISiAiB0fnwc8wDwX7Dvu4kY9L7v9kwdC6ew35Mjv2+nTUw9tA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635883,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb5AExCRA9TVsSAnZWagAAMYAP/1OSmTPpa9RrM/kdNym5\nnSOQ7p5MV4PRcKMwSzdk4RJySSuOmedSx8+RGX4mMgfx2ZwyI+1Jew7/d+sI\nwyJ4ivFPehYBg5YsvcwlVnWlhvWycBkrdil1bhBIg9J21FLO9/q+/Wd6CSIE\nuQ86uLgEdkvLg5mdMDxf4vUtxIwuh5bguGGoYU4Z4iS6ZW+Qr99tiKZUXiMp\n8/Lc+eN36XXmcJOFrK6w9FkJUggQyFuWpRgoCrZcB3G69nP/ZRBNR5IBh+cM\nFMf58mRNK2KwUcDCAy3pGvm9d/k3Lh5otHy6UTs9O5j+L9lQwyZOo09ayr2W\n6B1XZbCT7JYhJGs/QSFj5DPBG7zX2OZRi9j3uYVCxRYKW7GLnBzee75I9UYu\ntLU2Ggfv67EtgEftCJ0uT6XY7C46/ZBYCAohiNZmGJt3K2UNP4hGAtdp0UYA\nqy/37LxnMIhvCsuV+pwmjdXB7Az+e+HouOj/SJiCAbTYKu5h3VXP2nw6Avxf\npv3sDNhw3MWiZ9bJWtgFPWzt2EUgfmeL3Ta9VXBw5peuo/oVsdHP6c9Wyv5+\nK+dCJQslDFyPBBh18jbOL1UdxgPMNTjLVs2EWhCJMEOPDhwFiLD+jtObszxr\na0VqHJ6TBPHgyjb9q7cbIW+NdLjK+eMc4xi/g1Fc3ZMZ1sv1ZZlUWiOhvS7y\ns1Q8\r\n=dpOp\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","gitHead":"c01554f2a40d1091f84621ec26f9ef42deeacf0c","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.2_1541669168993_0.038886401745602095","host":"s3://npm-registry-packages"}},"2.5.2-6aeffa58-b1":{"name":"addict-ioc","version":"2.5.2-6aeffa58-b1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.2-6aeffa58-b1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"e062c6568b825436d22404fd67482a7a7581020d","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.2-6aeffa58-b1.tgz","fileCount":102,"integrity":"sha512-VvmBzoePrqfija0mUQ02Q4qufq+bftEca1LC+uBZZXKQfQSvTWJ9WXml8IajLjDXqHBGYasUihv2ynuzocpGrg==","signatures":[{"sig":"MEYCIQCTw3qdSzKDcLwHuvgV9ePOLzxvZa6mrGosMqTB2Hqm7gIhAOpKZlIIsjWbOrjNH2AGcMw96yWuHMFwUqKEKsRihcsY","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":631648,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb+/k2CRA9TVsSAnZWagAAlKEQAKD5iN1VXYApK/9MTkzx\nZR/YColQfjs9UQ5fk/Ym24ZdYBAF4DtWQi9rN2KRTqCEUo3WCo3NkGce34Di\nR6WYZGTk2z+0vbfJfSp6cfo8rss1zg5fM10Ps25vPr6uBCh5o3pq2uNSnQbE\nyuNNCSblvesrnU6j/pP25oXaa1SEY1w4XT1xxTcBOXYLPSt2RVkA9BImo4OR\nwlIAzT564myzQnqB+6fmF6VxZKkE4qj1W2f2x16NE0Uv4y12MwwbxC+N1rRa\n7KiXXCD4hcsvt/d1RZvZ0IkMpHaSNPKbN1Q7+p0qXhEIxwjc4bhyKU9z7ZCn\n8NemzEfKFD50FfgRPwkhnXttJ/78f6Gi6Lw4IGf+MEkESBO3eJyL2RrDBdj2\nl2NcCGEMpqI2cz/c5/1a/O9zOPZcChOI5G6rUeqNQwr+aP4EJ+77M9iU9J+7\ncyiClDc0JGi7NQ4KWT6kFcFvpMMnYu0F5hhnsCLYcAOsSWiP59ACp+rA23Ip\n1uYuyEtB92tpJghHFAQXpCVGRVsn3UlLsZzZvqE+xpaYO46Q7Jg6Ql6L1qGe\nk6RDTBnu8lXj4keOxgB35CrCU4POkiLz9BsASU++xNGNMtKjwgOVFkZpH19G\nfR8HuHRgFIfHNIVwX2rJ0gF+2hWSGE2iQPl4KWTD0XihOSCPqDjJcKddyERm\nZdIN\r\n=41aZ\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"6aeffa5872528ef2c29aa68ba7b269553c00a4ee","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"3.0.0","@types/node":"10.12.1","gulptraum-typescript":"2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.2-6aeffa58-b1_1543239989643_0.5954663836150458","host":"s3://npm-registry-packages"}},"2.5.3":{"name":"addict-ioc","version":"2.5.3","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.3","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"f216b1355b5b7f9dc25cac5212362e3f38fbc0a8","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.3.tgz","fileCount":102,"integrity":"sha512-nmbAToNrPpesOclHajkpFdgJQtnl12vnUpIkD0Ly1w4GySkxpcfC94GMSuC4SagbUvV9xZiUo5THs/GUPU+h9w==","signatures":[{"sig":"MEYCIQCPtgPZWXo5BrADYsHROCUBtbseP+kLD94JQd/9C3vF7QIhAN7LCayihnSW5r39xfvlDI/iWhZGoOjBbhBOCRTHR6nP","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635886,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb/SFpCRA9TVsSAnZWagAA5nQQAJIyuQw+nCy4o9DhTLP2\n3G28bT4CB0pxXxQOxMdCuyi+e/UybWYCz4teDRp54qI0+6/7dBLP+KbxFe0Z\ntg1CtXz90jJv3WdCrhhE7A89h0sC3socJkdTrNVKA94gKYA8sA18L620jhF1\nQVwauKB7wAkmYB4gyZl9GNfohxNBb+WP/Qc42dHXi57ilUHvQ6ttcFrBXydA\nYVhGNoKzRP/SKUKMJ/6dsMhdjTXRgAedRaFOf08/P1F4Cue7nSrxGFoUF/4o\nHlIEHcy1Kr4gUtybky2QA5gD8Rj3o+PoKZBqMeDCEWigI/E4DEbAfrGkXoHX\nn1QRj3luhHHQB9a3vwtCgQDjn4hOuTNxflt3X28YIzJGI9mjO88KVlLbs04z\nU+c8Xx3Hnj1ZEUg7fHUy+HMLXIhVVbCxa+eI9jWMLT+M0EC1BYTiFjpzbqqE\ntoTbBH5OgWDL4M/AwLf0zR/Z/u15yLA0K1qBtxftWx1JXmO3eeJmr2tGXiyk\n80+i+vrJJrN24CY3uL+FDLPRN9+7+/2IyixZFufk3fV9xH53v/n79MsBXjz3\npa2OxsBUx9PIzS0ITlyWK732vURWBaz6AcpfFusQ6iKkhxAcFMdK2zu2J9zK\ngATFL1EbQ1xvfWUNewYVvH89TP4mV5ZcmUi/t830MJOWGnofZZfYFjfCsJbZ\nsLdY\r\n=BIUl\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","gitHead":"19041ba5421fe18165214b0f99b7788280129496","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.3_1543315816253_0.6438554193831187","host":"s3://npm-registry-packages"}},"2.5.3-19041ba5-b13":{"name":"addict-ioc","version":"2.5.3-19041ba5-b13","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.3-19041ba5-b13","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"54eb42f8a5e2e9f3df4340f3f684457cd59cb7bc","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.3-19041ba5-b13.tgz","fileCount":102,"integrity":"sha512-J+JvBqYq0Qagj44YrqKzx4ZrPF8KybGiyejW/1GTcW8hRLvdMx+bkqSIhdkWBl+gpy6qprUwgUDdBSFFVas5Nw==","signatures":[{"sig":"MEQCIAwi3eapvK5oYUOoXbb2BHsD417TjMpQ1X7EGRXyyQqSAiBcFT0qqsc1VxryLD3jB8MJs8psuxghJoGCARWXiYBEmQ==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":635899,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb/SFtCRA9TVsSAnZWagAAnGMP/Re+UutUTOvqtlgJGZGv\nDN0ySbvVCWq/Bf1XsjVUkz3ZW9ycWP1uE3rZ6lJzD3C+9nlSyjwz5RleaqcY\npK2MsMGvGlbHU0GfeZnpj7xsQ/fv5jofVh6BJEF6n597K4G2J2m+TzKRUcQ7\n3nVtVWcIkM97VesrQSHOE+1Qhq2hP7vmtxzadu7MgN3ZhoqXevKOS8QgBaGY\niTCm6X4mgBdWJ3n5recOqIXmsEGHfBY8DmsawW5gnafyB4J6vh9hklmGj6V5\nqpzry+9XYMjJgO3G8nsJUSxYAbVJoZwVVNtc2tkhh0OF8oTeuUlIMxlldK4P\nt/FjrKgNU/g2M798habBRrDXyD961jzs8gN8b5M3E7ABQArGyJ/4fEA2U8Ey\njpBNpZ0duSaCkR+IxuzVC9rDUjd6aL8dmgIvzcH+TAlZ2MDN1o2DWIIdPGCa\nXiyGYgiUBnAZHgtTopDvX05y3GMJxg48WNn6rV6nHBb0C1wqlfZHqump+BCv\ndg4bwpT2FQdwXWj4Duiq8LW3JI5qHmnbUZSFWnFN/lKAAMbDgyfd0lQh/+ng\nEwVkMI+5tK8l5eV71fIltl6um8Sqyng8aMOF4No9R4r87PsrLTL8BjvBY7LF\nlhENXaA9DVYLucic8HY5aHhmlCBHAY8ESlKwUn8wPRb2fBdGOGQEiiOrleAL\nzMA5\r\n=wDFx\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"19041ba5421fe18165214b0f99b7788280129496","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.3-19041ba5-b13_1543315820581_0.7460103603403723","host":"s3://npm-registry-packages"}},"2.5.4-951816ec-b1":{"name":"addict-ioc","version":"2.5.4-951816ec-b1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.4-951816ec-b1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"319c687d6e4ca4f96330933159a27372d9e5c487","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.4-951816ec-b1.tgz","fileCount":102,"integrity":"sha512-z/mp/Pe81Zw7PydoCzwUHkWvCQ/XTsoOX/Tzfn6DfBFffY4yy2r+Wug2gjX5+2Oi+7aKYs4VH0IEIoJ9aOdAQw==","signatures":[{"sig":"MEYCIQDN8BKAnc1+FbHsT1NAuNLdxNzeWxuE+xDoIcaWOf4PMAIhAIvjhX/NoKETynGo5YTAEzAgcbqQe7e/mONCaZw01+57","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":636024,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcBSaTCRA9TVsSAnZWagAAv/wP/A/fmza0d9e2zDRCdBWe\n7oO4fit1ogjV6qLCi3F8LJhSTCHG/ekpO7ciX7vnKfMeDVvuH2Ve5gZYM0W0\nWEk57yck93i2A820DzA429a2e9Li7tG9m1R4coXQdkET5ZZ0Edz/0IYSRPH4\nBRm6yMXjXRnC6FEeZ8o0Fj1UwZ5mZSEu9u3FMhcwYOtshjxSRFUu6KzPdc1P\nte3+3+FaDLuzBettq2viXAnh6SGXRXoDg7fx33y3FoODtLbdSlC+b1OLHwVR\nuY+I41fTpRng51hMo+P9ZVg4G42s4YjXjQ7HDQ5bzbhXszLCfx6ykj3Fjv38\n38zGyFu87P6xJalIJbvFfe/yHFMKzzzodUrtwFB0MUXknQNJzrPNh4nzo96c\nDNeRcJXaRDP/9tcNY2Dx1I/LQgvrZvklH4sVPQsTiTCYcK22QZ5Sr1lRFLbG\nTtt8EMfLBZVZ0F1n+TPFBwqb4umdxM6aMTc3b3oJh900pZX0eujs96SgPQX5\nsk6PSxwVFlPH0z89nqc//9gft39Hqb58aem7Ih3n9FKdFH5r4YZ9Xexknpkg\nYgfMv/Jiz88usaOXMO235Bpe19UJ1n+zwUJ+ggyMvjE5I/ihKSIOGbrWLtDw\n6rtg2aZjk992bb9FZHSMLc8P3XhxwVNxT1x1Azq7qmx0tgiAhQfyuE0jjINB\ncgr3\r\n=xLLy\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"951816ecc0a9940081c27a6d7409428c67493d43","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.4-951816ec-b1_1543841427377_0.27616558563557203","host":"s3://npm-registry-packages"}},"2.5.4-7085a551-b14":{"name":"addict-ioc","version":"2.5.4-7085a551-b14","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.4-7085a551-b14","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"39dfa2de57d98738da7098eb31791010c32f9582","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.4-7085a551-b14.tgz","fileCount":102,"integrity":"sha512-C/swC1bIAInGzucv12aDCxpNPV4mPIiP1A9HRXoErqQJCz7NNoxzUC3w5i/CppCM1TvVwLYz5FI3HW3ySGMPFg==","signatures":[{"sig":"MEUCIB2b4zL57ZcAgECR1+4Fr+qX9Ma7dKz7/6XXd+D0i+IIAiEA5tWPKjVQc4nbOs0qYKL9byXbp/jCWccwZt7MnFjEKaQ=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":636025,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcBScvCRA9TVsSAnZWagAAUPQP/3CPLTV69zZbsiaiHnVP\nCLT3t4lzLf+lmQNBzkaTEMbxcX8k//Gj3C+x5YrwP2W7pzqT/yzlfUpvQqjP\n7mq0vT70YDbR6NccjHZeBObRXmQM8LRJBSRXowUTOZjIPDihiwORk8U/vxDO\nhjYbz6F19EvW9WZmmHP+a9uVG3X/vlROMoPlxqm1X4k1498w9GA0s/veW7Q6\nmfSUj+5P+U4RYZk8eqlbSQQiS0XQ4FZSUHve2J1k7YX0BIexnoIPmaR9AP8U\nm6CWKMn93wI/acXQ2SyFXtEJz/k0PBCF987kOXR3Acufvn2aBupSzg/0Q+uK\naHYXMWBziD13Ti2Lln+Y1PgsQLTc7E11EQQhKzN0vesMs1IuczW1La949f0/\nWfDuI40vFnI0+pqX/ydWXL1xVuRL5lqbXrXnFDYvHTdIUGqdh7jjULdand4I\nEqnRKLRXc7ewj6hCI4BEX0XzLHv7PDkP6VzAesGUtnspnXbgL6A4kBpW86Ro\nMPKlGZF5UxjXlbKNxLA7kI3dlaRW3NGpO8k++7IvSyabIKluNfyZ2yqG4WZ/\nAT0K9wAL8AlRde4h+cG70+KRtBPskkFCqrsTnzA1rG29SyROFttfYGdVTsCb\n3a9wbt9LzZoPCxFAUKYgh+iz4MFNO4R6iMnZG7ihK3+o3hhRvZEYnFV5Mp/g\nxmKM\r\n=zcYo\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"7085a551a762b3275d67706048b5b6108cd0f4ee","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.4-7085a551-b14_1543841582654_0.30831508445783107","host":"s3://npm-registry-packages"}},"2.5.4-a40bed26-b15":{"name":"addict-ioc","version":"2.5.4-a40bed26-b15","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.4-a40bed26-b15","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"6c8788794512fd9390f08392c29cf39ccae4abd8","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.4-a40bed26-b15.tgz","fileCount":102,"integrity":"sha512-KnvVgcvRYtmXW+P4ALlcHARZ20MK47iAGnBGtuAy02EgHlrq7BcwNvUK8lu912rru5HDwLmPscQbi1B6rIrBMg==","signatures":[{"sig":"MEYCIQCE/eaM9uGMkGQrILjLeesSVb2Ixj8dkIkf+yIMvInrcgIhALldngmX5SPefZr1kGz0A2PKpLOd+YfABIg3ggq+JJL0","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":636025,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcBSeqCRA9TVsSAnZWagAATEUQAJ3Rzm/Uh/oyG/jRM79x\nv1WCnskNZfWjgDSLM+E58sxchSrs06R+zOiALVQyz+1UZUa6R0njx9Ryv+VV\nOL6sqk430pU4DPUE6OdFg9++zTwdaDYUPIYleC6ogU0Vlvi9APP+bWfydB35\ncGPOjbl/Qgu4S9xc8/K1d2YA2fliYf9Psw9K+cBZnnqgVggpgS5EcGccAh2+\noRUdK++n/otb8NwEmUE7Nk6Rpqp0MuNxGH3yx7nyJmb4cM4EsVUZwg8AHH8h\nMa7E8YpqO04hj8d7MwUCN9yEOu2eH/UHPOhCb8HV2zV2E4w8dGq1LjtB7Iym\nHgKSwHYXwVWE6OZbLsWQZuojUAizSLUGK3qeAfa1IPRpX4MVBECIMm/QOlpD\nK2bQqshcMHSN0P9SBXPzpd9mc7Y1GEGE/Gc8O4NFRYl8TMrnUj0pccy/1rrS\nOEwXYbBTUEXViCdAgj8XJw+e6DEOKyuUGuHRku1SkVHh812fO6b2HpSin2Xs\npqgyi9x+CChj5wmCkYFJPyHBnYkahDSFUsz1Akwmo5ZX4GGaGy/Uou4g/LnX\n/HLblwpuqPmC2vkB7yORTqjddQhSxKgyEQZLO8O/0GDhKpCc70C6iWJje45q\noTTHK1wjH32husjK0fM1lLTbdu6lzx/fTdAPVyfr1WuKxSpza1Fu6tTb6i10\nbjpb\r\n=NNR3\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"a40bed26d3a0d318eef2a3739ad75c6617fe6c81","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.4-a40bed26-b15_1543841706087_0.9428624885493198","host":"s3://npm-registry-packages"}},"2.5.4":{"name":"addict-ioc","version":"2.5.4","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.4","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"20a90d0731b88c5bc4cbf3ed862520718ceff083","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.4.tgz","fileCount":102,"integrity":"sha512-SaY6tZfX/4X/frOrqzlS58TQnClE8n43kJi0bBtvOhIERTuhKQxzj26ssUz8AJzXblqGP97WVDcA2XG84oxZsQ==","signatures":[{"sig":"MEUCIH5DfZ5jUX+EuHK+fdXxLFxuvt7AY5QVtjotHFf1ymyBAiEAjdDwPvZ0xViDemLItBOtNObtM5brBxXhcJkiVoaDLsM=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":636012,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcBSexCRA9TVsSAnZWagAAvI8P/jIeqekpqhb8m1yA2ke3\nsidyD0pn2Op+J7jl0rqHwobl+6Lb1yWSvCuQhkytBZfTm9WeKthKpCDHl1Et\nzN1p9nojidnRbNFR+M9CYNsertKUXola7DlyhiNpo+xXXzTJ7aVjXibOlQrQ\n2oqJ/t4hDUEbx14w/eX9I29pTX+zf7GMK2wQNF8xmyFXWPw9IryddH1j5/wF\n1QF72JmYea9Qlo1hwUjd8kqMXRCDs4RcqhMZ/NBtYAICJwSjXBWkBlQMYYCf\naP2f1n8t1Eh9wgAZvpd5z5HYHPvsJb+dzIWt52nHsDPrCiJ4mPvPlwZ/yd6d\nKHGMGKnFT7uSsP3lfdx8tX4j2JbcDJGsaxvaHp2wyHGFOvOie4KGxun2UzWk\nKt2HaTjBjonEAo0rwPUk7EeCOFWWL2NFvPE+fzHrQX3gIEbC99PeAYNbZmB6\nVTLGm49tz2OTzNKdmluhVhKWbDCYEfldZMyWqKmNK6nLa3gINyJ6OlsvtaNB\nBgPIbYZ8bE3jc4kXJ/CRk06zHt8RFnaU4lmTg9ObrQtxeWadqKFDj+tlCCiv\n+CxKPlvtyYS4Wab/+ToNLvj4phebMm/9gWvq1iGKqR1eY9fpDNd2XhtouOwC\nwZ0wMXlVAvn7U2olOoHJiEhKGINNDqfYZbi/5nctLV7mCNqn+TRu5LYDSYjE\nlFK1\r\n=C1Pe\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","gitHead":"a40bed26d3a0d318eef2a3739ad75c6617fe6c81","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"5.6.0","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.11.3","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.4_1543841712280_0.6008219279773517","host":"s3://npm-registry-packages"}},"2.5.4-a40bed26-b16":{"name":"addict-ioc","version":"2.5.4-a40bed26-b16","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.4-a40bed26-b16","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"9e25b402fdb87b36d1fdaa4f99a91f05034435fb","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.4-a40bed26-b16.tgz","fileCount":102,"integrity":"sha512-vlrxWrheIhTypK+iPkEXtSMzYrtHKvqDPpOQ4rODz5sX5Z+No193IYwDiP2lxdZpFXaiClV7zwUpYGpf7ztg9A==","signatures":[{"sig":"MEQCIDFMpmNWQRarD4mw3J+kcNXsRvFhuBoRS/qSJXE6lpuaAiAFN+8lTFA56PfxIfx5ODMxMYIiAubhfdugrXkpYUrAzg==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":636025,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcE9BHCRA9TVsSAnZWagAAJBwP/1T3GskX6Iimx/d7NeLU\nPDqUee2ci3NjFxZ16OzCq1SEbJkIMfpwdnZKvcJrBCH/uutPefdkDQ7ZWOql\nrCkQjYfKlouQL/Ooq8ZBo4/xypq6cCPi7zZ5fyRxL90uB87Z6jDO9voy6gps\nsmtJkOub0hVZXe/mEB+Xn7ig147ZIpCIV/YedVOz5AbnQT8pBgkFFRHhxb3R\n/Vny00RtzqSZemj69fQ8qMZUF2itpiHX4uEQYe6bblK/R9G0Gi0tu9cA/mAh\ni/rHuwL0ALXd+BIs0QMERfEKQdWk1Humy+Bj6IM907+sJ2DvCsMyCG28JnJT\no4eozTdFQKq6FSmsVHJJbNSanm4aR55WQi59bkSviGyY+m7k6xvJjalTD9xg\nQhCWe/c3fQRIL74RP0QmNKo+JZlcVAXXuqxiNc96wcokn3x+ChkQK1sYCjyS\ntxoO60lXKZxYytCVxctQrB0nENIMIA6JKkGFVxCDLSYfdARlynhzh31hCpCw\n+STijRDrik0j71tHiUZO6i2DUF9uWylsD0IUmaozzcXLvwPMAtNIMncPoQOc\nSyba5/xQQkxf/zcuZVEDNp5VM7Ye4VqTeoqpH1sAe6RPCOQQAoMwhRESE7ip\nOiPF+tYWNea1g6mNG+A09EgchS2ogZQZ3uE5vRdj5r4FyHSI1R8wPLHLhJ3b\nJYAj\r\n=qvkC\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"a40bed26d3a0d318eef2a3739ad75c6617fe6c81","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"6.4.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"8.14.0","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.4-a40bed26-b16_1544802374927_0.4338688387687657","host":"s3://npm-registry-packages"}},"2.5.5-aeb5eb45-b17":{"name":"addict-ioc","version":"2.5.5-aeb5eb45-b17","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.5-aeb5eb45-b17","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"4615d80f24c8789e36c542a690547f672abc2587","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.5-aeb5eb45-b17.tgz","fileCount":102,"integrity":"sha512-hJrICfq+4qJUjv0GUh9wmhCXeKXFq8fECQPtIjYW9y5b/mH4e3Iqlu99N2o2eDsHhbL/gJO8ujkW+3LgBDKeQA==","signatures":[{"sig":"MEUCIFILO8zlYGMT3sY9czftt1l9JvJtqjKLGvbyJVMQbQhiAiEAiOGjHggIBs16PsscpQUppVRwXkkaLfzvTj8qAWt5Gds=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":631778,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcdPm6CRA9TVsSAnZWagAAiEUQAJRthClaG0jJcRkfm6qS\nW+uEJInrwG8cVmjZmtnNeEvDfgoxjKpJYuKxEIr/hwd9Izq/XSAabJ6lNi42\nl7yWokK7IA2bIaitDkkmd0blVNJj7kDJ4yHd1BnurHr+xs4BxX6ExwSKWaNG\nGmYn0Dy1qn8o2sHliSq6YZKwSbiVMyXKp+sCea/CEBusYicF4GTfrF6gR0N5\np0nKVAaF6bTi+gVj7ZW13fg1G/UeI8lCFCFzsiLYd5b6Y6uI97IOHtTKleHC\nTmsAa1OaKuDi/rzmh3cEZ9ip5uOMfGVb5I1iEhD4iOi7wwEMp0CNiKeHa31v\nNKT7qnew3yg3aJe1aWH/IBOn8dpcwdMGawUpeLpybO6rPy/2HuDgN7trWVlj\nJ9sx9EdBSn4s2ECh9dC8ofdXZS6dSMY0Ok2fvmsY9ArKxScdyIcN0FkHXjFo\nfqBvInGUdVvClbb+saY79czvCAKTKJ0PUozjjaPTmJEXGoDkSZADsJHz5gMf\nmxJsvHtPTLNvhdMHsWPVpUHQFL/X1+4F2f81o4IGXFe/uj2lgg7R0B6WppYN\nTo9Nb0riSLdURd8Ojc0dCAmuuT22kVquyP/cYN+qjouYNt/phjYULTsHAwDQ\n6VQZ4U6jBIOGS9P+SQJPrtwcGPLuv1D6c95VjEC5BS4uSwyGzaZNKqqlJdKy\naxhS\r\n=EIwO\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"aeb5eb45141e992455b394b2f45324a57ab728fa","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"6.4.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"10.15.1","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.5-aeb5eb45-b17_1551169978037_0.5912270095092076","host":"s3://npm-registry-packages"}},"2.5.5":{"name":"addict-ioc","version":"2.5.5","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.5","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"31fc776ebee2c14ec6411fbb771c3157f3759809","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.5.tgz","fileCount":102,"integrity":"sha512-ln4R/7mfSFgveGMUSsa/1bfm9O87XCx0BT60vja4cT1jybkHDBjAnGsiEjJOIisuIMmuOLDI5L0NnIJtC3tjbQ==","signatures":[{"sig":"MEUCIHnJe3YXb6Tpwf5BRYHufqR2tSOpI9x567UKO30+HCnmAiEAxcCBph8PcSfnk13lTKXpgW9PHi2pxko/MBv8CwIcN4Q=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":631765,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcdPoyCRA9TVsSAnZWagAACYEP/ipovgCdL4lmU53B5/nx\nkm497ppgxhoX8kmuVr2W2QUUdgxbq06dKqIUZJOw/IqWeRRQ5lqS9Ph8zm4f\n87o0jiECN8BjEyBlri0rN8+uXG1zRnPelMpjFJWAsgWrt55Z2afEycV57zTu\nb7Cr4G9zK8l1BUHNfk/0vow+t4RS4+t9u55tirKzGf/1GO4FLzb0Fyp0Jbme\nH4S2QsjASo1N6GWL+mZs193MShn/PFErUEDLfPHweWetGOmXmkMZ7I1xSOW5\nKQvbeMnyfsqcsDJ7osDRHr7vtIShKx1dB1npHt9tKTGTtlb208G5PrOjDASs\nNhLQbaI7SUDDjq5RDulate88+faiXutvmN683rauJNryH2h8zMV/kHNGHlNe\nxr/ZGnGsi4H9rOX/Bwt8mXY8u6y7GSh7hAUaGfmiFzOg0nGcyS/2Au2Zw1TF\nTUhtQ5VZI/VNa0JObAmv3nw1SMR4T/1QyxKHwnIvJ+Ql79q2OOa9dEAnCHl6\nviwtBby78Pmj4qs9nxRAeNN2edJIhkc+h618Cx2QC/H1ND8gazt1x6RK2hW+\nXoOHG+WYKCfb0Fqobt9kqGa42gt4dFnHv0hN3Oqqoyw1njT/24PLxnUitHqn\noZoYrzUR15XjgKJXMKwKoPP/rHQlnSFtvsIWsP7eElHtIEd+rymYqIKkY9aH\nq9Fc\r\n=U0kS\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","gitHead":"a2520d55505384285c911707793b47d0363614fd","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"6.4.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"10.15.1","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"4.0.0","should":"13.2.3","tslint":"5.11.0","tsconfig":"7.0.0","gulptraum":"~3.0.0","@types/node":"10.12.10","gulptraum-typescript":"~2.0.0","tslint-config-5minds":"1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.5_1551170097291_0.5287528899773248","host":"s3://npm-registry-packages"}},"2.5.6-a5d0200a-b1":{"name":"addict-ioc","version":"2.5.6-a5d0200a-b1","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.6-a5d0200a-b1","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"9f5ac36f68e69651f09db4442f4a40d7c44bc91f","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.6-a5d0200a-b1.tgz","fileCount":102,"integrity":"sha512-JgLEQrvqCbbYwLbgUMdSTt6yP5hjEgT8+dDrb/dFzRFGFxgnneEkoTpePZMOhx/clH+TF04fIn36Q7as9npNlQ==","signatures":[{"sig":"MEUCIQCIJxpFKpPu2KlxJwzyoOz9ksxA0oAYBfyy1oaY4gMuegIgfi95Lo4LUD4VvILiMKpMhEMyCKkPW/Q57aPjjdZqdPw=","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":631789,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcdPywCRA9TVsSAnZWagAAcF4P/3XbsmFs1LHnKVK8fvYa\ncZtJvVz/9/lOPyD6VIHP7q6rmhpNKfydvWG5K7zQk1a0PdEKA2vqmzluRduK\nudq7hkt1jsstFtMIRxcFB46/E6McujU/nj3x0jp2Ki1ZN5mkIL7vNNAE8BHa\nDabjLO/OcBZIWGW+yOb16WoWupeHyRprRfMakUTvttrf3tYA9EIgmi0ajZME\n7rqDM8uF6h5kJvBTJ+6K1pOMCmT/XnPfvQBIcurMPbePvyHx6MsvWzys9AYr\nafBAa/07r+d9P5LYdIINyjJN+cT1dN+sG4W2rkojuQ8xbqGqHpiqP6tHBB3n\nFDejrrpvnRg96Wt3xJXbohaaftuE9LcpTS9Kfc/WFopy150NGF3g9lsqhX1J\nlnffNiXi7bWfdZl4Hz3MbleTC0iz4LOhtZ4+wR/XUgiYFoUroMePdXWyKsVk\nVog2dj2mgL0Tzx/ST/1KSSsaouCZZMsB2mWDwatcNHXugKxqZ09lreuzr/Os\nZSDXU4ntAMCCU03rP8Z7sKNonIiMr+YMDoKm+8G6nWtEY8SGAqTEJS46Fs97\nOT8iexLS45NksH3gIx7SWn7f6H1Xz524Y/fHSXfjcG2ITU6QTarYoM9sLwJb\n+U2fDkgPUVrWj2Q9FB1ASubJP2y9nQ3mh8Jgu4BMyWnicgjYOKYUoyokM222\nkTY9\r\n=+Kfq\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"a5d0200a8321126ec9b3c4433b39838074e69796","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"6.4.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"10.15.1","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"^4.0.0","should":"^13.2.3","tslint":"^5.11.0","tsconfig":"^7.0.0","gulptraum":"^3.1.0","@types/node":"^10.12.10","gulptraum-typescript":"^3.0.0","tslint-config-5minds":"^1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.6-a5d0200a-b1_1551170735346_0.6278811651707874","host":"s3://npm-registry-packages"}},"2.5.6-aa216cb5-b18":{"name":"addict-ioc","version":"2.5.6-aa216cb5-b18","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.6-aa216cb5-b18","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"03f8ee5af41f664d625a810584f5a77a698fe257","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.6-aa216cb5-b18.tgz","fileCount":102,"integrity":"sha512-au1wTbC5kBJ0HsXdvHwtSlnjO+xF9m8DRQeahlvlyfFJ/fRCuhHFkQJ/68ddv3cjzpI9i9laOTr8vihD+82Zxw==","signatures":[{"sig":"MEQCIBhPy6V8OxMib7LZybERntFiNrx4hB/5LgLbyYTBg8ELAiBO2ULuo2HeypxjWI8BXgleKzzwIlJD79v+IhRk/asnjA==","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":631790,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcdQOLCRA9TVsSAnZWagAAq4IP/1NxE7xlrshKPHOE6yj7\nVLy/GCRWCiN1Ysbq3K5kXbsbhy6dWb//oVzO236KCeIy8AbWGJ+eg2ulZuEm\nVVU3/d7oMxTNbWCt5yYvAJdbs534jRFXm7ybEbTdvMHcdittl19miihLIC9l\n3Bq7hYH6+aL/k4NuKVg8mFdeHYf4n4b5PffyiHHPtjl6RWXD6w6+AwR1K/Xl\nJtxFDmihjs3K97g2TLRtrYiblzOuPMQLwKW5aNGhl01qPTUoeQgy4jiV3NAD\n07tyCcS950/z6J7vSGS3eSJ2sRZL0IUOEmGJunFZppgQHwV5tPtEXr5bqe2E\n2KUgr1IX+KEkwTYruBuoOQ4eA1ms2GUUbtSCatXN6I4nLQ+hqZ0IiZU3T//C\nmSocYdvyXap12H3FysxiiwORuR1MYxrraIx+kyqc6TC0nT6DHehcRQdUffc6\nKKqRqbK9jakWVdF/gFFwO/Sf0pJ2dSaGB8wDXdqKxgDo8kkBubiXnNJWiZIg\nUiLjQsRFqFKGkRAlGYODF/PDUqxt7egTY1bctxV2cOSVqUTq+ctoSx7m5lx4\nmsxT1ovkGgmYI8jEWdvvShclmnM+IW73o3rKQHv/zVrjwTILeHoh8ZPGr7PH\n7dyZZYsq8wZHWPU3ycp4UFbRHCVDhKdEct5AYt9uXwvyjlSNZ27oXz2YOl17\nz7zC\r\n=ibp3\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","gitHead":"aa216cb5337a0fb58f2c53c1291a4178d4955984","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"6.4.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"10.15.1","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"gulp":"^4.0.0","should":"^13.2.3","tslint":"^5.11.0","tsconfig":"^7.0.0","gulptraum":"^3.1.0","@types/node":"^10.12.10","gulptraum-typescript":"^3.0.0","tslint-config-5minds":"^1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.6-aa216cb5-b18_1551172490722_0.3937608477587793","host":"s3://npm-registry-packages"}},"2.5.6":{"name":"addict-ioc","version":"2.5.6","keywords":["ioc","dependency","injection","fluent","addict"],"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","_id":"addict-ioc@2.5.6","maintainers":[{"name":"sebastian.meier","email":"sebastian.meier@5minds.de"}],"contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"homepage":"https://github.com/5minds/addict-ioc#readme","bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"dist":{"shasum":"029379543ebe90f0cee87c4d68ce3dcf1982306e","tarball":"https://registry.npmjs.org/addict-ioc/-/addict-ioc-2.5.6.tgz","fileCount":102,"integrity":"sha512-zFX1z3zlw2p4Xa9qqiIFX83dRMXj7r/jSCVvJ7pZCbS3HMQhKxzCNv/c+kXpEixiZTGy2fm/kk8jvrJmFbhh9Q==","signatures":[{"sig":"MEYCIQDWWHAK6I5k/aKbVlsZ9SgW/nTRCESmIjv5VCNvX0bh/gIhALBJXQTPAOSR0QypvLjsas/NVyG1kfOUJtgLpYmCepeY","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"}],"unpackedSize":631777,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcdQO/CRA9TVsSAnZWagAAY5oP/iYwFKMZtDuDcY6LSuIo\n0+uMpZqPHqhrohOsq07LxPBsnz0TAGLfLzZ/FJX7QNR9c1tPIoNstTZ1/nMB\nXmTDItli3iMGP14xA9rvHy/9gSTQD/FIC9QY+qCB2OpcjVzFK43DomvCfF1y\nlZ+L/3qIBpiapt1Qdn4j2eO4sEm9zP61+z0u0xnmgahaZGNLGXIsbWRPSx9B\nuciuxcPpmzNz+mqJlHcRQarUAAIOJSG5a2oPH5pX1QyykdO49m9MiFeoKO46\njHz/AvoG5PXeQN01YBte9px1lA59w2VPhunNLSpgAdo+/BuLQs46utTaLcR1\nlFKzctlbgp8lUdBbIyZYQKLDFjnfnYN07mIa1oZcy8XRK/M2rfvaj2h+TXmG\n3Nyncy8wbsFYdr4NTba+y38UliJVNHc2UCUFT7Err1X0ev2obbM/8BVXlw7T\nIYVwwtJyvu00kgaH31xE9EPeZHhP4XXJ3lmxmR7aiSp5G6L4XUMZ5xOJCdDs\nsredZrsBPXj9QlPAR5qPX7jjqgGuVAW1jsrMsUS1/jjCwjIrKIFyrxsUIbIE\nzHWlC5tTwtKuL9p/PKkbCLKsg/KtP8DN5qSOMGUBIvAHk/RTQVbCRzCHHBty\nZJ9CIWvVuikAZHlUokh0rprCYyAkRMoBFPYMDjgBCy4K3lEhJAji1UfZB2JS\nS5nm\r\n=kQCq\r\n-----END PGP SIGNATURE-----\r\n"},"main":"dist/commonjs/index.js","gitHead":"aa216cb5337a0fb58f2c53c1291a4178d4955984","scripts":{"lint":"gulp lint","test":"mocha test/**/*","build":"gulp build","prepare":"npm run build","build-doc":"gulp doc"},"typings":"dist/index.d.ts","_npmUser":{"name":"process-engine-ci","email":"ci+npm@process-engine.io"},"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.","maintainer":"Sebastian Meier ","repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"_npmVersion":"6.4.1","description":"A fluent IoC container for JavaScript.","directories":{"test":"test"},"_nodeVersion":"10.15.1","dependencies":{"merge":"1.2.1","node-uuid":"1.4.8"},"_hasShrinkwrap":false,"devDependencies":{"gulp":"^4.0.0","should":"^13.2.3","tslint":"^5.11.0","tsconfig":"^7.0.0","gulptraum":"^3.1.0","@types/node":"^10.12.10","gulptraum-typescript":"^3.0.0","tslint-config-5minds":"^1.0.6"},"_npmOperationalInternal":{"tmp":"tmp/addict-ioc_2.5.6_1551172542953_0.09774985511799628","host":"s3://npm-registry-packages"}}},"time":{"created":"2017-01-25T13:38:53.537Z","modified":"2026-05-20T12:08:16.176Z","1.0.0":"2017-01-25T13:38:53.537Z","1.0.1":"2017-01-25T15:06:16.492Z","1.0.2":"2017-01-25T15:40:37.907Z","1.0.3":"2017-01-30T14:04:19.530Z","1.0.4":"2017-01-30T17:52:38.401Z","1.0.5":"2017-01-31T09:12:54.878Z","1.0.6":"2017-02-01T16:07:01.370Z","2.0.0-pre":"2017-05-10T13:19:45.451Z","2.0.0-pre2":"2017-05-10T15:37:31.276Z","2.0.0-pre4":"2017-05-19T15:21:22.463Z","2.0.0":"2017-05-19T15:22:07.725Z","2.0.1":"2017-05-20T08:21:08.596Z","2.0.2":"2017-05-30T17:11:32.308Z","2.0.3":"2017-05-30T17:37:30.946Z","2.0.4":"2017-07-17T13:25:04.288Z","2.0.5":"2017-07-31T07:26:01.616Z","2.0.6":"2017-07-31T09:22:08.082Z","2.0.7":"2017-08-01T15:32:15.479Z","2.0.8":"2017-08-08T13:46:13.429Z","2.0.9":"2017-08-10T08:00:46.258Z","2.0.10":"2017-08-10T09:03:21.934Z","2.0.11":"2017-08-10T12:34:44.238Z","2.1.0":"2017-08-11T11:27:12.581Z","2.1.1":"2017-08-11T11:56:15.126Z","2.2.0":"2017-08-11T15:06:15.137Z","2.2.1":"2017-08-18T14:42:52.533Z","2.2.2":"2017-08-22T08:08:20.742Z","2.2.3":"2017-08-29T12:58:46.305Z","2.2.4":"2017-08-29T14:24:32.527Z","2.2.5":"2017-08-29T15:27:19.925Z","2.2.6":"2017-08-30T06:52:11.034Z","2.2.7":"2017-09-01T08:39:27.421Z","2.2.8":"2017-09-08T17:26:48.839Z","2.2.9":"2017-09-15T08:03:44.642Z","2.2.11":"2017-10-02T19:23:06.549Z","2.2.12":"2017-10-03T06:49:37.241Z","2.3.0":"2017-10-18T15:10:27.519Z","2.3.1":"2017-10-18T15:16:39.004Z","2.3.2":"2017-10-18T15:25:05.116Z","2.3.3":"2017-10-18T16:17:43.255Z","2.3.4":"2017-10-18T16:32:29.079Z","2.3.5":"2018-02-12T16:16:07.761Z","2.3.6":"2018-03-15T16:19:46.802Z","2.3.7":"2018-03-15T16:26:23.052Z","2.4.0":"2018-10-31T13:02:40.981Z","2.5.0":"2018-11-06T08:48:20.036Z","2.5.1-8e3dddf1-b1":"2018-11-07T07:58:23.657Z","2.5.0-5c2de7cb-b4":"2018-11-07T07:58:32.682Z","2.5.0-5c2de7cb-b5":"2018-11-07T08:01:12.536Z","2.5.0-5c2de7cb-b6":"2018-11-07T08:03:06.846Z","2.5.0-5c2de7cb-b7":"2018-11-07T08:05:31.881Z","2.5.0-5c2de7cb-b8":"2018-11-07T08:06:41.166Z","2.5.1-fb73abb3-b9":"2018-11-07T08:25:25.905Z","2.5.1-830a581f-b10":"2018-11-07T08:28:08.331Z","2.5.1":"2018-11-07T08:28:25.503Z","2.5.2-a7a910cd-b1":"2018-11-08T08:41:47.796Z","2.5.2-a7a910cd-b2":"2018-11-08T08:41:52.668Z","2.5.2-05db85ab-b11":"2018-11-08T09:24:23.102Z","2.5.2-c01554f2-b12":"2018-11-08T09:26:04.534Z","2.5.2":"2018-11-08T09:26:09.175Z","2.5.2-6aeffa58-b1":"2018-11-26T13:46:29.782Z","2.5.3":"2018-11-27T10:50:16.416Z","2.5.3-19041ba5-b13":"2018-11-27T10:50:20.747Z","2.5.4-951816ec-b1":"2018-12-03T12:50:27.474Z","2.5.4-7085a551-b14":"2018-12-03T12:53:02.798Z","2.5.4-a40bed26-b15":"2018-12-03T12:55:06.273Z","2.5.4":"2018-12-03T12:55:12.410Z","2.5.4-a40bed26-b16":"2018-12-14T15:46:15.188Z","2.5.5-aeb5eb45-b17":"2019-02-26T08:32:58.233Z","2.5.5":"2019-02-26T08:34:57.753Z","2.5.6-a5d0200a-b1":"2019-02-26T08:45:35.539Z","2.5.6-aa216cb5-b18":"2019-02-26T09:14:50.909Z","2.5.6":"2019-02-26T09:15:43.073Z"},"bugs":{"url":"https://github.com/5minds/addict-ioc/issues"},"author":{"name":"5Minds IT-Solutions GmbH & Co. KG","email":"info@5minds.de"},"license":"ISC","homepage":"https://github.com/5minds/addict-ioc#readme","keywords":["ioc","dependency","injection","fluent","addict"],"repository":{"url":"git+https://github.com/5minds/addict-ioc.git","type":"git"},"description":"A fluent IoC container for JavaScript.","contributors":[{"name":"HUF Secure Mobile","email":"info@hufsm.com"},{"name":"Martin Möllenbeck","email":"martin.moellenbeck@5minds.de"},{"name":"Christian Werner","email":"christian.werner@5minds.de"}],"maintainers":[{"email":"support@npmjs.com","name":"npm-support"}],"readme":"![logo](./images/logo.png)\n\nAddict IoC is a lightweight IoC container with a fluent declaration syntax,\neasing your development and simplifying your code.\n\nIt is designed to be easily extensible for your own needs, without complicating\nthe architecture by abstractions.\n\n[![Build Status](http://jenkins.mindassist.net/buildStatus/icon?job=Addict.IoC)](https://jenkins.mindassist.net/job/Addict.IoC)\n\n# Features\n\n```\n* Fluent declaration syntax\n* Fully covered by unit tests\n* Written in TypeScript, transpiled into ES2017\n * Lightweight\n * Well structured, easily understandable code\n * Typings included\n* Dependency Injection into\n * Constructor\n * Properties\n * Methods\n* Discovery by tags and key/value matching\n* Singleton or transient instantiation\n* Injection with lazy instantiation\n* Support for factory functions\n* Circular dependency detection\n* Configuration injection\n* Optional auto-bind methods (e.g.: EventHandler) to instance\n* Validation of registered dependencies\n* Supports service locator pattern\n```\n\n# Table of Contents\n\n1. [Basic Usage](#basic-usage)\n 1. [Import Package](#import-package)\n 1. [Customizing Default settings](#customizing-default-settings)\n 1. [Dependency Injection](#dependency-injection)\n1. [Advanced Usage](#advanced-usage)\n 1. [IoC Module Pattern](#ioc-module-pattern)\n 1. [Registration](#registration)\n * [Register a class](#register-a-class)\n * [Register a factory function](#Register-a-factory-function)\n * [Register a static object](#register-a-static-object)\n 1. [Resolving a Registration](#resolving-a-registration)\n * [Resolve instance with injection arguments](#resolve-instance-with-injection-arguments)\n * [Resolve factory with injection arguments](#resolve-factory-with-injection-arguments)\n 1. [Lazy Injection](#lazy-injection)\n 1. [Configuration](#configuration)\n * [Static configuration](#static-configuration)\n * [With Function Reference (defered)](#with-function-reference-(defered))\n 1. [Validation](#validation)\n 1. [Discovery](#discovery)\n * [Simple string tags](#simple-string-tags)\n * [Tags with Key-Value pairs](#tags-with-key-value-pairs)\n 1. [Multiplicity](#multiplicity)\n * [Transient](#transient)\n * [Singleton](#singleton)\n 1. [Overwrite Dependencies](#overwrite-dependencies)\n 1. [Bind Functions to Instance](#bind-functions-to-instance)\n 1. [Targeted Injection](#targeted-injection)\n * [Inject into property](#inject-into-property)\n * [Inject into function](#inject-into-function)\n1. [Supported by](#supported-by)\n\n\n# Basic Usage\n\n## Import Package\n\nThe package exports the container class under the key `Container`.\nIdeally, you want to instantiate the container only once and use that instance\nthroughout your application.\n\nUsing plain NodeJS (up to ES5), you can create a container like this:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst container = new Container();\n```\n\nWhen using ES6, you can use the new `import` structure:\n\n```js\nimport {Container} from 'addict-ioc';\n\nconst container = new Container();\n```\n\nAnd using TypeScript, it will look like this:\n\n```TypeScript\nimport {Container} from 'addict-ioc';\n\nconst container: Container = new Container();\n```\n\nThat's it.\nNow you are ready to fill your new container with life.\n\nFor the sake of simplicity, we will stick with the old-school ES5 notation\nthroughout this Readme.\n\n## Customizing Default settings\n\nThe container comes with a wide range of settings, all of which will get a well\nthought-out set of defaults.\nThese settings are automatically applied to any registration added to the container.\n\nShould you wish to pass your own settings to the container, you can do so by\npassing your own set of configurations into the constructor.\n\nHere is an example:\n\n```js\nconst Container = require('addict-ioc').Container;\n\nconst myOverwrittenSettings = {\n isSingleton: false,\n isFactory: false,\n conventionCalls = ['initialize'],\n}\n\nconst container = new Container(myOverwrittenSettings);\n```\n\nHere is a list of all possible settings and their default values:\n\n```js\nconst defaultSettings = {\n defaults: {\n isSingleton: false,\n isTrueSingleton: false,\n wantsInjection: true,\n dependencies: [],\n lazyDependencies: [],\n lazyDependenciesAsync: [],\n ownedDependencies: [],\n functionsToBind: [],\n overwrittenKeys: {},\n overwrittenConventionCalls: {},\n injectConventionCalled: {},\n },\n // This is the default resolver, provided by the addict-ioc package.\n // The resolver will perform the task of creating instances from your\n // registered types.\n resolver: new Resolver(),\n // The key under which the container itself is registered.\n // This will allow you to inject the container into a resolved instance.\n containerRegistrationKey: 'container',\n // Circular dependencies are usually safe, when using singletons.\n // But if you still want the container to throw an error, when detecting a\n // circular dependency with singletons, you can set this to \"false\".\n circularDependencyCanIncludeSingleton: true,\n // Same as above, only for lazy dependencies.\n circularDependencyCanIncludeLazy: true,\n conventionCallTypes: [ConventionCallType.Class],\n};\n```\n\n## Dependency Injection\n\nBasic dependency injection is easily achieved.\nYou just need to register one or more types at the container,\nusing the `container.register('key', type)` function.\n\nAfterwards, these types can be declared as dependencies at any\nregistration.\n\nBy default, each dependency is injected into the resolved instance's constructor.\n\nExample:\n\n```js\n\n// Some test class.\nclass SomeEmailService {}\n\n// Another test class.\nclass SomeUserService {}\n\n// A test class that has both of the above classes as a dependency.\nclass MyUserNotifier {\n\n constructor(emailService, userService) {\n this._emailService = emailService;\n this._userService = userService;\n }\n}\n\n// Register the test classes:\n// Note that the key does not have to match the name of the type you are\n// registering here.\n// You can use whatever key you like.\ncontainer.register('EmailService', SomeEmailService);\ncontainer.register('UserService', SomeUserService);\n\n// Now register the test class that uses the others as dependencies.\n// Keep in mind that the dependencies will be injected in the same order as stated\n// here.\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n\nconst myUserNotifierInstance = container.resolve('UserNotifier');\n```\n\nCalling `container.resolve('UserNotifier')`, will get you an instance of\n'MyUserNotififer', which in turn will get an instance of 'SomeUserRepository'\nand 'SomeEmailService' injected into its constructor.\n\nThat's it.\n\n# Advanced Usage\n\n## IoC Module Pattern\n\nSince the IoC container is used to decouple your applications components,\nit is not a good idea to directly use the container in all of your classes.\n\nConsider the following example as an `ANTI`-pattern:\n\n```js\nconst container = require('addict-ioc');\n\nclass MyUserRepository {\n // ...\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nmodule.exports = MyUserRepository;\n```\n\nWhen you have, say, five dozen classes you wish to register in the\ncontainer, this pattern will become very hard to maintain, since all\nregistrations are floating around in five dozen different places.\n\nLet's consider a more modular approach, where your application consists of\nseveral self-contained modules.\nEach of the modules should know how the dependencies of its inner classes\ninteract and which external dependencies it has.\n\nNow, if we take a closer look at those external dependencies, the self-contained\nmodule needs a way to reference its external dependencies, so that the external\ndependency itself can load its dependencies the same way\n(yep we're building a dependency tree here).\n\nThe easiest way to achieve this is to let each self-contained module expose a\nfunction that takes the container instance as a parameter and registers all\ndependencies on that instance.\n\n\n```js\n// modules/user/ioc_module.js\n\nfunction registerInContainer(container) {\n\n const ItemIocModule = require('item/ioc_module');\n\n // Contains a registration for 'ItemService' and other\n // related registations.\n ItemIocModule.registerInContainer(container);\n\n\n container\n .register('UserRepo')\n .singleton();\n\n container\n .register('UserService')\n .dependencies('UserRepo', 'ItemService')\n .singleton();\n\n}\n\nmodule.exports.registerInContainer = registerInContainer;\n```\n\nThe following folder structure shows how functional modules can consist of\nseveral layers, in this case `service` and `repository` layers.\n\nEvery module defines its dependencies via an `ioc_module.js` and can reference\nother modules' ioc modules as well, just like in the example above.\n\n```\nmodules/\n user/\n modules/\n user_service/\n lib/\n user_service.js\n user_repository/\n lib/\n user_repository.js\n index.js\n ioc_module.js\n package.json\n item/\n modules/\n ...\n index.js\n ioc_module.js\n package.json\nindex.js\nioc_module.js\npackage.json\n```\n\n## Registration\n\nThe container provides multiple functions for creating registrations.\nEach of these functions returns the created registration, which allows the use\nof a fluent syntax for declaring and enhancing registrations.\n\nFor example:\n\n```js\n\ncontainer\n .register('someKey' sometype)\n .dependencies('someService')\n .injectInto('someTargetPropertyForTheDependency')\n .configure('some:path:to:a:config')\n .singleton();\n```\n\nThis creates a registration and performs multiple configurations on it.\n\nDon't worry if you don't understand what the chained functions do at this point.\nEach of them will be explained in a later chapter.\n\nThis example only serves to demonstrate the fluent syntax that the addict-ioc\ncontainer allows.\n\n**Important**:\nRemember that each chain **must** begin with a call to `container.register()`\nor one of its equivalents!\nThis is because each of the follow up functions is a part of the `registration`\nclass, an instance of which is returned by the `register` function.\n\nNow lets take a closer look at each of the functions used for creating a registration.\n\n### Register a class\n\nThe default method for creating a registation is `register`.\nThis method is used for registering classes at the ioc container, which is its\nmost prominent UseCase.\n\n```js\nclass MyUserRepository {}\n\ncontainer.register('UserRepo', MyUserRepository);\n```\n\n### Register a factory function\n\nYou can register a factory function through the `registerFactory` function.\n\nWhen calling `resolve`, the factory function is executed and its result is\nreturned to the caller.\n\nThis allows you to create instances suited to a very specific purpose.\n\n```js\nconst factory = (something) => {\n return {\n logIt: () => {\n console.log(something);\n }\n }\n}\n\ncontainer.registerFactory('factoryKey', factory);\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nIt is also possible to pass some dependencies to the factory, which the factory\ncan then pass to the instances it creates.\n\nTo do this, you need to specify a target property or function into which the\ndependencies are to be injected.\n\n```js\nclass EmailService {}\n\nconst factory = () => {\n return {\n setEmailService: (injectedEmailService) => {\n this.emailService = injectedEmailService;\n },\n };\n};\n\ncontainer.register('EmailService', EmailService);\n\ncontainer\n .registerFactory('factoryKey', factory)\n .dependencies('EmailService')\n .injectInto('setEmailService');\n\nconst resolvedInstance = container.resolve('factoryKey');\n```\n\nThe factory will now return an instance of an object, which will get the\n`EmailService` injected into its `setEmailService` function.\n\n**Important** The target needs to be a property or function on the *instance*\nthe factory creates, **not** the factory itself!\n\n### Register a static object\n\nYou can also register plain objects in the container.\nWhen resolving these, they will - obviously - not be instantiated.\n\nThis can be useful, when you wish to make some information globally available,\nor when you want to handle instance creation yourself.\n\n```js\nconst object = {\n 'this-could-be': 'virtually-anything',\n}\n\ncontainer.registerObject('objectKey', object);\n```\n\n**Note**:\nThe following features are not available for object registrations:\n- `dependencies`\n- `injectInto`\n- `singleton`\n- `bindFunctions`\n\nUsing any of these with an object registration will result in an error!\n\n## Resolving a Registration\n\nResolving a registration is easy:\n\n```js\nconst result = container.resolve('SomeKey');\n```\n\nOr for resolving asynchronously:\n\n```js\nconst result = container.resolveAsync('SomeKey');\n```\n\nThis works the same for all types of registrations.\n\n### Resolve instance with injection arguments\n\nYou can also pass customized arguments to each resolved instance,\nby passing an additional parameter to the `resolve` method:\n\n```js\nclass MyUserRepository {\n constructor(instanceParams) {\n this.params = instanceParams;\n }\n\n get params() {\n return this.params;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = 'hello world';\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.params) // This will print 'hello world'.\n```\n\nThis allows for each instance to receive very specific information,\nunique to each instance.\n\nYou can also pass multiple arguments to each instance.\nThese need to be contained in an Array:\n\n```js\nclass MyUserRepository {\n constructor(param1, param2) {\n this.param1 = param1;\n this.param2 = param2;\n }\n\n calculate() {\n return this.param1 + this.param2;\n }\n}\n\ncontainer.register('UserRepo', MyUserRepository);\n\nconst instanceParams = [1, 2];\n\nconst userRepoInstance = container.resolve('UserRepo', instanceParams);\n\nconsole.log(userRepoInstance.calculate()) // This will print 3.\n```\n\nThese arguments are not limited to any specific types and can contain whatever\nyou like.\n\n### Resolve factory with injection arguments\n\nThe same mechanism can also be used for factories.\n\nFor example:\n\n```js\nconst factory = (injectedArg1, injectedArg2) => {\n return {\n calculate: () => { return injectedArg1 + injectedArg2; },\n };\n};\n\ncontainer.registerFactory('mathFactory', factory);\n\nconst sampleInjectionArgs = [1, 2];\n\nconst resolvedInstance = container.resolve('mathFactory', sampleInjectionArgs);\n\nconst calucationResult = resolvedInstance.calculate(); // The result will be 3.\n```\n\n## Lazy Injection\n\nThe `injectLazy` declaration allows the registration to determine the point in\ntime a class gets instantiated itself.\n\n`lazy` dependencies will not be injected as an instance. Instead, the registered\nclass will get a factory function for that dependency.\n\nThe instance will only be created, when the factory function is called.\n\nThis can be very useful, if a class wants to inject some context-specific\ndata into the dependency in question.\n\n```js\nclass SomeClass {\n constructor(args) {\n this._arguments = args;\n }\n\n increment() {\n return this._arguments * 2;\n }\n}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someClassFactory) {\n this._someClassFactory = someClassFactory;\n }\n\n start() {\n const instanceSpecificInfo = this.getInstanceSpecificStuff();\n this._someClass = this._someClassFactory(instanceSpecificInfo);\n }\n\n getInstanceSpecificStuff() {\n return 2;\n }\n\n printIncrementedValue() {\n console.log(this._someClass.increment()) // This will print 4.\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\n*Note*: The arguments injected into the factory function will be **appended** to\nthe instances registered dependencies.\nNo dependency gets overwritten.\n\n## Configuration\n\nThe `configure` declaration allows you to set the `config` property of a class\ninstantiated by the container.\n\n### Static configuration\n\nThis is the simplest type of configuration, in which you just pass the full set\nof configs to the `.configure()` method.\n\n```js\n\nclass SomeClass {\n\n set config(value) {\n this._config = value;\n }\n\n start() {\n console.log(this._config.configValue); // something\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .configure({configValue: 'something'});\n```\n\n### With Function Reference (defered)\n\nHere, the `config` function gets executed, when the registered class it is\nassociated to gets instantiated.\n\n```js\nclass SomeClass {\n\n get config() {\n return this._config;\n }\n\n set config(value) {\n this._config = value;\n }\n}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .config(() => {\n console.log('config function executed');\n return { aConfigValue: 'something' }\n });\n\nclass SomeOtherClass {\n\n constructor(someClassLazy) {\n this._someClassLazy = someClassLazy;\n }\n\n start() {\n const someClass = this._someClassLazy(); // config function executed\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectLazy();\n```\n\nIn case this class gets injected lazily, meaning the `config` function will not\nbe executed until the lazy injection is resolved.\n\n## Validation\n\nBefore you start an application that uses the IoC container, you typically want\nto be sure that you declared all the dependencies correctly, so that you won't\nget any nasty errors during runtime.\n\nFor this purpose, the IoC container exposes the method `validateDependencies`.\n\nYou can call it in three different ways:\n- No parameters: This will validate all registrations\n- A single String: Only validate the registration with the given key\n- String-Array: Validates only the given set of keys\n\n```js\nclass SomeClass {}\n\ncontainer\n .register('SomeClassKey', SomeClass)\n .dependencies('SomeMissingRegistrationKey');\n\ntry {\n container.validateDependencies();\n} catch(error) {\n // this will throw because there is a dependency missing\n}\n```\n\nThis method will not throw an error on the first failed validation.\nInstead, it will collect all validation errors first and then throw\na validation error that contains a comprehensive report about *all*\nencountered errors.\n\n*Note*: The IoC container will see a circular dependency as valid, if there is\na `singleton` dependency in the tree.\nYou can adjust this by setting the value for the config parameter\n`circularDependencyCanIncludeSingleton` to **false**.\nThis will cause the container to mark a circular dependency as invalid, even if\na singleton is present in it.\n\nThe same goes for `lazy` dependencies.\nBy default, a circular dependency will be seen as valid, if at least one `lazy`\ndependency is present.\nIf you want to prevent this, set `circularDependencyCanIncludeLazy` to **false**.\n\n## Discovery\n\nThe main goal of the IoC container is to decouple an applications components\nand establish clear architectural patterns.\n\nWe should embrace that thought and use extension points in our applications.\nAn extension point is a component that uses the container to instantiate other\ncomponents by itself.\nThese are usually grouped under a specific topic or cover a specific UseCase.\n\nAn example would be a HTTP server, which uses the ioc container to instantiate\nall routers that are registered within that container.\n\nNow, if we want to decouple that server from the routers it instantiates,\nwe need some kind of discovery, because otherwise we would need to reference\nthose components directly within the server.\nThis would make the decoupling attempt rather pointless.\n\nIn order for the discovery to work as we intend, we need some kind of marker,\nby which an extension can actually retrieve the components it needs.\nUsing specific naming would be one possibility, but that is highly unreliable\nand easily prone to errors; simple typos can throw your application into chaos.\n\nTo get around this and offer an easy and reliable way to make the discovery work,\nthe ioc container offers a fluent way to attach tags to a registration.\nThese tags can be simple strings, or key-value pairs and will not influence the\nregistration itself in any way.\n\nConsider the following (very much simplified) sample stack:\n\n![discovery example](./images/sample_server_stack.png)\n\nHere we have a HTTP server that has to discover and manage two routers.\nThe server itself knows nothing of the routers themselves and thus, is not\ncoupled to them.\n\nThe routers each have a tag attached to them that marks them as routers.\nBy use of this tag, the Http server can use the container to discover these\nrouters and then initialize them.\n\nThe routers themselves will have their dependencies resolve the old-fashion way,\nby use of normal ioc registrations.\n\n### Simple string tags\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .tags('caching');\n\nclass MemcachedImplementation {}\n\n// You can attach as many tags as you like.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .tags('caching', 'secondary');\n```\n\nBoth of our test classes are tagged with the same string `caching`.\nThese can now be discovered by calling the `getKeysByTags` method:\n\n```js\n\nconst discoveredKeys = container.getKeysByTags('caching');\n\nconsole.log(discoveredKeys);\n// This will return:\n// 'RedisImplementation'\n// 'MemcachedImplementation'\n```\n\nThis function will return all registrations, which will have the `caching` tag\nattached to it, including those registrations who have additional tags attached\nto them.\n\n### Tags with Key-Value pairs\n\nIf you wish to attach a tag with a key-value pair, you can use the `setTag` method.\n\n```js\nclass RedisImplementation {}\n\ncontainer\n .register('Redis', RedisImplementation)\n .setTag('caching', 'primaryImplementation');\n\nclass MemcachedImplementation {}\n\n// To attach multiple key-value tags, the setTag function must be called\n// repeatedly.\ncontainer\n .register('Memcached', MemcachedImplementation)\n .setTag('caching', 'secondaryImplementation')\n .setTag('someOtherTag', 'someOtherValue');\n```\n\nTo discover registrations that have tags with a specific value,\nyou can provide a dictionary that contains the key-value pairs to look for.\n\n```js\nconst attributeQuery = {\n caching: 'primaryImplementation',\n};\n\nconst foundKeys = container.getKeysByTags(attributeQuery);\n// This will return 'RedisImplementation'\n```\n\n## Multiplicity\n\nThe `singleton` function determines, wether a registration is a singleton,\nor a transient component.\n\n### Transient\n\nBy default, all registrations are transient, meaning that each time we `resolve`\na registration, it will be a new instance of that registration.\n\nThe same goes for `lazy` registrations or any of the registrations' dependencies.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n //.singleton(false); this can be configured explicitly as well\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"false\"\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n### Singleton\n\nDeclaring a registration as `singleton` will cause the `resolve` method to always\nreturn the *same* instance of that registration.\n\nThis means that only one instance is created, when the registration is first\nresolved.\nAfterwards, the same instance is used every time somebody calls resolve for the\nsame registrations key.\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass)\n .singleton();\n // this is equal to:\n // .singleton(true);\n\nclass SomeOtherClass {\n\n constructor(something, alsoSomething) {\n console.log(something === alsoSomething); // \"true\"\n }\n}\n\ncontainer.register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey', 'SomeClassKey');\n```\n\n## Overwrite Dependencies\n\nLets revisit the `dependencies` example shown at the beginning:\n\n```js\n\nclass SomeUserRepository {}\n\ncontainer.register('UserRepo', SomeUserRepository);\n\nclass SomeEmailService {}\n\ncontainer.register('EmailService', SomeEmailService);\n\nclass MyUserNotifier {\n\n constructor(userRepository, emailService) {\n this._userRepository = userRepository;\n this._emailService = emailService;\n }\n}\n\ncontainer\n .register('UserNotifier', MyUserNotifier)\n .dependencies('UserRepo', 'EmailService');\n```\n\nIn special cases you might want to overwrite a registration without side effects\nto other registrations.\n\nFor this scenario the IoC container offers the fluent declaration `overwrite`.\nYou can use this multiple times on the same registration, once for every\noverwritten key.\n\nOverwriting a dependency key means that upon resolving that dependency, the\nkey specified in the overwrite is used, instead of the original one.\n\nExample:\n\n```js\nclass MyEmailValidator {}\n\ncontainer.register('EmailValidation', MyEmailValidator);\n\nclass MyMuchBetterEmailValidator {}\n\ncontainer.register('BetterEmailValidation', MyMuchBetterEmailValidator);\n\nclass MyEmailService {}\n\ncontainer.register('EmailService', MyEmailService)\n .dependencies('EmailValidation')\n .overwrite('EmailValidation', 'BetterEmailValidation');\n```\n\nHere we declare a dependency to `EmailValidation` on the `EmailService`\nregistration.\nThat dependency then gets overwritten with `BetterEmailValidation`.\nWhen we now resolve the `EmailValidation` registration, the resulting instance\nwill not get an instance of the `MyEmailValidator`, but the\n`MyMuchBetterEmailValidator` class.\n\n## Bind Functions to Instance\n\nWhen you want to use a class instance as an event handler, you may notice that\nby default ES6 class functions have no bound `this` context when referencing them.\n\nSo if you want to use them like in the following example, you'll get an error,\nbecause `this` is undefined.\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n testMethod() {\n console.log(this.testString);\n }\n};\n\nconst testType = new TestType();\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.testMethod);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\nThis is a common problem when passing handler functions.\nNormally you would simply alter the previous example.\n\n```js\ntestFunction(testType.testMethod.bind(testType));\n```\n\nThis could get cumbersome when you have multiple such cases, especially when\nthey are spread across multiple classes/modules.\n\nThe IoC container exposes the fluent declaration `bindFunctions` to help out\nwith this.\n\nIf called *without* parameters, it binds **all** methods of the class to the\nclass itself, so that you don't have to do any manual binding.\n\nIf you don't want all methods of the class to be bound, you can supply a list\nof method names to `bindFunctions`.\n\nExample:\n\n```js\nclass TestType {\n constructor() {\n this.testString = 'this-is-a-test';\n }\n methodOne() {\n console.log(this.testString);\n }\n methodTwo() {\n console.log(this.testString);\n }\n methodThree() {\n console.log(this.testString);\n }\n}\n\ncontainer.register('TestType', TestType)\n .bindFunctions('methodOne', 'methodThree');\n\nconst testType = container.resolve('TestType');\n\nconst testFunction = (handlerFunction) => {\n return handlerFunction();\n};\n\ntestFunction(testType.methodOne);\n// 'this-is-a-test'\ntestFunction(testType.methodThree);\n// 'this-is-a-test'\ntestFunction(testType.methodTwo);\n// TypeError: Cannot read property 'testString' of undefined\n```\n\n## Targeted Injection\n\nThe `injectInto` declaration allows you to determine where a registrations'\ndependencies will be injected into.\nUse this, if you wish dependencies to be injected into a function or a property,\ninstead of the classes constructor.\n\nThis feature allows you to use a constructor for other purposes than\nreceiving dependencies (which can be especially useful when used in conjunction\nwith lazy injections).\n\n**Note**: The `injectInto` declaration expects a `string`, containing the *name*\nof the property or function into which you wish to inject the dependencies.\n\nAlso note that this is the only way to supply dependencies to an object-registration.\n\n### Inject into property\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n set anyProperty(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyProperty');\n```\n\n### Inject into function\n\n```js\nclass SomeClass {}\n\ncontainer.register('SomeClassKey', SomeClass);\n\nclass SomeOtherClass {\n\n constructor(someCustomizedParameter) {\n this._somethingRegular = someCustomizedParameter;\n }\n\n anyFunction(value) {\n this._someClass = value;\n }\n}\n\ncontainer\n .register('SomeOtherClassKey', SomeOtherClass)\n .dependencies('SomeClassKey')\n .injectInto('anyFunction');\n```\n\n# Supported by\n\n![logo huf](./images/logo_huf.png)\n","readmeFilename":"README.md"}