search

emberjs / ember-cli-babel

Ember CLI plugin for Babel
MIT License
153 stars 119 forks source link

"loose" warning for @babel/plugin-proposal-private-property-in-object #415

Open bendemboski opened 2 years ago

bendemboski commented 2 years ago

Running an app or addon with what is currently the latest ember-cli-babel and @babel/preset-env (ember-cli-babel@7.26.6 and @babel/preset-env@7.15.6) results in this warning:

Though the "loose" option was set to "false" in your @babel/preset-env config, it will not be used for @babel/plugin-proposal-private-property-in-object since the "loose" mode option was set to "true" for @babel/plugin-proposal-class-properties.
The "loose" option must be the same for @babel/plugin-proposal-class-properties, @babel/plugin-proposal-private-methods and @babel/plugin-proposal-private-property-in-object (when they are enabled): you can silence this warning by explicitly adding
    ["@babel/plugin-proposal-private-property-in-object", { "loose": true }]
to the "plugins" section of your Babel config.

Should we be adding that option to the config anytime this block runs?

SergeAstapov commented 2 years ago

Seem like #428 (landed in v7.26.10) was sort of related (although didn't fix presence of this warning)

rwjblue commented 2 years ago

Hmmm, why didn't #428 fix the warning?

chriskrycho commented 2 years ago

428 fixed a related-but-not-identical issue: the set of class properties plugins themselves must match, and that's a hard error if they don't. Here, it's just warning that we're forcibly setting it when we configure the plugins, separately from whatever is set in preset-env. Similar-enough that it's easy to assume they're the same (I did, and was confused!). I suspect this is just an ordering issue? We get options from preset-env last in getBabelOptions:

https://github.com/babel/ember-cli-babel/blob/e1f0758e0ea4892d69885f0c07561a5de091daf2/lib/get-babel-options.js#L17-L66

rwjblue commented 2 years ago

Ya, makes sense @chriskrycho. I think based on your summary, that we could fix this warning too (without a massive refactoring in logic)?

chriskrycho commented 2 years ago

I think so? My first-pass though when looking at the code was that we just need to get the preset env config earlier up and pass any relevant options from it—mostly just "loose", I think?—down into the various _add*Plugin(s) calls.