src/content/docs/linter/rules/no-import-cycles.mdx
import { Tabs, TabItem } from '@astrojs/starlight/components';
<Tabs> <TabItem label="JavaScript (and super languages)" icon="seti:javascript"> :::note This rule belongs to the project domain. This means that its activation will activate the Biome Scanner to scan the files of your project. Read more about it in the [documentation page](/linter/domains#project) ::: ## Summary - Rule available since: `v2.0.0` - Diagnostic Category: [`lint/suspicious/noImportCycles`](/reference/diagnostics#diagnostic-category) - This rule isn't recommended, so you need to enable it. - This rule doesn't have a fix. - The default severity of this rule is [**warning**](/reference/diagnostics#warning). - This rule belongs to the following domains: - [`project`](/linter/domains#project) - Sources: - Same as [`import/no-cycle`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-cycle.md){
"linter": {
"rules": {
"suspicious": {
"noImportCycles": "error"
}
}
}
}
Prevent import cycles.
This rule warns when a file imports another file that, either directly or indirectly, imports the original file again.
Cycles can lead to symbols that are unexpectedly undefined and are
generally considered poor code hygiene.
If a cycle is detected, it is advised to move code such that imports only go in a single direction, i.e. they don't point "back" to the importing file.
However, files that import themselves are allowed, and the rule won't trigger for these use cases. This allows for encapsulation of functions/variables into a namespace instead of using a static class (triggers noStaticOnlyClass).
:::note This rule is computationally expensive. If you are particularly pressed for lint time, or don't think you have an issue with dependency cycles, you may not want this rule enabled. :::
import { baz } from "./baz.js";
export function foo() {
baz();
}
export function bar() {
console.log("foobar");
}
import { bar } from "./foobar.js";
export function baz() {
bar();
}
import { baz } from "./baz.js";
export function foo() {
baz();
}
export function bar() {
console.log("foobar");
}
import { bar } from "./bar.js";
export function baz() {
bar();
}
export function foo() {
console.log("foobaz");
}
export * as baz from './foobaz.js';
import { baz } from './foobaz.js';
import type { bar } from "./qux.ts";
export type Foo = {
bar: typeof bar;
};
import type { Foo } from "./types.ts";
export function bar(foo: Foo) {
console.log(foo);
}
The rule provides the options described below.
ignoreTypesIgnores type-only imports when finding an import cycle. A type-only import (import type)
will be removed by the compiler, so it cuts an import cycle at runtime. Note that named type
imports (import { type Foo }) aren't considered as type-only because it's not removed by
the compiler if the verbatimModuleSyntax option is enabled. Enabled by default.
{
"linter": {
"rules": {
"suspicious": {
"noImportCycles": {
"options": {
"ignoreTypes": false
}
}
}
}
}
}
import type { bar } from "./qux.ts";
export type Foo = {
bar: typeof bar;
};
import type { Foo } from "./types.ts";
export function bar(foo: Foo) {
console.log(foo);
}