[email protected] + webpack: runtime error after prod build

[borbelyzs]

We have upgraded our angular environment from version 5 to version 6, and now our angular-cli+webpack-based build system generates a "prod" build that fails at runtime in the typescript-logging module.

Error: Uncaught TypeError: Cannot read property 'Console' of undefined

It seems that the LoggerType enum is empty (or missing it's declaration). I have created a small environment to reproduce the bug here:
https://stackblitz.com/edit/angular-zhriph

[mreuvers]

Hey @dolf-o-matric

Maybe I am doing something wrong, but it doesn't show any error in the console. Instead the page gives:

Import error, can't find files:
index.html
main.ts

I also tried it directly using: https://angular-zhriph.stackblitz.io/

But that gave the same error, seems angular is not happy?

[borbelyzs]

Thank you for the quick reply! You are absolutely right; i should have clarified that: I used stackblitz only to host the files, not to run the project directly (or build it, if that's even possible on stackblitz).

So you should download them locally ("angular.json", "package.json", "tsconfig.json", and the whole "src" directory), run locally "npm install", and then start a build process with "npm run build". After a successful build move the results from the "dist" directory to a webserver-served environment to be able to run the project, and see the error message.

It will be a little tricky to read the stacktrace because every part of it is uglified, but it's possible.

[mreuvers]

Hey there, no problem. :)

I managed to reproduce it now as well, however after some digging around it seems it's angular's build doing something weird. Because the types it falls over are exported (I double checked).

Running it using: "npm run start" on the local ng dev. server works fine too (it logs).

See this json part from the angular configuration, changing "buildOptimizer" to false makes it run fine (using the dist stuff and moving that to a separate webserver). So whatever they're using there to optimize (probably uglify / webpack?) has a bug.

I am afraid there's not much I can do for you.

      "configurations": {
        "production": {
          "optimization": true,
          "outputHashing": "all",
          "sourceMap": false,
          "extractCss": true,
          "namedChunks": false,
          "aot": true,
          "extractLicenses": true,
          "vendorChunk": false,
          "buildOptimizer": false   // Changed this to false, and it's working fine.
        }
      }

[borbelyzs]

Okay, thanks for your update! It's still an early adoption (angular-cli -wise), maybe in 6.0.1 or so will be fixed.

[mreuvers]

Yeah at least you have a workaround for now. You may want to log an issue there - so they can determine what is failing exactly, it may only happen in some cases.

[borbelyzs]

With the latest angular-cli (6.0.1, published today) there is now runtime error, but the log in completely empty (buildOptimizer = true).

[mreuvers]

Well it's something else. Guess you need to wait and see until it's fixed. :)

[eastjie]

I have "Error: Uncaught TypeError: Cannot read property 'Console' of undefined" in Angular 6 at first with typescript-logging version 0.5.0 , after I update typescript-logging to 0.6.1 and make the refactoring. It seems to be fixed.

But I get the new error with "angular 6.0.2"
"If you specify loggerType to be Custom, you must provide the callBackLogger argument".

Only by setting "buildOptimizer = false" in my project, it works. I don't know if something goes wrong by optimizing.

[mreuvers]

Hello @eastjie

It feels like something is optimized away a bit too aggressively with that buildOptimizer flag on.

Can you paste the relevant code that causes this for you? Like your config setup for the logging, and the first logger and/or category you use.

See if I can get the same error like you.

The error it throws here, the code at least thinks you want to use a custom logger (not sure if that's true in your case)?

[eastjie]

@mreuvers , Thanks for your answer. I have tried in a new Angular Cli project. The error can be reproduced.

In configuration "logconfig.ts", logging is defined as follows:

import { Category, CategoryLogger, CategoryServiceFactory, CategoryConfiguration, LogLevel } from 'typescript-logging';
CategoryServiceFactory.setDefaultConfiguration(new CategoryConfiguration(LogLevel.Info));
export const catApp = new Category('app');
export const log: CategoryLogger = CategoryServiceFactory.getLogger(catApp);

And in "app.component.ts"

export class AppComponent implements OnInit {
  title = 'app';
  ngOnInit(): void {
    log.info('hallo, log');
  }
}

[mreuvers]

Thanks, I can reproduce it in a production type of build with that as well. It seems the optimizer is doing something wrong, it seems to not fully understand some default parameter value assignment or so and makes some funny code from it (it's near unreadable of course).

In development or without optimizer it all works fine (as expected, the javascript code then also looks like what it should be).

I'll have to experiment with it a bit to see if it can be worked around by writing the constructors code differently.

Did any of you log this (or some kind of similar issue) at the angular project? Because this is likely one of many projects that may fail due to the optimization.

[borbelyzs]

Our project uses HTTP client for REST API communication, supports OAUTH2 protocol, uses semi-recursive custom JSON parsing, uses heavely external gui libs like ng-bootstrap, ag-grid, ng-select, ng-fullcalendar, etc. None of these libs are causing problems (well, except for angular 6.0.1 and ag-grid, there was some stack size issues, but it's now fixed with angular 6.0.2, 6.0.3).

We have problems production-build-wise currently only with the typescript-logging lib. But again: i think it's still "early", maybe it will fix itself with the next angular (minor) version.

[eastjie]

In our project, other libs like ng-bootstrap, kendo-angular are used without problem for optimization. I have found some issues about product optimization. I thinks, it may need some time to wait for the next angular fix patch to check if this problem will be solved or not.

[mreuvers]

Thanks for the reply both of you!

Ok let's wait 1 or 2 minor fix patches of angular and see if it resolves itself. I'll have a look meanwhile as soon as I have some time left, to rewrite a little and see if that helps.

[borbelyzs]

Thanks for your work!

[mreuvers]

Hey guys,

Some update/progress. If you have anything to add/update please let me know as well.

I played around a bit, and have found something at last.

The problem is that for some reason most exported enums, are not generated properly in the compressed production js, they just missed their values basically. But 1 enum was generated properly with its values (and really the enums are not weird or anything).

Eventually I found why that single enum was "different", because that working enum was used in the same .ts file in an exported class. When I added some dummy code using the other enums there, guess what - they are generated propertly and it works in my test environment.

But this feels rather dirty and a hack to workaround a bug in the optimizer of angular. I will play a bit more later this week, to see if maybe splitting the things in different files works (or also fails just as bad).

This was tested with angular 6.0.3 (afaik the latest when writing).

[mreuvers]

We should keep an eye on angular/angular-cli#10655 which seems to be a regression.

Similar problems, including enums are described therẹ.

The workaround for now is indeed to put the flag: "buildOptimizer" to false.

[borbelyzs]

Yep, it seems the same problem to me, hope they will be fixing it soon

[eastjie]

Since "angular/angular-cli#10655" is fixed, I have tried today. The problem is fixed in my project with the "angular/cli: 6.0.8" and "angular-devkit/build-angular: 0.6.8" version. Thanks.

[mreuvers]

Cheers for the update! Works for you too @borbelyzs ?

[borbelyzs]

Yes, it's working now, i just made a test-build; everything's fine! Thanks, @mreuvers, @eastjie!