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.

[abdel-ships-it]

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.