By default, this rule only detects cycles for ES6 imports, but see the [`no-unresolved` options](./no-unresolved.md#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:
```js
/*eslint import/no-cycle: [2, { maxDepth: 1 }]*/
// dep-c.js
import './dep-a.js'
```
```js
// dep-b.js
import './dep-c.js'
export function b() { /* ... */ }
```
```js
// 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:
This option disable reporting of errors if a cycle is detected with at least one dynamic import.
```js
// 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](https://github.com/import-js/eslint-plugin-import/issues/2265). Please be extra careful about using this option.
