Angular-cli: Getting "WARNING in Circular dependency detected" when referencing components from single "barrel" file

[williamBurgeson]

See https://github.com/williamBurgeson/circ-ref for an example of this problem.

In my project, I have used a "all-components" and "all-services" file in each folder to tidy up the imports, but at some point with angular-cli between 1.2.7 and 1.4.1 this started provoking warnings such as below:

WARNING in Circular dependency detected:
src/app/all-components.ts -> src/app/hello/hello.component.ts -> src/app/all-components.ts

WARNING in Circular dependency detected:
src/app/hello/hello.component.ts -> src/app/all-components.ts -> src/app/hello/hello.component.ts

I have seen issues logged to the effect that warnings were desirable, however in this case the project builds and works fine apart from showing the same warnings in the console, and when run with the --prod switch no warnings are provoked.

As the sample app shows, both the "hello" and "goodbye" components are redeclared in the "all-components.ts" file, through which the app.component and app.module reference them as necessary. The "hello" component also references the "goodbye" component programmatically, in order to set a property.

I know it's possible to set properties exclusively through the HTML, however the requirements of my project are such that I need to reference components, sometimes with a circular dependency (as I might have done with classes in .net for example)

Ideally, this "feature" would be amended, to check if the circular references really are harmful, and either removed, made less sensitive, or some way can be offered to allow in a given situation such as mine to prevent the warning occurring.

[williamBurgeson]

Update: this condition appears to have come into effect from 1.3.0 onwards. Until this is fixed I'll have to stay on 1.2.7

[williamBurgeson]

