"dependencies": {
"@angular/animations": "^6.0.0",
"@angular/cdk": "^6.2.1",
"@angular/common": "^6.0.0",
"@angular/compiler": "^6.0.0",
"@angular/core": "^6.0.0",
"@angular/forms": "^6.0.0",
"@angular/http": "^6.0.0",
"@angular/material": "^6.2.1",
"@angular/platform-browser": "^6.0.0",
"@angular/platform-browser-dynamic": "^6.0.0",
"@angular/router": "^6.0.0",
"@fnando/sparkline": "^0.3.7",
"@types/socket.io": "^1.4.34",
"core-js": "^2.5.4",
"countup.js-angular2": "^6.0.0",
"d3": "^5.3.0",
"d3-cloud": "^1.2.5",
"hammerjs": "^2.0.8",
"isobject": "^3.0.1",
"js-base64": "^2.4.3",
"leaflet": "^1.3.1",
"leaflet.markercluster": "^1.3.0",
"progressbar.js": "^1.0.1",
"rxjs": "^6.0.0",
"scrollmonitor": "^1.2.4",
"simplebar": "^2.6.1",
"socket.io": "^2.1.1",
"zone.js": "^0.8.26"
},
"devDependencies": {
"@angular-devkit/build-angular": "^0.6.7",
"@angular/cli": "^6.0.7",
"@angular/compiler-cli": "^6.0.3",
"@angular/language-service": "^6.0.3",
"@types/jasmine": "^2.8.8",
"@types/jasminewd2": "~2.0.3",
"@types/node": "~8.9.4",
"codelyzer": "~4.2.1",
"jasmine-core": "~2.99.1",
"jasmine-spec-reporter": "~4.2.1",
"karma": "~1.7.1",
"karma-chrome-launcher": "~2.2.0",
"karma-coverage-istanbul-reporter": "^1.4.3",
"karma-jasmine": "~1.1.1",
"karma-jasmine-html-reporter": "^0.2.2",
"protractor": "^5.3.2",
"ts-node": "~5.0.1",
"tslint": "~5.9.1",
"typescript": "~2.7.2"
}
ng build - Everything works fine
ng build --prod (with or without --aot) - Running fails with the following error:
runtime.a66f828dca56eeb90e02.js:1 Uncaught TypeError: Cannot read property 'call' of undefined
at p (code snippet: return r[e].call(n.exports,n,n.exports,p),n.l=!0, ... [following])
Working with cli 6.0.7. Same error with cli 6.0.0.
After lots of trials and errors and lots of googling I think I solved my problem but the potential solution goes well beyond my understanding and knowledge of angular ...
Couldn't understand why for a clean project "ng build --prod" works fine while for my project not but it looks like generating the build with:
"ng build --prod --source-map"
does the trick.
Can't really figure out how --source-map affects the building process for one or more of the packages that generated the error in runtime.js but it seems to work.
Just going to investigate a bit more about that (in order to understand if that is really THE solution) before closing the issue.
@marcotoldo Hi, did you find the cause? I am experiencing currently the same problem.
Hi @Ludevik
unfortunately couldn't find the exact cause and gave it up (... already feeling lucky enough to have been able to generate a running production build using the "--source-map" trick)
I'm sure that it has something to do with one or more third-party packages that are installed in the app so I think the best way to isolate the problem would be to create a new empty application and to monitor the generated prod bundle while progressively adding all the third-party packages related to your specific app one at a time.
Anyhow even if I found it I already know I couldn't understand why it breaks the build (as far as I know runtime.js should be independent from your own code) since my code worked without any problem with angular 5 (... some days ago I had the pretty bad idea of upgrading to version 6 because I needed the latest Angular Material version).
I'm reopening the issue in case anyone else is experiencing the same problem or can make any contribution to solve it.
I've had the same issue but for me adding --source-map doesn't help...
Same for me, --source-map doesn't help, but at least i see the culprit, it is one of my exported enums from my library.
I've bisected the issue in my project and it started happening for me since I updated it to use the RxJS 6 import syntax instead of the old v5 one. This was mostly stuff like:
-import { merge } from 'rxjs/observable/merge';
+import { merge } from 'rxjs';
and:
-import { pairwise } from 'rxjs/operators/pairwise';
-import { filter } from 'rxjs/operators/filter';
-import { take } from 'rxjs/operators/take';
+import { pairwise, filter, take } from 'rxjs/operators';
I've also discovered that calling:
ng build --prod --optimization=false
works as well. May it be an UglifyJS issue?
that's really bad ... that means the build could fail again anytime even in my case ...
@mgol thanks for pointing out the rxjs issue.
Until now I thought it was something related to one of the packages I've added for my app but In my case too I had to replace all the import stuff from rxjs with the new syntax when upgrading.
Given that I haven't tried yet generating an empty app (for which --prod works) but with some rxjs stuff that could be the problem.
Maybe it's worth trying ... I'll give it a try and report about it in a while.
ng build --prod --optimization=false
nice ... never tried it before but I agree with @mgol, it may have something to do with the uglifier
Just tested out rxjs (cli 6.0.7):
Result: --prod working as expected
At least for me rxjs is not the problem but (given that ng build works) I'm convinced that uglifyjs (or the minifier as well) could be the problem as pointed out by @mgol
I checked all the options of the ng build but as far as I can see there's no way to enable/disable the uglifier alone, it seems to be "glued" to the optimizer as a whole ...
I've tried --optimization=false again on a different commit (with & without --source-map) and it didn't help there. :/ This seems to be pretty random...
EDIT: Sorry, my bad, I was invoking a wrong command. --optimization=false still helps.
@mgol :-(
@Ludevik in your case if you remove the enums you found the production bundle works? Just trying to figure out all the possible scenarios for which it fails ...
@marcotoldo Could you try to add --optimization=false to your app in a version that has this issue and see if it helps?
@mgol thanks, just gave it a try.
Yes, --optimization=false generates a working app but unfortunately I don't see any difference with ng build (without any option): output files have a similar (big) size probably due to the optimization process not invoked (but that wouldn't be a big problem after all) and the app is relatively slow when running (I suspect that with --optimization=false angular still performs all double checkings while running as if it was running during development).
So far in my case the best I can get is with --prod --source-map which generates a bundle even smaller than with --prod alone (roughly 10% smaller) and fast enough when running to be regarded as a production build, but I can't really figure out why it works (and unfortunately why it doesn't work for you ...)
Here is another trial (suggested here and there for problems related to uglifyjs): change "target" key of your "compilerOptions" of tsconfig.js from "es5" to "es2015".
In my case (with ng build --prod)it solved the problem of runtime.js but gave me other problems in main.js related to the need for calling super() here and there ...
sorry ... according to cli official doc:
Be aware that JIT does not support ES2015 and so you should build/serve your app with --aot
so target "es2015" cannot be used with --prod
I pinpointed it to the Webpack 4's "sideEffects": false flag used by RxJS; see the issue https://github.com/webpack/webpack/issues/7499, in particular my comment at https://github.com/webpack/webpack/issues/7499#issuecomment-396528532.
BTW, in my case changing:
import { pairwise, filter, take } from 'rxjs/operators';
import { merge } from 'rxjs';
in app.component.ts to the following:
import { filter, take } from 'rxjs/operators';
import { pairwise } from 'rxjs/operators/pairwise';
import { merge } from 'rxjs';
made the app work again. I suspect this may be pretty random...
@mgol following your hint I tried removing all rxjs operators from my code (actually was using just 'retry') but no luck ... same "'call' of undefined" error ;-(
I'm using some third-party angular modules but as far as I can see none of them uses rxjs.
Given my "lucky" use of --source-map and your "lucky" re-writing of the rxjs imports it really looks like the error appears in a non-deterministic way.
I'll keep trying to find a solution but given that the problem is related to the optimization stage I really hope a new release of the cli will fix it asap
ng serve --prod now works for me. I have changed all angular dependencies to 6.0.4 and all dev dependencies to their latest versions:
"@angular-devkit/build-angular": "0.6.8",
"@angular-devkit/build-ng-packagr": "0.6.8",
"@angular/cli": "6.0.8",
"@angular/compiler-cli": "6.0.4",
"@angular/language-service": "6.0.4",
i have also updated all our code to rxjs 6 version and then added rxjs-compat back because of one dependency, but i don't think it has impact.
As soon as i upgrade
"@angular-devkit/build-angular": "0.7.0-beta.2",
"@angular-devkit/build-ng-packagr": "0.7.0-beta.2",
to their @next versions i get the same error as before.
As soon as i upgrade
"@angular-devkit/build-angular": "0.7.0-beta.2", "@angular-devkit/build-ng-packagr": "0.7.0-beta.2",to their @next versions i get the same error as before.
That's because it's a regression introduced in Webpack 4.10.0. @angular-devkit/build-angular at 0.7.0-beta.2 depends on Webpack ~4.10.2 and the previous version of @angular-devkit/build-angular, 0.6.8 depends on Webpack ~4.8.1.
seems solved since ts-node 7.0.0
I have the same error using ng serve --aot --proxy-config proxy.conf.json but
at __webpack_require__ (bootstrap:81).
And I don't know how to solve it...
I got the same error but I just killed my ng serve and started serving again. it worked!
I know it's not the solution but my prod ng build --prod build's too successful.
Fixed via https://github.com/angular/angular-cli/pull/11488, we shouldn't have a dependency on 4.10.2 in our latest versions anymore.
Try for this..
ng build --prod --optimization=false
edit3: Updating to Angular 7 RC fixed it. See my other comment below.
I have this issue even with the latest dependencies. Turning off optimization fixes it. This started happening when I moved a large (non-angular) library outside of my project, bundled it with webpack, and added it as dependency to my application.
edit1: I have a suspicion it has something to do with reflect-metadata that my bundled library depends on due to class-transformer
edit2: I'm not so sure about that suspicion now because the angular compiler itself relies on reflect-metadata. The core-js polyfill provides it's own reflect metadata functionality so maybe there's a conflict but I doubt that's an issue for AOT because a comment in my pollyfill.ts says it can be removed for AOT. Removing it didn't solve the issue.
package.json:
"dependencies": {
"@angular/animations": "^6.1.9",
"@angular/common": "^6.1.9",
"@angular/compiler": "^6.1.9",
"@angular/core": "^6.1.9",
"@angular/forms": "^6.1.9",
"@angular/http": "^6.1.9",
"@angular/platform-browser": "^6.1.9",
"@angular/platform-browser-dynamic": "^6.1.9",
"@angular/router": "^6.1.9",
"rxjs": "^6.3.3",
"rxjs-compat": "^6.3.3",
...
},
"devDependencies": {
"@angular-devkit/build-angular": "^0.8.4",
"@angular-devkit/build-ng-packagr": "^0.8.4",
"@angular/cli": "^6.2.4",
"@angular/compiler-cli": "^6.1.9",
"@angular/language-service": "^6.1.9",
"@angularclass/hmr": "^2.1.3",
"lerna": "^3.4.0",
"ts-node": "~7.0.0",
"tslib": "^1.7.1",
"typescript": "~2.9.2",
...
},
"resolutions": {
"typescript": "~2.9.2",
"reflect-metadata": "0.1.12"
}
yarn.lock
[email protected], reflect-metadata@^0.1.10, reflect-metadata@^0.1.2:
version "0.1.12"
webpack@^4.15.1:
version "4.20.2"
Encouraging news. Updating to angular version 7.0.0-rc0 and corresponding versions for @angular-devkit and @angular/cli fixed it! :)
package.json
"dependencies": {
"@angular/animations": "^7.0.0-rc.0",
"@angular/common": "^7.0.0-rc.0",
"@angular/compiler": "^7.0.0-rc.0",
"@angular/core": "^7.0.0-rc.0",
"@angular/forms": "^7.0.0-rc.0",
"@angular/http": "^7.0.0-rc.0",
"@angular/platform-browser": "^7.0.0-rc.0",
"@angular/platform-browser-dynamic": "^7.0.0-rc.0",
"@angular/router": "^7.0.0-rc.0"
},
"devDependencies": {
"@angular-devkit/build-angular": "^0.9.0-rc.1",
"@angular-devkit/build-ng-packagr": "^0.9.0-rc.1",
"@angular/cli": "7.0.0-rc.1",
"@angular/compiler-cli": "^7.0.0-rc.0",
"@angular/language-service": "^7.0.0-rc.0",
}
I'm still experiencing this issue as of CLI 7.0.3.
I had similar event-related issues when hovering on plots using plot.ly: `ERROR TypeError: "o[a] is undefined".
As some of you noticed, the --optimization=false is still generating quite a big bundle. It turns out that --build-optimizer=false also solved the problem in my case. But it generates a way smaller bundle than with the full optimization removed so that's great! I haven't found a clear definition of what optimization does but as i understand it, it's super set of parameters including build-optimizer, which removes the dead code through Tree shaking if i understand it right.
Still these are workarounds and the problem has to be fixed to allow all flags to work as expected.
Thank you for the tip, @virgile-hogman, it sounded like a good idea. However, for our project it did not work. The only change that did help, was to remove all optimization, which resized our main bundle from 600 KB to 5 MB.
Angular version was updated today to 7.1.2.
Does anyone have any other ideas?
For info, the issue i had when hovering on plots in prod mode is now solved!
This problem appeared with a fully optimized bundle, consisting of two parameters: optimization (minimizer) + buildOptimizer (tree shaking), which are enabled by default in prod mode, at least with Angular 7.
As stated here a few months ago, I had to turn the buildOptimizer off to make the application work, but now i can also enable it again and i'm convinced the solution came with a fix on the build of angular-plotly.js. At least it's the most rational explanation, as a double minimization (of the underlying plotly.js library) created some strange issues already with the minimizer step alone.
Now i have a fully optimized bundle, so that's great! :)
In short, maybe the cause is different, but check if you don't have some double minimization going on through your third-party dependencies, that could explain some issues with the prod mode.
--build-optimizer=false work for me , --optimization=false didn't work
I had the same issue with the angular-plotly library. The point looked to be the fact that this library was already calling a minified library (plotly.js in that case) and the double minification was the origin of the problem. The new version (1.0) of angular-plotly solved perfectly the issue. I hope that might help somebody...
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._
Most helpful comment
I'm still experiencing this issue as of CLI 7.0.3.