[Bug] browserslist and targets have no effect on the output of the build (potential performance problems as well) #417
Comments
|
I was able to reproduce the ember output in |
|
can we omit |
|
but also, what do modules have to do with class property transpilation? 🤔 maybe that's the babel bug? |
|
I have pretty much zero subject-matter knowledge here. From reading preset-env docs and from some commit history, it seems like cli-babel does it's own module stuff. No idea what the interaction between the modules and other transpilation could be. |
|
as an experiment, I tried the following changes... to see if I can have any control over babel whatsoever... the answers appears to be no. diff --git a/ember-cli-build.js b/ember-cli-build.js
index 48e94e9..b11292d 100644
--- a/ember-cli-build.js
+++ b/ember-cli-build.js
@@ -4,6 +4,9 @@ const EmberApp = require('ember-cli/lib/broccoli/ember-app');
module.exports = function (defaults) {
let app = new EmberApp(defaults, {
+ 'ember-cli-babel': {
+ useBabelConfig: true,
+ },
// Add options here
});the 'use strict';
const { buildEmberPlugins } = require('ember-cli-babel');
module.exports = function (api) {
api.cache(true);
console.log('ugh'); // <-- I can see this in the terinal
return {}; // <-- I only added this because nothing I changed below seemed to affect the build output.
// ^ I would expect this to break the build... or at the very least babel should complain about running in to decorators
// and not having the decorator plugin loaded...
return {
presets: [
[
require.resolve('@babel/preset-env'),
{
// modules: 'auto',
// targets: {
// // esmodules: true,
// browsers: ['last 1 firefox versions'],
// },
},
],
],
plugins: [
[require.resolve('@babel/plugin-proposal-decorators'), { legacy: true }],
// ...buildEmberPlugins(__dirname)
],
};
}; |
|
I retract my comment about modules: false, since I cannot reproduce it's effect again. I'm puzzled but /shrug |
|
Moving targets let me add private methods in classes. |
|
Unfortunately, this doesn't solve my root issue:
|
|
When debugging this locally, I discovered the following allows native class transpilation: and in my linked ember-cli-babel, updating browserlist it was a bit behind: |
|
This results in my output js having proper fields: and a file reduction of:
beforeafter |
|
More importantly, on a slightly bigger app (still smol): https://github.com/NullVoxPopuli/limber
I don't notice any size differences. 🤔 beforehashes are all messed up cause I think my yarn linking changed something after |
|
There are some very small changes, easier to see when sorted: beforeafter |
|
It seems there is different behavior in production builds 🤔 For example, this same app, but in a development build. (now with sorted sizes, thanks!!!!) BeforeAfterThese sizes are more noticable anyway -- which is good, because anything I can do to help make development a bit faster, the better. Most meaningful changes in these diffs:
I looked aver the readme again and noticed that there is a option available, but it seems that's only used for addons, not apps. my diff here seems to be the only way to allow class properties to not be compiled. diff --git a/lib/babel-options-util.js b/lib/babel-options-util.js
index ff49d6e..c3469ea 100644
--- a/lib/babel-options-util.js
+++ b/lib/babel-options-util.js
@@ -346,7 +346,7 @@ function _addDecoratorPlugins(plugins, options, config, parent, project) {
plugins,
[
require.resolve("@babel/plugin-proposal-class-properties"),
- { loose: options.loose || false },
+ { loose: true || options.loose || false },
],
_buildClassFeaturePluginConstraints(
{gonna try a bigger app - maybe the ember-website |
|
ok, so I decided to go with https://github.com/emberobserver/client one file (the app's js file) has ~ 2.7% smaller. (development) |
|
so... I guess... do we ever not want loose mode? |
|
Presumably this is the same as #419 (comment) |
Originally reported here: emberjs/ember.js#19790
🐞 Describe the Bug
After some investigation here: https://stackoverflow.com/questions/69547969/with-babel-how-do-i-not-compile-away-class-properties-since-browsers-support
And a minimal babel repro here: https://github.com/NullVoxPopuli/babel-transpilation-tests
I expect that setting my targets to
last 1 firefox versionswould allow me to keep native class properties. and only transpile what is decororated.I believe fixing this could provide a bit of a boost to everyone's build times. Today all class properties are transpiled to a time when class properties were not implemented in the browser).
🔬 Minimal Reproduction
last 1 Chrome versionsandlast 1 firefox versionsyarn browserslist --update-dbember build -e productionrootURLto be involved in an assignment, rather than a function call.result: https://github.com/NullVoxPopuli/repro-for-emberjs-19790
😕 Actual Behavior
Living in the dark ages
🤔 Expected Behavior
Utilize support for native properties, private properties, methods, etc.
🌍 Environment
➕ Additional Context
See the comparison between these two files:
Input: https://github.com/NullVoxPopuli/babel-transpilation-tests/blob/main/input.js
Output: https://github.com/NullVoxPopuli/babel-transpilation-tests/blob/main/output.js
This is correct.
But when I add that input file to ember, I get this for the output:
which... I guess is unrelated, but should still be fixed. Now, If I change the private methods/getters to public:
I get this mess:
which is way wrong.
The text was updated successfully, but these errors were encountered: