Eslint Plugin Node Security

Plugins, configs, resolvers, and tooling for ESLint-driven code quality

This monorepo houses battle-tested ESLint plugins, sharable configs, and supporting utilities that help teams enforce architecture, security, and consistency with actionable, LLM-friendly feedback.

⭐ Star the repo  ·  👀 Watch releases  ·  📨 Follow the writeups  ·  📊 Live metrics

_{If these plugins caught a real bug for you, a star is the signal that keeps the ecosystem maintained.}

---

Philosophy

Interlace fosters strength through integration. We interlace security directly into your workflow, creating a resilient fabric of code. Tools should guide rather than gatekeep, providing educational feedback that strengthens developers.

Why an independent ecosystem? 🚀 Ship fast without upstream bureaucracy • 🤖 AI-optimized messages (CWE, OWASP, fixes) • ⚡ Unified codebase for performance • 🏗️ Consistent patterns across all plugins • 📚 Educational "why" explanations • 🔧 Modern ESLint flat config (v8 / v9 / v10)

All rules are clean-room implementations — familiar naming, better engineering.

The deeper case:

• cicd-impact/value-philosophy.md — what value is (Buffett, Munger, software-industry voices), the two ruling systems (capitalism + humanism), why static code analysis is hard to measure, and the unbroken chain from human incentives down to a single ESLint rule.
• cicd-impact/philosophy.md — how CI/CD friction expresses itself along three axes (money, velocity, deliverability) plus the investor frame, and where a faster / better lint suite plugs in to lower the bill on all four.
• cicd-impact/ — a forkable calculator that turns the philosophy into a $/CI minute figure for any GitHub Actions repo.

---

📦 Available Packages

Independently versioned ESLint-focused packages: plugins, configs, and supporting utilities.

Security Plugins

Package	Description	Downloads
eslint-plugin-secure-coding	Comprehensive security rules
eslint-plugin-node-security	Node.js core-module security
eslint-plugin-jwt	JWT security best practices
eslint-plugin-pg	PostgreSQL security
eslint-plugin-browser-security	Browser/frontend security
eslint-plugin-express-security	Express.js security
eslint-plugin-nestjs-security	NestJS security
eslint-plugin-lambda-security	AWS Lambda security
eslint-plugin-vercel-ai-security	Vercel AI SDK security

Code Quality & Architecture Plugins

Package	Description	Downloads
eslint-plugin-modularity	Structural integrity and DDD patterns
eslint-plugin-modernization	ESNext migration and syntax evolution
eslint-plugin-maintainability	Cognitive load and clean code
eslint-plugin-reliability	Runtime stability and error safety
eslint-plugin-operability	Production readiness and resource health
eslint-plugin-conventions	Team-specific habits and styles
eslint-plugin-import-next	High-fidelity dependency graph analysis
eslint-plugin-react-features	React best practices and optimization
eslint-plugin-react-a11y	React accessibility and WCAG compliance

Supporting Tools

Package	Description	Downloads
@interlace/eslint-devkit	Build your own team-specific ESLint rules

---

🎯 Why This Repo?

ESLint is the backbone for keeping large codebases healthy. These packages target the real problems teams face at scale: inconsistent patterns, architectural drift, security gaps, and slow onboarding. The plugins deliver guardrails plus explanations tuned for humans and LLMs alike.

Problems We Solve

Challenge	How these plugins help
🏗️ Architectural Drift	Enforce module boundaries and prevent circular dependencies automatically
🔒 Security Blind Spots	Catch hardcoded secrets, injection vulnerabilities, and unsafe patterns early
📚 Inconsistent Patterns	Codify team conventions into automated rules that teach while they enforce
🤖 AI-Assisted Development	LLM-optimized error messages that AI assistants can actually understand and fix
🚀 Developer Onboarding	New team members learn the codebase through guardrails, not just documentation

Design Principles

• Battle-Tested: Every tool solves a real problem encountered in production
• Actionable Feedback: Error messages explain the "why" and show how to fix
• LLM-Ready: Optimized for modern AI-assisted development workflows
• Zero Configuration Burden: Sensible defaults with escape hatches when needed

---

🛟 ESLint Support Matrix

Last data refresh: 2026-05-09 (window: 2026-05-02 → 2026-05-09, source: npm registry)

ESLint Major	Weekly Downloads	Share	Status
v10	11.8M	9.24%	✅ Supported (forward-looking)
v9	76.9M	60.4%	✅ Supported (current default)
v8	30.9M	24.3%	✅ Supported (legacy active)
v7 and older	7.7M	6.1%	❌ Unsupported (EOL)

All published packages declare "eslint": "^8.0.0 || ^9.0.0 || ^10.0.0" as a peer dependency.

Node.js compatibility

Node.js	Status	Notes
24.x	✅ Active development	Repo's engines.node pin; what CI runs against
22.x LTS	✅ Supported	Recommended for production users
20.x LTS	✅ Supported	Long-term-stable baseline
18.x	✅ Supported (minimum)	Lowest declared engines.node across published packages
≤ 17	❌ Unsupported	EOL upstream

