Angular-cli: CommonJS or AMD dependencies warnings with absolute path

Created on 29 Jun 2020  路  17Comments  路  Source: angular/angular-cli

馃悶 Bug report

Command

  • [x ] build
  • [x ] serve

Is this a regression?

The warning was no present in v9

Description

When building an app , every import of a module with an absolute path lead to a warning :

import { PasswordStrengthBarComponent } from 'app/components/util/password-strength-bar/password-strength-bar.component';

generate the following warning :

WARNING in D:\full_path\shared.module.ts depends on app/components/util/password-strength-bar/password-strength-bar.component. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

Using a relative path instead fix the warning :
import { PasswordStrengthBarComponent } from '../components/util/password-strength-bar/password-strength-bar.component';
`

I find this warning missleading. According to MDN the module path can be relative or absolute. At least the warning should be different from the real case were commonJS dependencies are used.

馃敩 Minimal Reproduction

Import a module with absolute path and ng build the project

馃敟 Exception or Error


WARNING in D:\full_path\shared.module.ts depends on app/components/util/password-strength-bar/password-strength-bar.component. CommonJS or AMD dependencies can cause optimization bailouts.
> For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

馃實 Your Environment


Angular CLI: 10.0.0
Node: 10.16.0
OS: win32 x64

Angular: 10.0.1
... animations, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.1000.0
@angular-devkit/build-angular     0.1000.0
@angular-devkit/build-optimizer   0.1000.0
@angular-devkit/build-webpack     0.1000.0
@angular-devkit/core              10.0.0
@angular-devkit/schematics        10.0.0
@angular/cli                      10.0.0
@ngtools/webpack                  10.0.0
@schematics/angular               10.0.0
@schematics/update                0.1000.0
rxjs                              6.5.4
typescript                        3.9.5
webpack                           4.43.0

devkibuild-angular browser low broken bufix

Most helpful comment

@Greenek, in that case please provide a reproduction. Otherwise we鈥檒l be unable to investigate your issue.

@jimmykane, this feature has been present and finalized since the early beta releases of version 10. None-the-less certain issues were only raised after the stable release. One of the reasons why we do release betas and release candidates is for the community to try out new things and gather feedback and address bugs before the stable version is released. So apologies for the inconvenience but if you didn鈥檛 try the betas and raised the issues at that time you also share the responsibility that this bug is now present in the stable version. We cannot possibility think of all the use cases that thousands of users have, which in some cases might be non-standard.

All 17 comments

The same problem occurs when using tsconfig.json paths. Adding them to allowedCommonJsDependencies doesn't help.

.../src/app/app.component.ts depends on @core/services/config.service. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies
{
    "architect": {
        "build": {
            "options": {
                "allowedCommonJsDependencies": [
                    "@core/*"
                ],

tsconfig.base.json:

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

@Greenek & @grunk what鈥檚 the value module in your tsconfig.base.json and tsconfig.app.json?

@alan-agius4: ESNext

Full tsconfig.base.json configuration:

{
    "compileOnSave": false,
    "compilerOptions": {
        "allowSyntheticDefaultImports": true,
        "baseUrl": "./",
        "declaration": false,
        "downlevelIteration": true,
        "emitDecoratorMetadata": true,
        "esModuleInterop": true,
        "experimentalDecorators": true,
        "importHelpers": true,
        "lib": ["ES2018", "ES2020", "DOM"],
        "module": "ESNext",
        "moduleResolution": "node",
        "outDir": "./dist/out-tsc",
        "resolveJsonModule": true,
        "sourceMap": true,
        "target": "ES5",
        "typeRoots": ["node_modules/@types"],
        "paths": {
            "@core/*": ["./src/app/core/*"],
            "@modules/*": ["./src/app/modules/*"],
            "@shared/*": ["./src/app/shared/*"]
        }
    },
    "angularCompilerOptions": {
        "fullTemplateTypeCheck": true,
        "strictInjectionParameters": true
    }
}

@Greenek & @grunk what鈥檚 the value module in your tsconfig.base.json and tsconfig.app.json?

esnext in tsconfig.base and it's not in tsconfig.app

Hi again,

I just tried this locally and wasn't able to reproduce any of the above issues.
Screenshot 2020-06-29 at 15 04 46

Can you setup a minimal repro please?

You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.

This might be related to your directory structure so its really important to get an accurate repro to diagnose this.

Thanks

You can find a minimal app where i can reproduce the problem : https://github.com/grunk/demo_bug_angular_cli
I basically took my current app and stripped down almost everything.
Note that this app has started with Angular 2 RC's and is beeing updated since. So it's possible that the structure is not the exact same that you can find by creating a new project.

ng build should gave you the warning :

WARNING in YOUR_PATH\shared.module.ts depends on app/components/util/password-strength-bar/password-strength-bar.component. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

If you change the import in shared.module.ts from
import { PasswordStrengthBarComponent } from 'app/components/util/password-strength-bar/password-strength-bar.component';
to
import { PasswordStrengthBarComponent } from '../components/util/password-strength-bar/password-strength-bar.component';

And build it again. The warning is now gone.

Maybe it has something to do with shared module ?

image

For us most of the warning messages are coming from local modules as well, when importing components and declaring them in their respective module using absolute paths. Changing the paths to relative fixes the issue as well.

The weird thing is that in one of the shared modules, which is located in the same folder/path as another module, not all components that are imported through absolute paths are showing the warning messages, only some.

Hi, thanks for the reproduction.

I have looked at this and this is caused by a combination of 2 things. The first being using non relative imports and the second is that you are using JIT instead of AOT for your development builds. When using JIT, component templates and style sheets are required via a CommonJs require statement.

@alan-agius4 how about this one:

WARNING in /Users/fxck/www/zeropsmonorepo/apps/zerops/src/modules/app/app.module.ts depends on @angular/common/locales/cs. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

The first being using non relative imports and the second is that you are using JIT instead of AOT for your development builds.

that would be because AOT is unusable on medium to large projects

Hi, thanks for the reproduction.

I have looked at this and this is caused by a combination of 2 things. The first being using non relative imports and the second is that you are using JIT instead of AOT for your development builds. When using JIT, component templates and style sheets are required via a CommonJs require statement.

Switching to AOT in debug build indeed fix the warnings. That's a good enough solution for me.

We've also been upgrading over the last few years from 5, to 6, to 7, to 8, to 9 and now attempting to upgrade to 10. We've been getting the same cryptic warning messages. The app will still run locally.

We use typescript path aliases such as:

...
"compilerOptions": {
    "baseUrl": "./",
    "importHelpers": true,
    "paths": {
      "Shared/*": ["src/app/shared/*"],
...

And we use them in our app such as:

import { AppComponent } from 'Shared/components/app/app.component';

When attempting to ng serve we get the following error:

>> WARNING in {project path}/src/app/app.module.ts depends on 'Shared/components/app/app.component'. CommonJS or AMD dependencies can cause optimization bailouts.
>> For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

As a fix (as outlined by @grunk above), enabling aot within angular.json file does seem to help:

...
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "aot": true, <-- Add this!
...

I have the aot option enabled all the time and I'm still receiving this warning.

Still issues here with aot.

Please add these issue to the update guide or stop releasing an unfinished and not well tested version that causes developers time lost.

@Greenek, in that case please provide a reproduction. Otherwise we鈥檒l be unable to investigate your issue.

@jimmykane, this feature has been present and finalized since the early beta releases of version 10. None-the-less certain issues were only raised after the stable release. One of the reasons why we do release betas and release candidates is for the community to try out new things and gather feedback and address bugs before the stable version is released. So apologies for the inconvenience but if you didn鈥檛 try the betas and raised the issues at that time you also share the responsibility that this bug is now present in the stable version. We cannot possibility think of all the use cases that thousands of users have, which in some cases might be non-standard.

Are you literally saying I am responsible for this issue (and others) for not trying the betas ?

Really man ?

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