Angular-cli: Angular 10. CommonJS or AMD dependencies can cause optimization bailouts

[alekcey0211]

After update to angular 10. I got this warning.

WARNING in ...\projects\client\src\app\localization.ts depends on devextreme/localization/globalize/date. CommonJS or AMD dependencies can cause optimization bailouts.

after read link "https://angular.io/guide/build#configuring-commonjs-dependencies"
i made this

    "build": {
        "builder": "@angular-devkit/build-ng-packagr:build",
        "options": {
            "allowedCommonJsDependencies": [
                "lodash",
                "devextreme-angular",
                "devextreme",
                "@firebase",
                "@angular/fire",
                "devexpress-richedit",
                "x-data-spreadsheet"
            ],
            "tsConfig": "projects/core/tsconfig.lib.json",
            "project": "projects/core/ng-package.json"
        }
    }

But this don`t help me.

What i doing wrong?

[alan-agius4]

Hi @alekcey0211,

Your module entrypoint is devextreme/localization/globalize/date which is not listed in the above.

[BlindDespair]

I would reopen this. The current solution is very inconvenient! We're using lodash in our project and we use synthetic imports to have smaller bundles when importing lodash functions. So we use it like import isEmpty from 'lodash/isEmpty;' and we get a warning per each function and now it's not enough to just say in angular.json 'lodash', but we have to write a long list like "lodash/isEmpty", "lodash/uniqBy", "lodash/get" etc, even though it's just one package in node_modules! We don't want to specify every lodash function we want to use in angular.json just to suppress warning... Would be great if it can be handled per package and not per import.

[ahmadmu]

I'm getting this error when loading local Angular components in their respective modules through a global path like @app. We're using @app to refer to our ./src/app/* folder in tsconfig:

    "paths": {
      "@app/*": [
        "./src/app/*"
      ]
     }

Here's the full error for one of the modules:

WARNING in [...]\src\app\shared-components\shared-components.module.ts depends on @app/shared-components/dashboard/dashboard.component. CommonJS or AMD 
dependencies can cause optimization bailouts.

I know the path should be relative here, but then the error message should reflect that (or another issue) and this error is a bit misleading.

Edit: I looked into it a bit further, and not all components that are loaded this way are showing the warning.

[alan-agius4]

@BlindDespair, let's continue tracking this https://github.com/angular/angular-cli/issues/18058 since it's has more details.
@ahmadmu, see https://github.com/angular/angular-cli/issues/18057

[jimmykane]

Hi I dont understand the problem here at all.

I get:

/Users/dimtrioskanellopoulos/Projects/track-tools/src/app/services/app.event.service.ts depends on '@sports-alliance/sports-lib/lib/events/adapters/importers/json/importer.json'

The lib it depends on is fine to be imported with any other project.

Import is in file /Users/dimtrioskanellopoulos/Projects/track-tools/src/app/services/app.event.service.ts:

import { EventImporterJSON } from '@sports-alliance/sports-lib/lib/events/adapters/importers/json/importer.json';

[jimmykane]

Also most important:

Why is this not on the Angular Upgrade GUIDE! ? Do we really have to sniff up the web ?

[sgunaseelan56]

WARNING in component.ts depends on 'socket.io-client'. CommonJS or AMD dependencies can
cause optimization bailouts

[Pattsu]

After I upgrade Angular version from 9 to 10...

[hudzenko]

@ahmadmu I have totally same behaviour. I do not really understand why this issue is closed. But that is so stupid because the warning is totally random and talks about other problem but not using aliases for imports for the same module

Inside conversation module:
import { ConversationComponent } from '@app/features/apps/conversation/conversation.component';

Warning:
WARNING in .../src/app/features/apps/conversation/conversation.module.ts depends on '@app/features/apps/conversation/conversation.component'. CommonJS or AMD dependencies can cause optimization bailouts.

That is so stupid...

[sgunaseelan56]

I have resolved this issue by adding it to the angular.json ->
allowedCommonJsDependencies.
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:browser",
"options": {
"allowedCommonJsDependencies" : [

• "socket.io-client", //Warning related packages*
• "socket.io-parser",*
• "debug"*
• ], *

Thanks and Regards,
Gunaseelan S

On Tue 14 Jul, 2020, 19:11 Evhenii Hudzenko, [e-mail]
wrote:

@ahmadmu https://github.com/ahmadmu I have totally same behaviour. I do
not really understand why this issue is closed. But that is so stupid
because the warning is totally random and talks about other problem but not
using aliases for imports for the same module

Inside conversation module:
import { ConversationComponent } from
'@app/features/apps/conversation/conversation.component';

Warning:
WARNING in .../src/app/features/apps/conversation/conversation.module.ts
depends on '@app/features/apps/conversation/conversation.component'.
CommonJS or AMD dependencies can cause optimization bailouts.

That is so stupid...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/18025#issuecomment-658186265,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APDPFHDJ2SKMWQIFIAMGAETR3ROCFANCNFSM4OIJYY5Q
.

[jimmykane]

Hi @alan-agius4 can you guide me to the issue that will solve our production issues since updating and following the guides broke many things.

To be honest after this it's the first time I will say: I am not sure I recommend angular.

And that is due to the team member communications.

I will be reporting this to my superiors that are working for Google on a colab project anyways.

That's not the way Todo things.

[thomasoreilly]

Hi @alan-agius4.
We're seeing this issue arise on applications built with Angular 10 consuming our library (built with Angular 9). Adding the dependencies to the allowedCommonJsDependencies solves the warnings which is great, however, is there another solution where the consuming application doesn't need to config for our library dependencies? I was thinking maybe writing an upgrading schematic to update their angular.json, not sure if that is even possible as I have not done that before. Is there anything else you can suggest please.

Thanks,
Thomas.

[alan-agius4]

Hi @thomasoreilly,

No, there isn’t a configuration to disable the warning at a library level.

The reason being is that the consumer of a given library must be made aware that by using a library in CJS format they might cause optimization bailouts which may impact negatively on SEO, bundle size and performance. This is because CJS libraries cannot be optimized as much as ESM or FESM by bundlers such as Webpack and Rollup.

Users can choose to suppress the warning and accept that they might have larger bundles sizes and unused code in their final bundle, until either the problematic library is distributed in a modern format or they replace it with another modern library.

[thomasoreilly]

Hi @thomasoreilly,

No, there isn’t a configuration to disable the warning at a library level.

The reason being is that the consumer of a given library must be made aware that by using a library in CJS format they might cause optimization bailouts which may impact negatively on SEO, bundle size and performance. This is because CJS libraries cannot be optimized as much as ESM or FESM by bundlers such as Webpack and Rollup.

Users can choose to suppress the warning and accept that they might have larger bundles sizes and unused code in their final bundle, until either the problematic library is distributed in a modern format or they replace it with another modern library.

Thanks for this information @alan-agius4.

[ruslanguns]

I hate warnings! BUT agreed with @thomasoreilly, the way that @sgunaseelan56 suppressed the warnings is working just fine... still don't see any differences on my building process so I can ignore it.

[phil123456]

I am not sure I recommend angular.

it's a nightmare

[lenichols]

@sgunaseelan56 that seemed too have worked... thx

[guisperandio]

Im currently using the custom-webpack builder, and im not able to use the allowedCommonJsDependencies property.

[edoardo849]

on Angular ~10.0.9 and Amplify ^3.3.1 the following seems to remove all warnings:

File angular.json

"architect": {
        "build": {
            "options": {
            "allowedCommonJsDependencies": [
              "uuid",
              "ulid",
              "lodash/get",
              "lodash/isEmpty",
              "lodash/isEqual",
              "@aws-amplify/core",
              "buffer",
              "@aws-crypto/sha256-js",
              "crypto-js/hmac-sha256",
              "crypto-js/lib-typedarrays",
              "zen-observable",
              "js-cookie",
              "isomorphic-unfetch",
              "@aws-crypto/crc32",
              "fast-xml-parser",
              "@aws-crypto/sha256-browser",
              "axios"
            ]
}}}

[PBartrina]

@guisperandio Have you found a fix por que custom-webpack builder users?

[guisperandio]

@PBartrina Not yet, tbh I was not looking into it, cause the alert message it is not a problem yet, but definitelyit is something that im gonna look into next week

[UchihaYuki]

How can I know which import will cause "CommonJS or AMD dependencies can cause optimization bailouts."?

When I

import { map } from 'rxjs/operators'

Everything works well, but when I

 import { map } from 'rxjs/internal/operators'

This warning is show, but I can't see the reason.

[gunjankhanwilkar]

How can I know which import will cause "CommonJS or AMD dependencies can cause optimization bailouts."?

When I

import { map } from 'rxjs/operators'

Everything works well, but when I

 import { map } from 'rxjs/internal/operators'

This warning is show, but I can't see the reason.

You can find a good explanation here - https://stackoverflow.com/a/62604034/6097025

[guisperandio]

@PBartrina I tested that today and the allowedCommonJsDependencies it is working with @angular-builders/custom-webpack:browser now

[PBartrina]

@guisperandio Thanks for the update! <3

[angular-automatic-lock-bot[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._}