Build Optimizer does not support es2015 code
Closed this issue · 40 comments
From @filipesilva on April 30, 2018 17:28
Build Optimizer does not currently support es2015 modules code, but we should support it.
Related to angular/devkit#237
Copied from original issue: angular/devkit#816
From @robwormald on May 4, 2018 18:43
Should also support ES2015 code (really, it should support esnext)
From @hansl on May 5, 2018 19:5
I was under the impression UglifyES (or whatever NG version of uglify) was doing a proper job at DCE on ES2015 code and that we wouldn't need build optimizer for those.
From @cyrilletuzi on May 8, 2018 9:43
Note: now we have Angular Elements, support for ES2015 becomes more important, because transpiling custom elements to ES5 is not supported by the standard and produces an error.
From @rafaelfgx on May 10, 2018 23:59
With all the respect, this is a very basic bug and one that should be avoided.
You create an Angular 6 application, without changing anything, with all the default settings, build it for production, and it does not work.
It is very serious that something so trivial as publishing in production is not working in the final version.
More testing is needed, especially for the most important and essential tasks.
From @robwormald on May 11, 2018 0:34
@rafaelfgx - nobody should be using es2015 modules in production, Webpack doesn’t export them, and they’re not turned on by default.
From @msklvsk on May 11, 2018 9:22
While buildOptimizer is turned on by default, es6 is not, including the docs:
From @devoto13 on May 14, 2018 12:24
@hansl It does not seem to be the case.
Here is ES2015 with build optimizer on (fails with #10658):
Here is ES2015 with build optimizer off:
As you can see it is ~200k less with build optimizer enabled. Not sure if it is real gain or a side effect of build optimizer removing not dead code, but this looks like a lot of gain. Most of it comes from Angular packages (~180k).
From @catull on May 16, 2018 12:43
Hmm, I see a build optimiser bug for production builds with ES5.
See #7799 (comment).
That issue is closed, stating that the bug is tracked here.
As a work-around, I switched off build-optimiser and the app is working.
With build-optimiser ON, the error is as documented in the "issue comment" at the top of this comment.
From @byrondover on May 27, 2018 20:27
robwormald commented 10 days ago
@rafaelfgx - nobody should be using es2015 modules in production, Webpack doesn’t export them, and they’re not turned on by default.
@robwormald You may want to align with @StephenFluin on your community messaging around enabling ES2015. 😅
https://twitter.com/stephenfluin/status/997224523610116096
P.S. Big fans of all the work you do and are doing! 🤞for production ES2015 support by 2020. 
From @robwormald on May 27, 2018 20:51
@byrondover ES2015 syntax (classes, const,let,etc) is fine (assuming your browser target supports it) - lots of good wins to be had there.
ES2015 modules, not so much (though if you a very adventurous, no harm trying)
From @StephenFluin on May 27, 2018 21:25
My talk was about how Angular is working to push the limits of the web, and that if/when it made sense to ship all apps as ES2015 we could do that for you and save a bunch of bundle size and increase perf. Hello World worked for me but in general shipping ES2015 actually can hurt your machine readability as things like the Google crawler don't support ES2015
From @byrondover on May 27, 2018 21:59
Wow, didn't expect a response, let alone over Memorial Day weekend. 🇺🇸
Thanks for the clarification, gents! 🙇
From @zijianhuang on May 28, 2018 5:29
Having this problem since NG 6.0. Still a problem in 6.0.3 along with the latest CLI. As said by this others, setting "buildOptimizer":false will make things in production work again, however, the bundle is apparently too big. Let's see if 6.0.4 will has this fixed?
From @TomDemulierChevret on May 28, 2018 7:32
@StephenFluin Having our webapp crawlable is not mandatory for many of us. In my company 90% of Angular apps we develop are not publicly available.
@robwormald Is it possible to build with only ES2015 syntax ?
From @filipesilva on May 29, 2018 13:8
angular/devkit#981 has some fixes for ES2015 code support.
Thinking more about it, I don't think we do anything in regards to ES2015 modules in Build Optimizer, so that is probably enough.
From @filipesilva on May 30, 2018 9:47
Building upon #981, we should also wrap static initializers on ES2015 classes.
This is similar to https://github.com/angular/devkit/blob/master/packages/angular_devkit/build_optimizer/README.md#wrap-enums.
The following TS class:
class MyClass {
static field = console.log('hello');
}
transpiled to es2015 is:
"use strict";
class MyClass {
}
MyClass.field = console.log('hello');
//# sourceMappingURL=static.js.map
and ran through build optimizer yields:
"use strict";
class MyClass {
}
MyClass.field = /*@__PURE__*/ console.log('hello');
MyClass can never be dropped because of the property access. If we wrap it it should be ok though:
var MyClass = (function () {
class MyClass {
}
MyClass.field = console.log('hello');
return MyClass;
})();
From @clydin on May 30, 2018 14:6
Two potential downsides to this approach would be increased code size and a potential decrease in runtime performance. Both of these should be analyzed to ensure the additional behavior is a net positive.
From @zijianhuang on May 31, 2018 3:55
As of Angular CLI 6.0.7, the problem is still there.
From @filipesilva on May 31, 2018 7:39
@zijianhuang the changes are not in 6.0.7. I think you can test these changes by installing @angular-devkit/build-angular@0.7.0-beta.1.
From @Maximaximum on May 31, 2018 7:45
I updated @angular-devkit to 0.6.7 and the issue seems to be gone.
From @cedvdb on June 5, 2018 10:12
issue still here with 0.7.0 and target es6.
What would be really nice is an error at compilation time as to maybe find a temporary fix for the part of the code that's problematic.
From @filipesilva on June 5, 2018 12:58
@cedvdb can you put up a repro I can look at please?
From @cedvdb on June 6, 2018 12:46
The problem seems to be resolved. I didn't manage to reproduce it yet. If you need so I could dig deeper this evening, right now I gotta work.
From @filipesilva on June 6, 2018 12:51
As long as it's working, I think there's no need to look further. If I had to bet it wasn't working because at some point you were in an old version.
This fix is only on @angular-devkit/build-optimizer@0.7.0-beta.1 that comes with @angular-devkit/build-angular@0.7.0-beta.1.
You can check what version you have with npm list @angular-devkit/build-optimizer.
From @shahafal on June 6, 2018 13:40
@StephenFluin ... things like the Google crawler don't support ES2015
thank you for this, it's the first time i'm hearing of it. unfortunately except for discussions about this being an issue i can't find anywhere a discussion about the status to fix this.
do you know if there is an open thread in github (or someplace else) discussing the fix? i would like to follow it
@filipesilva Greetings! Does "now" mean angular-cli 8+?
@VVKot it should be in 7.3 too, the latest fixes we had were released in https://github.com/angular/angular-cli/releases/tag/v7.3.0-rc.0.
The issue is still present for me on version 7.3.7
@ryshep111 can you open a new issue including a reproduction? I'm don't really know what you're seeing or how to investigate it.
@ryshep111, the issue was fixed somewhere after v6.0.3, at the moment I am using v7.2.12.
my tsconfig.json:
{
"compileOnSave": false,
"compilerOptions": {
"baseUrl": "./",
"outDir": "./dist/out-tsc",
"sourceMap": true,
"declaration": false,
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"target": "es2015",
"typeRoots": [
"node_modules/@types"
],
"lib": [
"es2017",
"dom"
],
"skipLibCheck": true
}
}My angular.json
...
"configurations": {
"production": {
"optimization": true,
"outputHashing": "all",
"sourceMap": false,
"extractCss": true,
"namedChunks": false,
"aot": true,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true,
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.prod.ts"
}
],
"serviceWorker": true
}
}
...Hope this gives you some hint.
OK, it took me 4 hours but I think I found the root cause, or at least the way to reproduce exactly.
I've created a repository to reproduce it, all explanations are in the readme file there.
https://github.com/shlomiassaf/angular-cli-build-optimizer-es2015-issue
Ohh boy, this one was tricky.
TLDR: It will only happen if the class is built in FESM2015 module AND it has a NON-ANGULAR decorator applied on it.
I.E: Angular packages built with ng-packger.
@shlomiassaf it reproduces for me too. In our library we have our own decorators so it's probably the same root cause — all our super calls are dropped with build optimizer and es2015 target. Works fine in Angular 8 though. @filipesilva any chance this could be fixed in Angular 7 by investigating the above reproduction repo? Could we at least somehow mark super calls so compiler does not cut them out? This looks like the only problem we are having.
@waterplea I think it got fixed in #14263. In general we don't do releases of n-1 versions unless it's a security concern though. Is there something stopping you for updating to version 8?
@filipesilva I'm developing a library which theoretically works in Angular 6+, it's just unfortunate that if users would want to run my library in es2015 they are forced to update. So yeah, I understand you not touching older versions, I was maybe hoping for some ninja tactics like // @dynamic or whatever :)
@VVKot it should be in 7.3 too, the latest fixes we had were released in https://github.com/angular/angular-cli/releases/tag/v7.3.0-rc.0.
No it is not working in 7.3
Hello
Why this issue is closed?
In any v7 version, with ng library, you can reproduce this issue.
In my company we cant update to v8 instantly.
Well, is there something I can do to solve this on v6.2.9? We can't update (trying) to v8 like upstairs.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.