Replies: 3 comments 11 replies
-
|
What will be the win if we move them to a separate package actually ? If there is no such big win why to go through this now? |
Beta Was this translation helpful? Give feedback.
-
|
There are many BCs in the next release: while each of them they might not be an issue by itself the sheer amount of errors from all of them combined might scare people. Maybe a warning in v7 and the nuke option in v8? |
Beta Was this translation helpful? Give feedback.
-
|
I will move forward with #7011, but keep this poll open and pinned for a week or two. Adding the reexports should be trivial, it can happen later. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Should we move decorators to their own package? The dependency on
reflect-metadatawill be an optional peer, and the default metadata provider will change, but we could still keep the legacy decorators exported from the core, to ease adoption of v7. I fear the burden of changing imports in all entities could be too huge for bigger projects, and people might hesitate to upgrade.This is currently implemented in #7011, where I struggle with fixing all the affected tests 🙃
The PR also adds ES spec decorators, which could be exported from the core package on a different export path, since they share names with the legacy ones.
16 votes ·
Beta Was this translation helpful? Give feedback.
All reactions