Angular-cli: Error in ng build --prod that doesn't happen with ng serve --prod

Created on 12 Jun 2019  路  6Comments  路  Source: angular/angular-cli

馃悶 Bug report

Command (mark with an x)


- [ ] new
- [x] build
- [x] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Is this a regression?


This problem didn't happen with angular/cli 7.x

Description

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.

馃敩 Minimal Reproduction

Here is a bear-bones repo that exposes the bug: https://github.com/hugodes/cli-2015

馃敟 Exception or Error

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)

馃實 Your Environment




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:

  1. Developers use ng serve for development and they should be made aware errors that will end up on production.
  2. Also it will be easier for reporting the "process shim" bug to the aws team, if they just have to run ng serve instead of having to setup a third party web server.

devkibuild-angular low broken bufix

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.

All 6 comments

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._

Was this page helpful?
0 / 5 - 0 ratings