The warning was no present in v9
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.
Import a module with absolute path and ng build the project
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
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
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
modulein yourtsconfig.base.jsonandtsconfig.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.

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 ?

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
@fxck, see https://github.com/angular/angular-cli/issues/18019#issuecomment-650048878
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._
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.