Idk how much detail you want in this issue, but when I heard of the babel transform changes in the 2.3.2 version, I was expecting to have to modify my babel config. I later found that this happens automatically for me in the index.js -- which can certainly be a nice ability for people don't want to think about babel.
But anywho -- a goal I have for ember + babel is to be able to pick and choose babel plugins for optimal output -- right now there is a bug in @babel/plugin-proposal-decorators that requires the class-properties plugin, and I'd like to omit class-properties plugins from all my apps (because browsers natively support them) -- and providing a way for consumers of ember-concurrency to opt in/out of the babel plugin would be a good step in that direction as well. :D
machty
commented
5 months ago
Idk how much detail you want in this issue, but when I heard of the babel transform changes in the 2.3.2 version, I was expecting to have to modify my babel config. I later found that this happens automatically for me in the index.js -- which can certainly be a nice ability for people don't want to think about babel.
For some background, here is the process:
Here are some example "mega" PRs were v2 conversions happened (these all also switch to pnpm, so that's why the diff is massive):
https://github.com/NullVoxPopuli/ember-popperjs/pull/142
But anywho -- a goal I have for ember + babel is to be able to pick and choose babel plugins for optimal output -- right now there is a bug in
@babel/plugin-proposal-decoratorsthat requires the class-properties plugin, and I'd like to omit class-properties plugins from all my apps (because browsers natively support them) -- and providing a way for consumers of ember-concurrency to opt in/out of the babel plugin would be a good step in that direction as well. :D