For further info: I did get an error elsewhere in my code where I had a local provider declaration in a component (I needed the dependency to hold state specific to that component, so I had to declare the provider directly in the @Component([providers]) array, and I got an error at runtime, which I solved using ... useClass: forwardRef(() => MyService) instead of ... useClass: MyService - there's no obvious way to do this for components for, which my warnings seem to be revolved around...

[valentinstn]

I'm familiar with the forwardRef method and that this does solve some problems with circular dependencies. However, we are only using that when we couldn't find a better way to solve the dependencies.

Does anyone know if the usage of forwardRef has any negative side effects? Is a broad usage of this functionality unproblematic?

[Brocco]

The ability to show/hide circular dependency warnings was introduced and is controllable via .angular-cli.json you can see documentation about that feature here search for "showCircularDependencies"

[williamBurgeson]

Thanks for this. With the use of "barrel" files, are there any actual problems which can occur as a result of these "circular dependencies"? As mentioned in a comment, I understand the use of forwardRef may be appropriate and required at times, however I would like to know if there are any situations where I might actually want to be warned about true circular dependencies - assuming a statically loaded module is not able to hard-reference a lazy-loaded module for instance

[born2net]

would be awesome if we can turn off circle dep for specific files.

[born2net]

I am using ng-cli 1.4.4 and still getting:

src\comps\simple-grid-module\SimpleGridDraggable.ts -> src\comps\simple-grid-module\SimpleGridTable.ts -> src\comps\simple-grid-module\SimpleGridDraggable.ts

WARNING in Circular dependency detected:
src\comps\simple-grid-module\SimpleGridRecord.ts -> src\comps\simple-grid-module\SimpleGridTable.ts -> src\comps\simple-grid-module\SimpleGridRecord.ts

WARNING in Circular dependency detected:
src\comps\simple-grid-module\SimpleGridTable.ts -> src\comps\simple-grid-module\SimpleGridRecord.ts -> src\comps\simple-grid-module\SimpleGridTable.ts

WARNING in Circular dependency detected:
src\services\yellowpepper.service.ts -> src\app\campaigns\campaign-orientation.ts -> src\services\yellowpepper.service.ts

and I did set

"apps": [
    {
      "root": "src",
      "outDir": "dist",
      "showCircularDependencies": false,
      "assets": [

am I missing something?

               |___/         
@angular/cli: 1.4.4          
node: 6.9.4                  
os: win32 x64                
@angular/animations: 4.4.4   
@angular/common: 4.4.4       
@angular/compiler: 4.4.4     
@angular/core: 4.4.4         
@angular/forms: 4.4.4        
@angular/http: 4.4.4         
@angular/platform-browser: 4.
@angular/platform-browser-dyn
@angular/router: 4.4.4       
@angular/cli: 1.4.4          
@angular/compiler-cli: 4.4.4 
@angular/language-service: 4.
@ngtools/webpack: 1.7.2      
typescript: 2.3.4            

regards

Sean

[dr-mohamed-benkhalifa]

@born2net: you should add showCircularDependencies as following to your .angular-cli.json:

....
  "defaults": {
    ....
    "build": {
      "showCircularDependencies": false
    }
  }

[born2net]

thank you

[emilio-martinez]

@Brocco I hadn't taken a look at Angular CLI is a while because at first it didn't fit my needs. However, I was recently taking a look at how it's evolved, and I have to say this is a really nice feature. Thank you!

For those in the thread reading this, I would consider keeping this warning on as a measure of code quality rather than a bad/annoying thing.

[realappie]

I wonder what kind of side effects this could have, I am aware of the fact I can simply turn it off. But why is this a warning in the first place? Can someone help me understand the problem (Or the possibility of a problem)

[emilio-martinez]

@realappie The circular dependencies surfaced here relate to files that either directly or indirectly are mutually importing each other. It's not an uncommon occurrence in software, but the results can vary. It doesn't necessarily mean that something wrong _will happen_, but it's important to surface because something wrong _may_ happen depending on the use case.

For the most part, it's fairly easy to refactor your way towards no circular dependencies, so that's why it's a warning, but ultimately, I would consider it a good practice to move away from these types of patterns.

[williamBurgeson]

Maybe some would disagree but I can't think of any reason why "barrel files" would be considered a bad thing - possibly because I'm coming from a .net world where all classes within a given assembly are visible by default elsewhere, rather than each class being dependent on others in a strictly non-circular way.
Of course for DI/IoC this is different - ClassA can't take a constructor dependency on ClassB for example when vice-versa applies, but this doesn't mean that we shouldn't be able to have both ClassA and ClassB in the same index file, to make the boilerplate for importing them considerably cleaner and less verbose.
Just my tuppenceworth...

[emilio-martinez]

@williamBurgeson ClassA and ClassB can absolutely be in the same file if needed. This warning is not an opinion on bad behavior; it's more of a PSA or an FYI.

[thomkok18]

@williamBurgeson I solved this issue by removing the unused inside the import statement where the warning is referring to. Maybe this is what your looking for?

[dereklin]

I am trying out nrwl/nx and using one index.ts in the libs folder to export everything that's shared between the apps. And I have things inside libs also importing from libs/index.ts. I get many "Circular dependency detected" warnings. But there was no real circular dependency problem. libs/index.ts is not a class.

If the warning system can go deep into the actual class level and find out the real circular dependency it will be great

[christophechevalier]

@Brocco
I don't think it's a good idea to want to hide the warnings of circular dependencies.
We should consider that circular dependencies can be managed in our structure and especially through our reducers & selectors.
It is possible to do otherwise. I saw in some projects some examples, but none with Angular + Rxjs.
I still share what could be a solution:

http://randycoulman.com/blog/2016/09/27/modular-reducers-and-selectors/
https://github.com/piotrwitek/react-redux-typescript-guide
https://github.com/reactjs/reselect#customize-equalitycheck-for-defaultmemoize
https://github.com/toomuchdesign/re-reselect
https://github.com/HenrikJoreteg/redux-bundler-example
https://github.com/HenrikJoreteg/redux-bundler

[mark-langer]

I noticed that I get this error if you forget to specify the file endings for the template url or style urls.
Exmaple:
templateUrl: 'my.component' should better be templateUrl: 'my.component.html'.

[ghost]

@christophechevalier
My data structure is not flat. I have a circles like that:
src\app\_models\type1.ts -> src\app\_models\type2.ts -> src\app\_models\type-caster.ts -> src\app\_models\type1.ts
I am casting types live not knowing for sure what types will come. This is just a valid data structure. But I am not punished with these warnings that I don't wanna have in this case. Because they don't make sense here.
The types might be the same but the content is different like 2 is a number and 5 is a number too. It only happens because I must import a previous class again.

[elvisbegovic]

what is the new syntax (v6 rc3) to disable showCircularDependencies please?

cc @filipesilva

[kotsias]

You can disable warning by adding this in the section Architect > Build > Options
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:browser",
"options": {
"showCircularDependencies": false,

[chriswep]

I noticed that I get this error if you forget to specify the file endings for the template url or style urls.
Exmaple:
templateUrl: 'my.component' should better be templateUrl: 'my.component.html'.

i don't know why i didn't add the file ending in the first place, but this was exactly my problem. thanks @mark-langer

[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._}