Tim van der Lippe | fdbd42e | 2020-04-07 14:14:36 | [diff] [blame] | 1 | # import/no-cycle |
| 2 | |
| 3 | Ensures that there is no resolvable path back to this module via its dependencies. |
| 4 | |
Tim van der Lippe | 16aca39 | 2020-11-13 11:37:13 | [diff] [blame] | 5 | This includes cycles of depth 1 (imported module imports me) to `"∞"` (or `Infinity`), if the |
Tim van der Lippe | fdbd42e | 2020-04-07 14:14:36 | [diff] [blame] | 6 | [`maxDepth`](#maxdepth) option is not set. |
| 7 | |
| 8 | ```js |
| 9 | // dep-b.js |
| 10 | import './dep-a.js' |
| 11 | |
| 12 | export function b() { /* ... */ } |
| 13 | ``` |
| 14 | |
| 15 | ```js |
| 16 | // dep-a.js |
| 17 | import { b } from './dep-b.js' // reported: Dependency cycle detected. |
| 18 | ``` |
| 19 | |
| 20 | This rule does _not_ detect imports that resolve directly to the linted module; |
| 21 | for that, see [`no-self-import`]. |
| 22 | |
| 23 | |
| 24 | ## Rule Details |
| 25 | |
| 26 | ### Options |
| 27 | |
| 28 | 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 |
| 29 | import/export infrastructure only registers `import` statements in dependencies, so |
| 30 | cycles created by `require` within imported modules may not be detected. |
| 31 | |
| 32 | #### `maxDepth` |
| 33 | |
| 34 | There is a `maxDepth` option available to prevent full expansion of very deep dependency trees: |
| 35 | |
| 36 | ```js |
| 37 | /*eslint import/no-cycle: [2, { maxDepth: 1 }]*/ |
| 38 | |
| 39 | // dep-c.js |
| 40 | import './dep-a.js' |
| 41 | ``` |
| 42 | |
| 43 | ```js |
| 44 | // dep-b.js |
| 45 | import './dep-c.js' |
| 46 | |
| 47 | export function b() { /* ... */ } |
| 48 | ``` |
| 49 | |
| 50 | ```js |
| 51 | // dep-a.js |
| 52 | import { b } from './dep-b.js' // not reported as the cycle is at depth 2 |
| 53 | ``` |
| 54 | |
| 55 | This is not necessarily recommended, but available as a cost/benefit tradeoff mechanism |
| 56 | for reducing total project lint time, if needed. |
| 57 | |
Tim van der Lippe | 16aca39 | 2020-11-13 11:37:13 | [diff] [blame] | 58 | #### `ignoreExternal` |
| 59 | |
| 60 | An `ignoreExternal` option is available to prevent the cycle detection to expand to external modules: |
| 61 | |
| 62 | ```js |
| 63 | /*eslint import/no-cycle: [2, { ignoreExternal: true }]*/ |
| 64 | |
| 65 | // dep-a.js |
| 66 | import 'module-b/dep-b.js' |
| 67 | |
| 68 | export function a() { /* ... */ } |
| 69 | ``` |
| 70 | |
| 71 | ```js |
| 72 | // node_modules/module-b/dep-b.js |
| 73 | import { a } from './dep-a.js' // not reported as this module is external |
| 74 | ``` |
| 75 | |
| 76 | Its value is `false` by default, but can be set to `true` for reducing total project lint time, if needed. |
| 77 | |
Tim van der Lippe | fdbd42e | 2020-04-07 14:14:36 | [diff] [blame] | 78 | ## When Not To Use It |
| 79 | |
| 80 | This rule is comparatively computationally expensive. If you are pressed for lint |
| 81 | time, or don't think you have an issue with dependency cycles, you may not want |
| 82 | this rule enabled. |
| 83 | |
| 84 | ## Further Reading |
| 85 | |
Tim van der Lippe | a661941 | 2021-09-13 12:28:55 | [diff] [blame] | 86 | - [Original inspiring issue](https://github.com/import-js/eslint-plugin-import/issues/941) |
Tim van der Lippe | fdbd42e | 2020-04-07 14:14:36 | [diff] [blame] | 87 | - Rule to detect that module imports itself: [`no-self-import`] |
Tim van der Lippe | 16aca39 | 2020-11-13 11:37:13 | [diff] [blame] | 88 | - [`import/external-module-folders`] setting |
Tim van der Lippe | fdbd42e | 2020-04-07 14:14:36 | [diff] [blame] | 89 | |
| 90 | [`no-self-import`]: ./no-self-import.md |
Tim van der Lippe | 16aca39 | 2020-11-13 11:37:13 | [diff] [blame] | 91 | |
| 92 | [`import/external-module-folders`]: ../../README.md#importexternal-module-folders |