Different result when building with --prod=true

[fireflysemantics]

🐞 Bug report

Command (mark with an x)

• new
• [ x] build
• [ x] serve

Description

When building the App with the --prod=true flag it renders as a blank screen.

I discovered this after pushing the App to Github Pages and seeing nothing. This is an SO post I created while trying to diagnose this:

https://stackoverflow.com/questions/59596387/angular-app-deployed-to-github-pages-not-initializing

The error shown in the console is obscure for this. This is what it says:

main-es2015.5c2edd6f312ad6930668.js:1 Uncaught ReferenceError: process is not defined
    at Object.2U8Y (main-es2015.5c2edd6f312ad6930668.js:1)
    at l (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at Module.zUnb (main-es2015.5c2edd6f312ad6930668.js:1)
    at l (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at Object.0 (main-es2015.5c2edd6f312ad6930668.js:1)
    at l (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at t (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at Array.r [as push] (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at main-es2015.5c2edd6f312ad6930668.js:1

This is the deployed app that produces the error:

https://fsalpha-canary.fireflysemantics.com/

Just open up the console in chrome to see it.

I'll also include a screen shot of it.

A clear and concise description of the problem...

ng serve -o

Will work.

ng serfve -o --prod=true

Just renders an app that does not initialize and only provides an obscure error.

🔬 Minimal Reproduction

I'm going to have to start building the entire app piece by piece from scratch now to figure out what is causing the hangup.

Just wanted to report that this is the case .

🔥 Exception or Error

main-es2015.5c2edd6f312ad6930668.js:1 Uncaught ReferenceError: process is not defined
    at Object.2U8Y (main-es2015.5c2edd6f312ad6930668.js:1)
    at l (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at Module.zUnb (main-es2015.5c2edd6f312ad6930668.js:1)
    at l (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at Object.0 (main-es2015.5c2edd6f312ad6930668.js:1)
    at l (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at t (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at Array.r [as push] (runtime-es2015.e59a6cd8f1b6ab0c3f29.js:1)
    at main-es2015.5c2edd6f312ad6930668.js:1

🌍 Your Environment

ole@mkt:~$ ng version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 9.0.0-rc.3
Node: 12.6.0
OS: linux x64
Angular: 
... 

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.900.0-rc.3
@angular-devkit/core         9.0.0-rc.3
@angular-devkit/schematics   9.0.0-rc.3
@schematics/angular          9.0.0-rc.3
@schematics/update           0.900.0-rc.3
rxjs                         6.5.3

[clydin]

The application appears to be attempting to access the “process” global. This is a Node.js specific API and does not exist on a browser. You should be able to isolate the problem by tracking down the code that is attempting to use “process”.

[fireflysemantics]

I figured out what the issue is. Documented it here:
https://stackoverflow.com/questions/59604716/can-the-angular-production-build-not-shorten-class-names

It looks like it's due to Angular shortening the class names of the modeled entities, and this in turn is causing the duplicate keys for in the ValidationContext container that stores the decorator methods.

[fireflysemantics]

This is the error trace that I get from the production build locally:

main.2876a5e2eb85f08784d9.js:1 Uncaught Error: The ValidationContainer 
      already contains context with signature t_e_sku.
    at Function.t.addValidationContext 

The signature t_e_sku is ClassName_propertyName ... and since Angular has shortened the name to t_e it is for some reason conflicting with another t_e class ...

[fireflysemantics]

If I switch off the optimization the production build works:

ng serve --prod --optimization=false

[fireflysemantics]

Now that the optimization is turned off, I'm getting cleaner messages WRT the process errer:

main-es2015.05c167886ce4cb3c62f6.js:161223 Uncaught ReferenceError: process is not defined
    at Object../node_modules/path/path.js (main-es2015.05c167886ce4cb3c62f6.js:161223)
    at __webpack_require__ (runtime-es2015.d6c52737d4587c65265f.js:80)
    at Module../src/app/utilities.ts (main-es2015.05c167886ce4cb3c62f6.js:180158)
    at __webpack_require__ (runtime-es2015.d6c52737d4587c65265f.js:80)
    at Module../src/app/asset.service.ts (main-es2015.05c167886ce4cb3c62f6.js:178289)
    at __webpack_require__ (runtime-es2015.d6c52737d4587c65265f.js:80)
    at Module../src/app/app.component.ts (main-es2015.05c167886ce4cb3c62f6.js:178116)
    at __webpack_require__ (runtime-es2015.d6c52737d4587c65265f.js:80)
    at Module../src/app/app.module.ts (main-es2015.05c167886ce4cb3c62f6.js:178193)
    at __webpack_require__ (runtime-es2015.d6c52737d4587c65265f.js:80)

[clydin]

The issue does indeed appear to be the Node.js process global access. While Node.js and browsers both leverage JavaScript, they are distinct platforms with different APIs. Libraries targeting a browser should not assume the presence of Node.js's APIs (or vice versa). This is very similar to attempting to use Windows APIs in a Linux C program.

As to the class name issue mentioned above, that error could potentially happen even if the names were not modified. Class names are not required to be globally unique but rather only unique on a module level. The production build is just increasing the likelihood of such a failure condition.

As this doesn't appear to be an issue caused by a defect within the CLI, I'm going to close the issue. If this turns out to be an incorrect assessment, please re-open.

[fireflysemantics]

@clydin I think this should be reopened.

In this case I have a domain project that uses this library:

https://github.com/fireflysemantics/validator/#readme

Classes are decorated with validators like @IsNumber etc.

The Angular project depends on the domain project.

When the annotations run, they use the class names to create unique IDs for the context that the decorator applies to.

Not requiring class names to be globally unique therefore completely breaks this use case and I'm sure it will cause other issues when using decorators in general.

[fireflysemantics]

#12887

[fireflysemantics]

Also I'm the creator of the library:
https://github.com/fireflysemantics/validator/#readme

I coded the duplicate validation context check in to make sure that this never occurs.

It does not occur outside of the Angular optimization in my experience and I've tested it thoroughly.

This makes me wonder if perhaps Angular is "Over optimizing" when it comes to class names and whether this can cause other production issues.

I really think that to be on the safe side class names should be globally unique across the application.

[clydin]

Identifiers (class, function, property or otherwise) are by definition not globally unique. They are only required to be unique within their given scope. They can also be shadowed within nested scopes but this is generally considered a bad practice. It is definitely plausible for a larger JavaScript program to have multiple files within different functional areas of a program that contain classes with the same name. Classes or other elements with the same name can even be imported into a single module by aliasing the names (import { X as Y} from './a/b/c'; import { X as Z } from './d/e/f').
It is also possible to have two classes with the same name in the same file (contrived example):

const X = class A {
  randomProperty: number;
  getName() { // Returns 'A'
    return A.name;
  }
};

const Y = class A {
  randomProperty: string;
  anotherProperty: boolean;
  getName() { // Returns 'A'
    return A.name;
  }
};

new X();
new Y();

[fireflysemantics]

I see your point and I think I may know how to get around this now. If I include all the domain models inside one file, then I assume all the abbreviated class names will be unique within that file (Post optimization)?

Also I think that during optimization, it would still benefit Angular users if Angular made sure that all abbreviate class names were unique.

In other words, create a Map of all the abbreviated class names.

For each class names being considered for abbreviation, check the abbreviated name first in the Map. If it does not exist already, then allow that name. Otherwise choose a different name.

If Angular did this, then I would not need to understand that I need to keep all domain model classes in the same scope and each class could live in its own file.

I'm sure this gotcha will cause issues for others using annotations in the future, and they are hard to detect.

I built in a check for in my library that detects it. We're it not for that I could be scratching my head for weeks.

[angular-automatic-lock-bot]

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