Cycle d'imports détecté

Un composant, une directive ou un pipe référencé par ce composant obligerait le compilateur à ajouter un import qui créerait un cycle d'imports. Par exemple, considérez le cas où un Parent référence un Child dans son template :

parent.ts

import {Component} from '@angular/core';
import {Child} from './child';

@Component({
  selector: 'app-parent',
  imports: [Child],
  template: '<app-child/>',
})
export class Parent {}

child.ts

import {Component, inject} from '@angular/core';
import {Parent} from './parent';

@Component({
  selector: 'app-child',
  template: 'The child!',
})
export class Child {
  private parent = inject(Parent);
}

Il existe déjà un import de child.ts vers parent.ts, puisque Child référence Parent dans son constructeur.

Utile : Le template du composant parent contient <child></child>. Le code généré pour ce template doit donc contenir une référence à la classe Child. Pour créer cette référence, le compilateur devrait ajouter un import de parent.ts vers child.ts, ce qui provoquerait un cycle d'imports :

parent.ts -> child.ts -> parent.ts

Portée distante

Si vous utilisez des NgModules, pour éviter d'ajouter des imports qui créent des cycles, du code supplémentaire est ajouté à la classe NgModule dans laquelle est déclaré le composant, afin de relier les dépendances.

C'est ce qu'on appelle la « portée distante » (remote scoping).

Libraries

Malheureusement, le code de « portée distante » a des effets de bord — ce qui empêche le tree-shaking — et ne peut pas être utilisé dans les libraries. Ainsi, lors du build de libraries avec le paramètre "compilationMode": "partial", tout composant qui nécessiterait un import cyclique provoquera cette erreur de compilation NG3003.

Déboguer l'erreur

Le cycle qui serait généré est affiché dans le message d'erreur. Par exemple :

The component Child is used in the template but importing it would create a cycle:
/parent.ts -> /child.ts -> /parent.ts

Servez-vous-en pour identifier comment le composant, le pipe ou la directive référencé dépend en retour du composant en cours de compilation. Voici quelques pistes pour corriger le problème :

Essayez de réorganiser vos dépendances pour éviter le cycle. Par exemple, en utilisant une interface intermédiaire, placée dans un fichier indépendant qui peut être importé dans les deux fichiers dépendants sans provoquer de cycle d'imports.
Déplacez les classes qui se référencent mutuellement dans le même fichier, pour éviter tout import entre elles.
Convertissez les instructions d'import en imports de type uniquement (avec la syntaxe import type) si les déclarations importées ne sont utilisées que comme types, car les imports de type uniquement ne contribuent pas aux cycles.