Background
While preparing the ESLint to Oxlint migration, a batch of violations surfaced that ESLint does not report
today. import/no-cycle is the largest of them by a wide margin: 534 circular imports across 148 files
in src/, all of them real.
The rule has been in our ESLint config for years with maxDepth: '∞', and it reports 0. ESLint's
resolver never resolves the @src/..., @libs/... and @components/... aliases, so it never builds a
module graph and has nothing to check. Oxlint reads tsconfig.json, resolves the aliases, and sees the
graph.
Fixing what the new linter found is a prerequisite for the migration. The day Oxlint becomes a blocking
check, these 534 findings become 534 hard errors, so the cleanup has to land first and on its own schedule.
Cycle path is a symptom, not a work item. Break the cycle it draws and the finding often
survives, now drawing a different cycle through the same import. One row fixed can reappear as another cycle issue re-reported.
The numbers
|
|
| Findings |
534 |
| Files involved |
148, all under src/ |
| Mutually dependent clusters |
6, largest 116 files |
| Import edges inside those clusters |
537 |
| Import edges that must break to reach 0 findings |
54 |
| Shortest and longest cycle |
2 and 39 modules |
Definition of done
- A clean Oxlint run reports 0
import/no-cycle findings.
- No
eslint-disable or oxlint-disable comment is added for import/no-cycle anywhere. A suppressed cycle
is still a cycle and still carries costs.
How to validate numbers
List generated on POC oxlint branch #98027
To reproduce use .oxlintrc.no-cycle.json and run command:
npx oxlint . -c .oxlintrc.no-cycle.json -f json > oxlint-no-cycle-findings.json
Current results:
oxlint-no-cycle-findings.json
Issue Owner
Current Issue Owner: @thelullabyy
Background
While preparing the ESLint to Oxlint migration, a batch of violations surfaced that ESLint does not report
today.
import/no-cycleis the largest of them by a wide margin: 534 circular imports across 148 filesin
src/, all of them real.The rule has been in our ESLint config for years with
maxDepth: '∞', and it reports 0. ESLint'sresolver never resolves the
@src/...,@libs/...and@components/...aliases, so it never builds amodule graph and has nothing to check. Oxlint reads
tsconfig.json, resolves the aliases, and sees thegraph.
Fixing what the new linter found is a prerequisite for the migration. The day Oxlint becomes a blocking
check, these 534 findings become 534 hard errors, so the cleanup has to land first and on its own schedule.
Cycle path is a symptom, not a work item. Break the cycle it draws and the finding often
survives, now drawing a different cycle through the same import. One row fixed can reappear as another cycle issue re-reported.
The numbers
src/Definition of done
import/no-cyclefindings.eslint-disableoroxlint-disablecomment is added forimport/no-cycleanywhere. A suppressed cycleis still a cycle and still carries costs.
How to validate numbers
List generated on POC oxlint branch #98027
To reproduce use .oxlintrc.no-cycle.json and run command:
Current results:
oxlint-no-cycle-findings.json
Issue Owner
Current Issue Owner: @thelullabyy