-
-
Notifications
You must be signed in to change notification settings - Fork 119
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
[FEAT] Decorator and Class Field Support #274
[FEAT] Decorator and Class Field Support #274
Conversation
This PR adds the decorator and class field transforms directly to the stardard Ember build, so users can rely on `ember-cli-babel` to provide them and won't have to manage their own transforms package. It does _not_ add these transforms if it detects that the plugins have already been added by something else, and instead warns.
766f277
to
520190f
Compare
index.js
Outdated
) { | ||
this.project.ui.writeWarnLine(`${ | ||
this._parentName() | ||
} has added the decorators and/or class properties plugins to its build, but ember-cli-babel provides these by default now! You can remove the transforms, or the addon that provided them, such as @ember-decorators/babel-transforms. Ember supports the stage 1 decorator spec and transforms, so if you were using stage 2, you'll need to ensure that your decorators are compatible, or convert them to stage 1.`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am slightly worried by line-noise cause by this warning, i have some questions:
- how often does this fire for a large app (with many nested ember-cli-babel's)?
- can it be reduced further, and maybe more meaty details to a readme?
- it should likely surface what version of ember-cli-babel now provides this via
- where does a user remove the decorators from, their add-on or their app or...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are good points. Do you think we should only warn if it's a top level thing? So, apps will warn, and addons will only warn if they are being worked on/developed. I've found this a good way to move the ecosystem forward in the past when things aren't incredibly pressing, and I think this qualifies since the transforms do tend to be limited to a single package.
I left a note, re: warning. But otherwise 👍 . Question, for non-decorator users how much does this slow down the users babel? |
I haven't seen any noticeable changes in build-speed, but I also haven't used the decorator transforms in a large application. Is there a way we can benchmark to find out what the change would be? |
Super low tech, is something like: |
ec4a47f
to
80e42a4
Compare
I benchmarked and shared results with @stefanpenner offline, this does not appear to be a regression performance-wise. I've also updated the warning to only log in the root application/addon, so users won't get large amounts of noise from addons they don't control. I think this should be good to go! |
ember-cli-babel 7.7.0 published 🎉 |
Thanks for the extra diligence |
Ran into an issue when reinstalling dependencies within my project.
|
Hey @LordCHTsai, can you possibly provide a reproduction? It seems strange that the plugin would be included twice, definitely would like to get to the bottom of it. |
@pzuraq here's the reproduction
and here's the log
|
Update: At least it's narrowing down to |
Just ran into this as well. Created a new app with Ember CLI 3.7 and ran |
This PR adds the decorator and class field transforms directly to the
stardard Ember build, so users can rely on
ember-cli-babel
to providethem and won't have to manage their own transforms package. It does
not add these transforms if it detects that the plugins have already
been added by something else, and instead warns.