Properly handle class properties proposal#420
Conversation
|
Tested this, besides the unit tests, by doing a |
| "@babel/polyfill": "^7.11.5", | ||
| "@babel/preset-env": "^7.12.0", | ||
| "@babel/preset-env": "^7.16.4", | ||
| "@babel/runtime": "7.12.18", |
There was a problem hiding this comment.
Might be worth it to try and unpin @babel/runtime again after this PR too (Discussion in #384 )
|
I confirm that with this branch, things work as expected!
I expect some perf / build improvements from this! let's goooooo 🚢 nice work @chriskrycho <3 |
rwjblue
force-pushed
the
fix-babel-class-shenanigans
branch
from
e1c6b60 to
dddbada
Compare
|
Rebased / amended to kick off a CI run |
Historically, we only add the `@babel/plugin-proposal-class-properties`
so that we make sure the ordering is right with the decorators proposal
(otherwise, it can end up compiling in the wrong order). With a recent
version of `@babel/preset-env` and, transitively, `caniuse-lite`, this
resulted in cases where we added that plugin but *not* related plugins
for private class properties, which in turn triggered a Babel assertion
about not adding the properties together as appropriate when the caniuse
database (correctly) reported that .
The fix is:
1. Bump to a more recent version of `@babel/preset-env`, which comes
with a correspondingly bumped version of `caniuse-lite`, which in
turn correctly understands what the latest versions of targeted
browsers are.
2. Include in `ember-cli-babel` itself a check for whether we even
*need* to add the plugin, and only provide it when the provided
`targets` indicate that they require it.
Resolves emberjs#419
rwjblue
force-pushed
the
fix-babel-class-shenanigans
branch
from
dddbada to
0d47e8b
Compare
Totally a team effort with @rwjblue – we spent a half day pairing on it till we had a solution; I just did the "write some tests and open a PR" bit. ;) |
|
Thanks, @rwjblue !!!!! <3 I super excited to deploy these updates everywhere!!! |
4 participants
Historically, we only add the
@babel/plugin-proposal-class-propertiesso that we make sure the ordering is right with the decorators proposal (otherwise, it can end up compiling in the wrong order). With a recent version of@babel/preset-envand, transitively,caniuse-lite, this resulted in cases where we added that plugin but not related plugins for private class properties, which in turn triggered a Babel assertion about not adding the properties together as appropriate when the caniuse database (correctly) reported that .The fix is:
Bump to a more recent version of
@babel/preset-env, which comes with a correspondingly bumped version ofcaniuse-lite, which in turn correctly understands what the latest versions of targeted browsers are.Include in
ember-cli-babelitself a check for whether we even need to add the plugin, and only provide it when the providedtargetsindicate that they require it.Resolves #419