Articles

Circular dependencies compile cleanly, pass tests, and ship to production. Here are the 3 patterns that create them, what Node.js, webpack, Rollup, and esbuild actually do with them, and how to stop them before they compound.

Circular dependencies accumulate silently in every large JavaScript codebase. Payload has 508, Next.js has 17, Strapi has 5. They bloat your bundle, slow your tests, and cause mysterious undefined errors at runtime that disappear when you add a console.log. Here is why they form and how to find them all.

Math.random() is a PRNG, not a CSPRNG — its outputs are predictable once an attacker recovers the internal state. I found this pattern in a 44K-star open-source codebase generating integration API keys. Here is the attack class, the ESLint rule that catches it, and the one-line fix.

Our import cycle detector reported 0 cycles in a Next.js app with 7 actual cycles. Here's the 3-line cache bug that hid them all — and how to test if your own detector has the same class of failure.

The most-installed security linter on npm flags one safe pattern for every real vulnerability it catches — a 1:1 true-positive-to-false-positive ratio at 27.5% recall. Six plugins benchmarked side-by-side, with the false-positive code samples that train teams to ignore the tool.

I ran 40 real-world vulnerable patterns through 17 ESLint plugins — eslint-plugin-security, SonarJS, Microsoft SDL. The old pinned version crashes on ESLint 9; the current one doesn't crash but still misses SQL injection entirely. Most others miss 60–100%. Here's the reproducible benchmark, re-verified against the current version of every plugin.

Our import-next/no-cycle reported 0 cycles in next.js's 14K-file repo. oxlint reported 17. The same rule on a 33-file subset of the same repo found 5. The bug: a depth-truncated DFS cached files as 'known acyclic' that it had never finished exploring — and the cascade swallowed 245 files. Five lines fixed it. Here is why your AI-generated barrel files make this worse.

700 AI-generated functions. 5 models. The cheapest model leads the aggregate leaderboard — but one model writes clean-scanning JWT code where the flagship is flagged every time, and the 'worst' model fixes 93% of database bugs. The rankings don't tell you any of this.

When AI fixes a security bug, the original finding disappears — but 1 in 3 'fixes' quietly introduced a brand-new vulnerability in a different category. I tested this across 3 remediation rounds with Claude (opus alias, Feb 2026 run) using two approaches — ESLint-guided feedback vs. prompt engineering alone. I call it the Hydra Problem, and it exposes a fundamental limit of 'fix it again' workflows.

A reproducible benchmark: @microsoft/eslint-plugin-sdl (17 rules, Angular/Electron/browser-focused) vs the Interlace security plugins, on one Node fixture. SDL's recommended config catches 5 — frontend hardening is exactly why it's the wrong layer for a Node backend, and exactly the gap your AI assistant ships into.

A reproducible fixture benchmark: eslint-plugin-sonarjs (269 rules) vs the Interlace security plugins on 40 known vulnerabilities. SonarJS is one of the best quality linters in the ecosystem — which is exactly why a green run isn't a clean Node.js security bill. Recall 35%, the 26 it misses, why they survive review, and what happens when Claude and Gemini write them. Result JSON linked.

eslint-plugin-security is the foundational, actively-maintained Node security linter — 14 rules, 2.4M+ weekly downloads. On one fixture of 12 vulnerability classes it caught 21 issues and the domain plugins caught 46. Here's the 25-finding gap, why AI-generated code lives in it, and how to layer both.