ember-cli-babel icon indicating copy to clipboard operation
ember-cli-babel copied to clipboard

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

Open bendemboski opened this issue 4 years ago • 5 comments
trafficstars

Running an app or addon with what is currently the latest ember-cli-babel and @babel/preset-env ([email protected] and @babel/[email protected]) 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?

bendemboski avatar Sep 21 '21 15:09 bendemboski

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

SergeAstapov avatar Dec 17 '21 02:12 SergeAstapov

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

rwjblue avatar Dec 17 '21 13:12 rwjblue

#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

chriskrycho avatar Dec 17 '21 14:12 chriskrycho

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

rwjblue avatar Dec 22 '21 13:12 rwjblue

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.

chriskrycho avatar Dec 22 '21 17:12 chriskrycho