InternetProgramming/Lab3/node_modules/eslint-plugin-import/docs/rules/no-cycle.md

import/no-cycle

Ensures that there is no resolvable path back to this module via its dependencies.

This includes cycles of depth 1 (imported module imports me) to "∞" (or Infinity), if the maxDepth option is not set.

// dep-b.js
import './dep-a.js'

export function b() { /* ... */ }

// dep-a.js
import { b } from './dep-b.js' // reported: Dependency cycle detected.

This rule does not detect imports that resolve directly to the linted module; for that, see no-self-import.

This rule ignores type-only imports in Flow and TypeScript syntax (import type and import typeof), which have no runtime effect.

Rule Details

Options

By default, this rule only detects cycles for ES6 imports, but see the no-unresolved options as this rule also supports the same commonjs and amd flags. However, these flags only impact which import types are linted; the import/export infrastructure only registers import statements in dependencies, so cycles created by require within imported modules may not be detected.

maxDepth

There is a maxDepth option available to prevent full expansion of very deep dependency trees:

/*eslint import/no-cycle: [2, { maxDepth: 1 }]*/

// dep-c.js
import './dep-a.js'

// dep-b.js
import './dep-c.js'

export function b() { /* ... */ }

// dep-a.js
import { b } from './dep-b.js' // not reported as the cycle is at depth 2

This is not necessarily recommended, but available as a cost/benefit tradeoff mechanism for reducing total project lint time, if needed.

ignoreExternal

An ignoreExternal option is available to prevent the cycle detection to expand to external modules:

/*eslint import/no-cycle: [2, { ignoreExternal: true }]*/

// dep-a.js
import 'module-b/dep-b.js'

export function a() { /* ... */ }

// node_modules/module-b/dep-b.js
import { a } from './dep-a.js' // not reported as this module is external

Its value is false by default, but can be set to true for reducing total project lint time, if needed.

allowUnsafeDynamicCyclicDependency

This option disable reporting of errors if a cycle is detected with at least one dynamic import.

// bar.js
import { foo } from './foo';
export const bar = foo;

// foo.js
export const foo = 'Foo';
export function getBar() { return import('./bar'); }

Cyclic dependency are always a dangerous anti-pattern as discussed extensively in #2265. Please be extra careful about using this option.

When Not To Use It

This rule is comparatively computationally expensive. If you are pressed for lint time, or don't think you have an issue with dependency cycles, you may not want this rule enabled.

Further Reading

• Original inspiring issue
• Rule to detect that module imports itself: no-self-import
• import/external-module-folders setting