eslint-plugin-import Spends 148s Finding Circular Deps in 5,000 Files. import-next Does It in 2.7s.

The no-cycle rule on 5,000 files: eslint-plugin-import takes 148 seconds; eslint-plugin-import-next takes 2.71 — 54.9x measured, because O(n²) graph traversal became O(n). At 10K files the gap projects past 100x (we stopped measuring eslint-plugin-import at 5K — it was already taking ~2.5 minutes per run). Full numbers, methodology, and a drop-in migration below.

🔄 Drop-in replacement — compatible with the eslint-plugin-import rule set, with faster graph algorithms, CWE/LLM-optimized messages, and fewer false positives/negatives.

TL;DR

The 54.9x is measured; the 10K column is a projection (we stopped running eslint-plugin-import at 5K — it was already ~2.5 minutes). Details below.

Why eslint-plugin-import is Slow

The original eslint-plugin-import uses an O(n²) module resolution algorithm:

1. For each file, parse all imports
2. For each import, resolve the full module path
3. For no-cycle, traverse the entire dependency graph for every file

This creates quadratic complexity. On 5,000 files with interconnected imports, the no-cycle rule alone takes 148 seconds.

How eslint-plugin-import-next Fixes This

We rewrote the core algorithms:

1. Cached module resolution — resolve each path once, cache permanently
2. Incremental graph building — build the dependency graph incrementally, not per-file
3. Cycle detection with Tarjan's algorithm — O(n) instead of O(n²)

Result: 2.71 seconds for the same 5,000 files.

Benchmark 1: Core Rules (9 rules)

Both plugins configured with identical rules:

• no-unresolved, named, namespace, default, export
• no-named-as-default, no-named-as-default-member, no-duplicates, order

Takeaway: Even with basic rules, the performance gap grows with codebase size.

Benchmark 2: Recommended Preset

Using the full recommended configuration from each plugin.

Takeaway: Recommended presets show similar scaling — 5.5x faster at 10K files.

Benchmark 3: no-cycle Rule Only

This is where the difference is massive. The no-cycle rule detects circular dependencies.

*10K Projection Note: 5K→10K doubles the file count, so O(n²) roughly quadruples eslint-plugin-import's time (148.59s × 4 ≈ 600s ≈ 10 minutes) — we didn't run it because 10+ minutes per iteration is impractical. eslint-plugin-import-next is O(n), so its time roughly doubles (2.71s × 2 ≈ 5s). 600 / 5 ≈ 120x — a projection, not a measurement; the measured maximum is the 54.9x at 5K.

Takeaway: If you use no-cycle (and you should), the speedup is 25-100x depending on codebase size.

┌────────────────────────────────────────────────────────────────┐
│ no-cycle Rule: 5,000 files                                     │
├────────────────────────────────────────────────────────────────┤
│ eslint-plugin-import:      148.59s ████████████████████████████│
│ eslint-plugin-import-next:   2.71s █                           │
└────────────────────────────────────────────────────────────────┘

Why no-cycle is Critical

Circular dependencies cause:

• Build failures with tree-shaking
• Runtime bugs with undefined imports
• Memory leaks in bundlers
• Test flakiness from initialization order

Most teams disable no-cycle because it's too slow. With eslint-plugin-import-next, you can finally enable it.

Methodology

Apple-to-apple comparison — full source code

Run It Yourself

git clone https://github.com/ofri-peretz/eslint-benchmark-suite.git
cd eslint-benchmark-suite
npm install
npm run generate:import
npm run benchmark:import
npm run benchmark:import-recommended
npm run benchmark:import-no-cycle

Migration Takes 2 Minutes

# Remove old plugin
npm uninstall eslint-plugin-import

# Install new plugin
npm install --save-dev eslint-plugin-import-next

// eslint.config.mjs — `configs` is a NAMED export (default export is the plugin)
import { configs } from "eslint-plugin-import-next";
export default [configs.recommended];

Compatibility

Links

• 📦 npm: eslint-plugin-import-next
• 📊 Benchmark suite
• 📖 Full rule docs
• 💻 Source on GitHub

⭐ Star on GitHub if you've ever disabled no-cycle because it was too slow to run.

I'm Ofri Peretz, a security engineering leader and the author of the Interlace ESLint ecosystem — domain-specific static analysis for security, reliability, and performance on the Node.js stack.

ofriperetz.dev · LinkedIn · GitHub