A suggestion concerning a reflect-metadata package #7570
Replies: 1 comment 11 replies
-
|
Interesting. What |
Beta Was this translation helpful? Give feedback.
-
|
I've dug a bit more into the repo, one concern is with the copyright; Since the project is based from https://github.com/rbuckton/reflect-metadata, we may need to retain the original Apache 2.0 license along with Other than that, I agree with all your points above. |
Beta Was this translation helpful? Give feedback.
-
|
There is an another way: implement missing 3 functions of that yet another implementation (it is mentioned in my README). I may implement them and cross fingers nothing else breaks. And I expect you to thoroughly inspect possible differences in behavior. If it's ok, I will fill the gap and we will have MIT licensed code after that. |
Beta Was this translation helpful? Give feedback.
-
https://github.com/thephoenixofthevoid/reflect-metadata-ng/blob/main/TESTRUN_MIT.md self-explanatory |
Beta Was this translation helpful? Give feedback.
-
|
And finally thephoenixofthevoid/reflect-metadata-ng@1bd0f34 |
Beta Was this translation helpful? Give feedback.
-
|
It looks like I know cases where two packages differ: when annotation value is Falsy. But tests seem to not care about testing this edge case. |
Beta Was this translation helpful? Give feedback.
-
Since the code runs only in the modern environment (node 10 recently gets deprecated), all kinds of shims for standard ES6 classes packed deep inside of "reflect-metadata" make no sense.
Recently I remastered this package and come up with a very clear solution that has exactly the same behavior as the original one.
I would like to share it with a community: https://github.com/thephoenixofthevoid/reflect-metadata-ng
If you have any questions about it, ask here or create an issue in the above repo.
Beta Was this translation helpful? Give feedback.
All reactions