x)
- [ ] new
- [x] build
- [x] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
This problem didn't happen with angular/cli 7.x
When I serve the app via ng serve --prod the app runs fine.
When I serve the files outputted by with a server (apache, nginx) ng build --prod the app fails to load with js error.
Here is a bear-bones repo that exposes the bug: https://github.com/hugodes/cli-2015
The problem here is that this errors appears with ng build --prod but not with ng serve --prod
main-es2015.4cf9183c1dd8f352bda7.js:1 Uncaught ReferenceError: process is not defined
at Object.md97 (main-es2015.4cf9183c1dd8f352bda7.js:1)
at f (runtime-es2015.858f8dd898b75fe86926.js:1)
at Object.Sp1i (main-es2015.4cf9183c1dd8f352bda7.js:1)
at f (runtime-es2015.858f8dd898b75fe86926.js:1)
at Module.zUnb (main-es2015.4cf9183c1dd8f352bda7.js:1)
at f (runtime-es2015.858f8dd898b75fe86926.js:1)
at Object.1 (main-es2015.4cf9183c1dd8f352bda7.js:1)
at f (runtime-es2015.858f8dd898b75fe86926.js:1)
at t (runtime-es2015.858f8dd898b75fe86926.js:1)
at Array.r [as push] (runtime-es2015.858f8dd898b75fe86926.js:1)
Angular CLI: 8.0.2
Node: 10.16.0
OS: darwin x64
Angular: 8.0.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Package Version
-----------------------------------------------------------
@angular-devkit/architect 0.800.2
@angular-devkit/build-angular 0.800.2
@angular-devkit/build-optimizer 0.800.2
@angular-devkit/build-webpack 0.800.2
@angular-devkit/core 8.0.2
@angular-devkit/schematics 8.0.2
@angular/cli 8.0.2
@ngtools/webpack 8.0.2
@schematics/angular 8.0.2
@schematics/update 0.800.2
rxjs 6.5.2
typescript 3.4.5
webpack 4.30.0
Anything else relevant?
The error comes from the fact that the aws-sdk is dependent on node specific variables that are not present in a browser context.
But the problem is that the error should both happen with ng serve and ng build.
Why ? Multiple reasons:
Hi, the problem here is that aws-sdk is not compatible with JS modules as is setting process as a global object.
See: https://github.com/aws/aws-sdk-js/blob/c175cb2b89576f01c08ebf39b232584e4fa2c0e0/lib/browser_loader.js#L36-L38
This works well when not using module type script tags however, it will always fail when using type=module since there is not a global scope. See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#Other_differences_between_modules_and_standard_scripts
I suggest you file an issue with AWS, that their SDK doesn't work with JS modules.
I am going to leave this open for the time being, to discuss this a bit further with the rest of team and see if we should always add type=module on serve when differential loading will be enabled during build.
@alan-agius4 thanks for your great insight, it's perfectly clear.
I would advocate for adding type=module on serve because for us we didn't see the problem until the code was merged on our live dev server.
I think devs would be better off knowing broken code is broken before deploying.
For readers who encounter this problem in Angular 8 with aws-sdk, a workaround for now it to add these two lines of code in you polyfills.ts file:
// Add global to window, assigning the value of window itself.
(window as any).global = window;
// Defining process shim
(window as any).process = undefined;
We discussed this and we decided that it's best that we add type=module on script tags in serve mode, if differential loading will be needed and the script target is es2015.
Thanks @alan-agius4 !!!
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
@alan-agius4 thanks for your great insight, it's perfectly clear.
I would advocate for adding type=module on serve because for us we didn't see the problem until the code was merged on our live dev server.
I think devs would be better off knowing broken code is broken before deploying.