You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When instantiating services, the last parameter passed to the constructor is the container instance itself, allowing usage like this (copied from the TypeDI documentation):
Sometimes it is convenient to pass the container instance through various function calls instead of specific services individually, so the above pattern is helpful. But upgrading from [email protected] introduces the following TypeScript build break:
Service with "MaybeConstructable<ContainerInstance>" identifier was not found in the container.
Register it before usage via explicitly calling the "Container.set"functionor using the
"@Service()" decorator.
The cause is that, when initializing the parameter types, typedi does not account for ContainerInstance being one of the possible types, and so the injection fails.
Here is the diff that solved my problem:
diff --git a/node_modules/typedi/cjs/container-instance.class.js b/node_modules/typedi/cjs/container-instance.class.js
index e473b1e..c0e4ce6 100644
--- a/node_modules/typedi/cjs/container-instance.class.js+++ b/node_modules/typedi/cjs/container-instance.class.js@@ -250,6 +250,8 @@ class ContainerInstance {
});
if (paramHandler)
return paramHandler.value(this);
+ if (paramType && paramType.name === ContainerInstance.name)+ return this;
if (paramType && paramType.name && !this.isPrimitiveParamType(paramType.name)) {
return this.get(paramType);
}
diff --git a/node_modules/typedi/esm2015/container-instance.class.js b/node_modules/typedi/esm2015/container-instance.class.js
index 4b75cb4..891e094 100644
--- a/node_modules/typedi/esm2015/container-instance.class.js+++ b/node_modules/typedi/esm2015/container-instance.class.js@@ -247,6 +247,8 @@ export class ContainerInstance {
});
if (paramHandler)
return paramHandler.value(this);
+ if (paramType && paramType.name === ContainerInstance.name)+ return this;
if (paramType && paramType.name && !this.isPrimitiveParamType(paramType.name)) {
return this.get(paramType);
}
diff --git a/node_modules/typedi/esm5/container-instance.class.js b/node_modules/typedi/esm5/container-instance.class.js
index 56df7eb..0c9e9fc 100644
--- a/node_modules/typedi/esm5/container-instance.class.js+++ b/node_modules/typedi/esm5/container-instance.class.js@@ -261,6 +261,8 @@ var ContainerInstance = /** @class */ (function () {
});
if (paramHandler)
return paramHandler.value(_this);
+ if (paramType && paramType.name === ContainerInstance.name)+ return _this;
if (paramType && paramType.name && !_this.isPrimitiveParamType(paramType.name)) {
return _this.get(paramType);
}
A more robust implementation would be to check paramType === ContainerInstance -- yes, this is definitely something which should be included by default! It's in my fork as HostContainer -- bear in mind that what you're doing here is the service locator pattern, which is generally discouraged in DI.
Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch
[email protected]
for the project I'm working on.When instantiating services, the last parameter passed to the constructor is the container instance itself, allowing usage like this (copied from the TypeDI documentation):
Sometimes it is convenient to pass the container instance through various function calls instead of specific services individually, so the above pattern is helpful. But upgrading from
[email protected]
introduces the following TypeScript build break:The cause is that, when initializing the parameter types,
typedi
does not account forContainerInstance
being one of the possible types, and so the injection fails.Here is the diff that solved my problem:
This issue body was partially generated by patch-package.
The text was updated successfully, but these errors were encountered: