kategengler
commented
2 years ago I was able to reproduce the ember output in babel-transpilation-tests by passing modules: false to preset-env (as ember-cli-babel does).
Open NullVoxPopuli opened 2 years ago
kategengler
commented
2 years ago I was able to reproduce the ember output in babel-transpilation-tests by passing modules: false to preset-env (as ember-cli-babel does).
NullVoxPopuli
commented
2 years ago can we omit modules: false when building ember?
NullVoxPopuli
commented
2 years ago but also, what do modules have to do with class property transpilation? :thinking: maybe that's the babel bug?
kategengler
commented
2 years ago 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.
NullVoxPopuli
commented
2 years ago 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 babel.config.js
'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
oliverlj
commented
2 years ago Moving targets from const browsers = ['last 1 Chrome versions', 'last 1 Firefox versions', 'last 1 Safari versions']; to const browsers = ['> 0.6%', 'not IE 11', 'not op_mini all', 'not dead'];
let me add private methods in classes.
NullVoxPopuli
commented
2 years ago Unfortunately, this doesn't solve my root issue:
class properties should not be transpiled away, babel is doing too much work
NullVoxPopuli
commented
2 years ago When debugging this locally, I discovered the following allows native class transpilation:
(a change to ember-cli-babel)
and in my linked ember-cli-babel, updating browserlist
❯ npx browserslist --update-db
Latest version: 1.0.30001278
Installed versions: 1.0.30001066, 1.0.30001196it was a bit behind:
Target browser changes:
- and_chr 94
+ and_chr 95
- android 94
+ android 95
- chrome 91
- edge 93
- edge 92
- firefox 91
+ firefox 94
- opera 78
+ opera 81This results in my output js having proper fields:
and a file reduction of: standard new app, no actual code in it:
NullVoxPopuli
commented
2 years ago More importantly, on a slightly bigger app (still smol): https://github.com/NullVoxPopuli/limber
ember build --environment=production
I don't notice any size differences. :thinking:
kategengler
commented
2 years ago There are some very small changes, easier to see when sorted:
NullVoxPopuli
commented
2 years ago It seems there is different behavior in production builds :thinking: I've yet to figure out how to retain class property assignment in production builds.
For example, this same app, but in a development build. (now with sorted sizes, thanks!!!!)
ember build --environment="development"These 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
babel: {
loose: true
}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
NullVoxPopuli
commented
2 years ago ok, so I decided to go with https://github.com/emberobserver/client
one file (the app's js file) has ~ 2.7% smaller. (development)
NullVoxPopuli
commented
2 years ago so... I guess... do we ever not want loose mode? Is something deeper wrong here? in my babel-only repro loose mode was not needed :thinking: (nor was even specifying the class fields plugin) :shrug:
rwjblue
commented
2 years ago Presumably this is the same as https://github.com/babel/ember-cli-babel/issues/419#issuecomment-971787156
Originally reported here: https://github.com/emberjs/ember.js/issues/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 productionin the my-app.js, I expect all occurrences of
rootURLto 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.