The 18.x floor is set by every package's engines.node: ">=18.0.0". Bumping the floor follows the same gate logic as ESLint majors — a deliberate decision tracked in docs/ESLINT_VERSION_SUPPORT.md.

Our baseline for supporting a major version

A major is supported when either:

1. 20% gate — it has ≥20% of weekly downloads on npm (v8 and v9 today), OR
2. Forward-looking exception — it is the next major after a currently-supported version (v10 today, the future of v9). We ship support pre-emptively so users can upgrade ahead of the curve, not behind it.

A supported major is in our peerDependencies, our benchmark matrix, and our CI matrix. Versions are dropped only after two consecutive refreshes below the gate AND a successor that is itself supported.

The data above can be re-fetched at any time via npm run stats:eslint-versions (script). Full policy: docs/ESLINT_VERSION_SUPPORT.md.

---

🎯 How We Measure Quality (FP / FN / TP / TN)

Every ESLint finding is one of four things — and we track all four, per rule, per CWE, per OSS repo:

	Code IS vulnerable / problematic	Code is safe / clean
Rule fires	TP — true positive (signal)	FP — false positive (noise)
Rule silent	FN — false negative (miss)	TN — true negative (correct quiet)

Three rates fall out of those counts:

• Precision = TP / (TP + FP) — of the things we flag, what fraction are real?
• Recall = TP / (TP + FN) — of the things we should flag, what fraction did we catch?
• F1 = harmonic mean of precision and recall — one number that punishes either being bad.

Recall first, precision second. A missed CWE is worse than a noisy rule, and we don't regress recall to chase FPs. Today's headline: 100% recall on Arena and Juliet with 97.6% precision (CLAIMS.md holds every claim with its evidence file).

The full philosophy — synthetic vs. wild corpora, severity-classification policy, multi-rater agreement (Cohen's κ), and the ten principles — lives in benchmarks/README.md.

---

⚡ Performance — Cold cache vs. Warm cache

Latency is measured for every supported rule on real OSS repos (next.js, supabase, lodash, vercel-ai, payload, shadcn-ui, three.js…) with both cold (--no-cache) and warm (--cache --cache-location <stable>, second consecutive run) profiles. From the latest flagship scorecard (ESLint 9.39.4 + oxlint 1.63.0 + Node 24.13.0):

Stack	Median cold	Median warm	Δ	Cache benefit
Ours (ESLint)	10,095 ms	443 ms	9,652 ms	96%
Competitor (ESLint)	4,697 ms	500 ms	4,197 ms	89%
oxlint native	168 ms	83 ms	85 ms	51%

The actionable takeaway: ESLint cache cuts ~96% of our run time on the second pass. If you haven't enabled it, you're paying 22× more per lint run than necessary:

eslint --cache --cache-location node_modules/.cache/eslint .

How we benchmark our benchmarks

The benchmark itself is versioned and reproducible — measuring the right thing matters as much as measuring it well:

• Cold definition: eslint --no-cache (full AST parse, full rule pass, full resolver work)
• Warm definition: eslint --cache --cache-location <stable> after a prior cold run (cache present, mtime+size hash determines reuse)
• Cache-hit verification: oxlint caches implicitly via file-mtime + content hash; the warm column is its second consecutive run
• Single-shot per row; median-of-N tracked in the corpus but not yet headlined (TODO: --repeat=N)
• Frozen corpus per bench version (npm run ilb:corpus-integrity is a CI gate — silent commit drift in the corpus invalidates prior numbers)
• Append-only history in benchmark-results/history.ndjson so any number can be plotted across time
• Cross-version matrix runs the suite against ESLint v8/v9/v10 on every PR (eslint-version-matrix.yml)

Run locally: npm run ilb:scorecard. Result schema, vocabulary contract (cost / effectiveness / latency), and the full ten principles are in benchmarks/README.md.

---

👥 Who Is This For?

Role	How these packages help
Tech Leads	Enforce architectural decisions automatically instead of during code review
Platform Teams	Provide guardrails that scale across multiple teams and repositories
Security Engineers	Catch vulnerabilities at development time, not in production
Engineering Managers	Reduce onboarding time and maintain consistency as teams grow
Senior Engineers	Codify institutional knowledge into automated tooling

---

🤝 Contributing

We welcome contributions! If you've faced a problem in your organization that could benefit others, we'd love to hear about it.

• Have an idea? Start a discussion
• Found a bug? Open an issue
• Want to contribute code? See our Contributing Guide (planned)

---

🔗 Get Started

Resource	Description
📦 npm packages	Install and start using the tools
💬 GitHub Discussions	Ask questions and share ideas
🐛 Report Issues	Found a bug? Let us know

---

📄 License

MIT © Ofri Peretz — See LICENSE for details.

---

Made with ❤️ from lessons learned in the trenches