-
-
Notifications
You must be signed in to change notification settings - Fork 283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@tsed/di overrides native metadata from 'reflect-metadata' #2399
Comments
🎉 This issue has been resolved in version 7.34.4 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
🎉 This issue has been resolved in version 7.35.0-beta.5 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
🎉 This issue has been resolved in version 7.35.0-rc.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
🎉 This issue has been resolved in version 7.36.0-rc.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
🎉 This issue has been resolved in version 7.36.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Description
I have been actively working on integrating the Automock library (https://github.com/automock/automock) with various DI frameworks, including Ts.ED 🎉 . During the exploration of
@tsed/di
metadata mechanism, I came across a potential limitation concerning the@Inject
decorator.Presently, when using the
@Inject
decorator, it overrides the native metadata key of the parameter see here. This behavior can have unintended consequences, particularly when integrating with external libraries like Automock, which heavily relies on accurate metadata to automatically mock class dependencies. See:tsed/packages/di/src/common/decorators/inject.ts
Line 47 in 83bc31d
To address this concern and ensure seamless integration with any library, I propose the addition of an extra metadata key, named
original:paramtypes
, in the@tsed/di
infrastructure. This new key will store the original parameter types before applying any decorator modifications. By preserving the original metadata, the@Inject
decorator can continue to function as intended, while also enabling 3rd party libraries to access the unaltered parameter types when needed.The text was updated successfully, but these errors were encountered: