Skip to content

CommonJS or AMD dependencies warnings with absolute path #18057

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
grunk opened this issue Jun 29, 2020 · 17 comments · Fixed by #18259
Closed

CommonJS or AMD dependencies warnings with absolute path #18057

grunk opened this issue Jun 29, 2020 · 17 comments · Fixed by #18259

Comments

@grunk
Copy link

grunk commented Jun 29, 2020

🐞 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

@Greenek
Copy link

Greenek commented Jun 29, 2020

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/*"]
        }

@alan-agius4
Copy link
Collaborator

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

@alan-agius4 alan-agius4 added the needs: more info Reporter must clarify the issue label Jun 29, 2020
@Greenek
Copy link

Greenek commented Jun 29, 2020

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

@grunk
Copy link
Author

grunk commented Jun 29, 2020

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

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

@alan-agius4
Copy link
Collaborator

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

@alan-agius4 alan-agius4 added needs: repro steps We cannot reproduce the issue with the information given and removed needs: more info Reporter must clarify the issue labels Jun 29, 2020
@grunk
Copy link
Author

grunk commented Jun 29, 2020

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

@ahmadmu
Copy link

ahmadmu commented Jun 30, 2020

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.

@alan-agius4 alan-agius4 added area: @angular-devkit/build-angular devkit/build-angular:browser freq1: low Only reported by a handful of users who observe it rarely severity3: broken and removed needs: repro steps We cannot reproduce the issue with the information given labels Jun 30, 2020
@ngbot ngbot bot modified the milestone: needsTriage Jun 30, 2020
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Jun 30, 2020
@alan-agius4
Copy link
Collaborator

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.

@fxck
Copy link

fxck commented Jun 30, 2020

@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

@alan-agius4
Copy link
Collaborator

@fxck, see #18019 (comment)

@grunk
Copy link
Author

grunk commented Jul 1, 2020

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.

@tomardern
Copy link

tomardern commented Jul 8, 2020

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

@Greenek
Copy link

Greenek commented Jul 8, 2020

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

@jimmykane
Copy link

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.

@alan-agius4
Copy link
Collaborator

alan-agius4 commented Jul 14, 2020

@Greenek, in that case please provide a reproduction. Otherwise we’ll 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’t 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.

@jimmykane
Copy link

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

Really man ?

clydin pushed a commit that referenced this issue Jul 15, 2020
…plateUrl and styleUrl

Currently, when users use either absolute paths, or path mappings in JIT mode, we issue a warning for templateUrl and styleUrl. With this change we suppress those warning.

Closes: #18057
clydin pushed a commit that referenced this issue Jul 15, 2020
…plateUrl and styleUrl

Currently, when users use either absolute paths, or path mappings in JIT mode, we issue a warning for templateUrl and styleUrl. With this change we suppress those warning.

Closes: #18057
(cherry picked from commit 2aedad9)
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Aug 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants