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
I just resolved a very nasty bug I had in my app, which could have been prevented if inversify had a warning about this use case.
I basically had a service, registered as singleton, but it had, by mistake, dependencies that are scoped. By doing that, the dependencies are actually becoming singletons as they are only initialized when the singleton is instantiated, which could potentially cause major issues
Expected Behavior
Inversify should print a warning if scoped/transient dependency is used in a singleton
Current Behavior
Inversify lets you use the scoped service in a singleton, causing wrong instances.
Possible Solution
Coming from .NET in the past, with the built-in DI container, the framework would force that any dependencies are in scope order -> transient can depend on scoped (which is thread-local there) or singleton, scoped can depend on transient, but the opposite order is forbidden and it would throw an error when registered.
Your Environment
Version used: 6.0.1
Environment name and version (e.g. Chrome 39, node.js 5.4): Node 18.18.2
Operating System and version (desktop or mobile): macOS
The text was updated successfully, but these errors were encountered:
I just resolved a very nasty bug I had in my app, which could have been prevented if inversify had a warning about this use case.
I basically had a service, registered as singleton, but it had, by mistake, dependencies that are scoped. By doing that, the dependencies are actually becoming singletons as they are only initialized when the singleton is instantiated, which could potentially cause major issues
Expected Behavior
Inversify should print a warning if scoped/transient dependency is used in a singleton
Current Behavior
Inversify lets you use the scoped service in a singleton, causing wrong instances.
Possible Solution
Coming from .NET in the past, with the built-in DI container, the framework would force that any dependencies are in scope order -> transient can depend on scoped (which is thread-local there) or singleton, scoped can depend on transient, but the opposite order is forbidden and it would throw an error when registered.
Your Environment
The text was updated successfully, but these errors were encountered: