Scale Forem

BullMQ + Node.js: Replace 50 Cron Jobs with Smart Queues

Кирилл — Fri, 03 Apr 2026 20:12:23 +0000

BullMQ + Node.js: замена 50 cron-задач на умные очереди

BullMQ + Node.js: Замена 50 Cron-задач на Умные Очереди

Введение

В этой статье мы рассмотрим, как заменить 50 cron-��адач на умные очереди с помощью BullMQ и Node.js. Мы погрузимся в преимущества использования очередей сообщений, настройку BullMQ и предоставим практические примеры того, как интегрировать его с Node.js.

Проблема с Cron-задачами

Cron-задачи являются распространенным способом планирования задач в системах Linux. Однако, по мере роста количества задач, управление cron-задачами может стать громоздким. У нас было 50 cron-задач, запущенных в нашей системе, каждая со своей собственной планировкой и логикой. Это привело к:

Трудностям в управлении и масштабировании системы
Увеличению риска ошибок и конфликтов между задачами
Ограниченной видимости выполнения задач и их производительности

Введение в BullMQ

BullMQ — это библиотека Node.js, которая предоставляет про��той и эффективный способ управления очередями сообщений. Она позволяет создавать очереди, добавлять задачи в них и обрабатывать эти задачи в надежном и масштабируемом виде. С помощью BullMQ мы можем заменить наши cron-задачи на умные очереди, которые предоставляют:

Лучшую масштабируемость и производительность
Улучшенную видимость выполнения задач и их производительности
Упрощенное управление и обработку ошибок

Настройка BullMQ

Чтобы начать работу с BullMQ, необходимо установить пакет bull:

npm install bull

Далее, создайте новый файл для своей очереди, например, queue.ts:

import { Queue } from 'bull';

const queue = new Queue('myQueue', {
  redis: {
    host: 'localhost',
    port: 6379,
  },
});

export default queue;

В этом примере мы создаем новую очередь с именем myQueue, которая использует Redis в качестве движка хранения.

Добавление Задач в Очередь

Чтобы добавить задачу в очередь, можно использовать метод add:

import queue from './queue';

queue.add({
  name: 'myJob',
  data: {
    foo: 'bar',
  },
});

В этом примере мы добавляем новую задачу в очередь с именем myJob и некоторыми образцами данных.

Обработка Задач

Чтобы обработать задачи, необходимо создать рабочий процесс, который потребляет задачи из очереди:

import queue from './queue';

queue.process(async (job) => {
  console.log(`Обработка задачи ${job.id} с данными: ${JSON.stringify(job.data)}`);
  // Обработка задачи здесь
});

В этом примере мы создаем рабочий процесс, который потребляет задачи из очереди и выводит некоторую информацию о задаче.

Замена Cron-задач на Умные Очереди

Чтобы заменить наши 50 cron-задач на умные очереди, мы можем создать одну очередь, которая обрабатывает все задачи. Мы можем затем добавлять задачи в очередь с разными планировками и приоритетами.

Например, мы можем создать задачу, которая запускается каждый час:

import queue from './queue';

queue.add({
  name: 'hourlyJob',
  data: {
    foo: 'bar',
  },
  repeat: {
    cron: '0 * * * *',
  },
});

В этом примере мы добавляем новую задачу в очередь, которая запускается каждый час.

Мы также можем создать задачу, которая запускается каждый день в 2 часа ночи:

import queue from './queue';

queue.add({
  name: 'dailyJob',
  data: {
    foo: 'bar',
  },
  repeat: {
    cron: '0 2 * * *',
  },
});

В этом примере мы добавляем новую задачу в очередь, которая запускается каждый день в 2 часа ночи.

Преимущества Использования BullMQ

Использование BullMQ предоставляет несколько преимуществ, включая:

Улучшенную масштабируемость и производительность
Упрощенное управление и обработку ошибок
Лучшую видимость выполнения задач и их производительности

Заключение

В этой статье мы рассмотрели, как заменить 50 cron-задач на умные очереди с помощью BullMQ и Node.js. Мы погрузились в преимущества использования очередей сообщений, настройку BullMQ и предоставили практические примеры того, как интегрировать его с Node.js.

Если интересно — подписывайтесь, будет ещё.

I Built Boreal UI — An Accessibility-First Component Library for React and Next.js

Davin Chiupka — Fri, 03 Apr 2026 20:10:37 +0000

During my two semesters of project management classes in college, we had roughly four months to come up with an idea, build an MVP, and complete the full project for our final grade. It was a lot to juggle and sometimes a little chaotic, but it taught me a lot about how real product development works. We had to think about user stories, planning, databases, back-end logic, wireframes, and front-end implementation all at the same time.

Even with all of that, I was always most drawn to the front-end side. I’ve always enjoyed the creative side of development, and one of my favorite parts of the process was seeing wireframes turn into a real, usable interface. The problem was that every time we built a new application, I wanted to create the UI from scratch.

A lot of the existing options just did not click with me. Many UI libraries felt too familiar, a little too corporate for my taste, or harder to shape into exactly what I wanted. I often felt like I was either stuck with someone else’s visual style or spending too much time fighting the framework to make it feel like my own.

So, after those classes ended, I made the very ambitious, and maybe slightly irrational, decision to build my own UI library from the ground up. Since I already loved building with React, I decided to make it work for both React Core and Next.js.

That became Boreal UI.

Boreal UI has been the result of a lot of learning, trial and error, and time spent building and rebuilding components. The core idea behind it was simple: UI libraries should help developers create, not force them into a default look and feel. Components should be flexible enough to support creativity rather than limit it.

That is why Boreal UI puts such a strong focus on customization. One of my favorite features is the ability to define project-wide defaults, so instead of styling every component over and over, the whole app can feel consistent from the start.

It also includes built-in color schemes, including both light and dark themes, and you can register your own custom schemes as well. That means if you want your app to reflect your own branding or style, you can do that without a ton of extra setup.

Accessibility was just as important to me. During my co-op at Fanshawe’s OER Studio, I worked on open educational resources like digital textbooks and interactive learning activities, and accessibility was always a major priority. The goal was to make sure those materials could be used by anyone without barriers, and I wanted that same thinking to carry into this project. Boreal UI was built to support websites that are easier for everyone to use.

So really, Boreal UI is my attempt to make building websites faster, more accessible, and more expressive at the same time. I wanted something practical, but also something that still leaves room for creativity.

If you want to check out Boreal UI, you can find the full documentation at borealui.ca or install it with npm install boreal-ui.

I’d love to hear what you think. Try it out, build something with it, push it around a bit, and if you manage to break it, definitely let me know.

Thanks for reading.

The Dependency Firewall: Isolate AI Changes So One Bad Prompt Can't Break Your Build

Nova Elvaris — Fri, 03 Apr 2026 20:08:28 +0000

One bad AI-generated change shouldn't cascade through your entire codebase. But without guardrails, that's exactly what happens.

I call this the Dependency Firewall — a pattern borrowed from SRE blast-radius thinking, applied to AI-assisted coding.

The Problem

You ask your AI assistant to refactor a utility function. It "helpfully" updates the function signature, changes the return type, and touches three callers. Your tests pass locally — but a downstream service that imports that module breaks in production.

The root cause: no blast-radius boundary between AI-generated changes and the rest of your system.

The Pattern

Before any AI-assisted code change, define a change boundary:

## Change Boundary
- Files allowed to change: src/utils/parser.ts
- Files NOT allowed to change: anything importing parser.ts
- Interface contract: parseInput(raw: string) => ParsedResult (unchanged)
- Test gate: all existing tests must pass without modification

Then include this in your prompt:

You may ONLY modify src/utils/parser.ts.
Do NOT change the function signature of parseInput().
Do NOT modify any importing files.
If the change requires signature changes, STOP and explain why.

Why It Works

Blast radius is explicit — you decide what can change before the AI touches anything
Interface contracts are frozen — the AI can refactor internals but can't break callers
Test gates catch drift — if existing tests need changes, that's a red flag, not a feature

A Real Example

I needed to optimize a token-counting function. Without the firewall, my assistant rewrote it, changed the return type from number to { count: number; truncated: boolean }, and updated four callers. Three of those callers were in a shared library used by two other services.

With the firewall prompt, the assistant optimized the internals, kept the signature identical, and added the truncated field as a separate function. Zero blast radius.

The Checklist

Before every AI code change:

[ ] List files allowed to change
[ ] List frozen interfaces/signatures
[ ] Define test gate (which tests must pass unchanged)
[ ] Add boundary to your prompt
[ ] Review the diff against your boundary before merging

When to Skip It

For greenfield code with no callers yet, you don't need a firewall. But the moment something has dependents — even one — define the boundary.

The five minutes you spend writing a change boundary will save you the hour you'd spend debugging a cascade failure. Every time.

My RAG Feature Pipeline Started Simple… Then Got Personal 🤖📦

golden Star — Fri, 03 Apr 2026 20:04:12 +0000

I built a RAG feature pipeline thinking it would be clean:

“Just take raw data, process it, generate embeddings, store in vector DB… done.”

Yes.

“Done.”

Step 1: Clean the Data (aka emotional damage)

I opened my dataset.

It had:

broken text
random HTML
sentences that started in 2012 and ended in 2026

So I cleaned it.

Then cleaned it again.

Then realized:

“Cleaning data is just debugging… but slower.”

Step 2: Chunking (aka cutting things you don’t understand)

Now I had to split text into chunks.

Too big → model confused
Too small → model useless

So I picked a size and said:

“Looks reasonable.”

(It wasn’t.)

Step 3: Embeddings (aka turning words into math magic)

I converted text into vectors.

Thousands of them.

They looked like:

[0.123, -0.928, 0.44, …]

I nodded like I understood.

I did not.

Step 4: Store in Vector DB

Everything went into the database.

Fast. Scalable. Beautiful.

Until I queried it.

I asked:

“Find relevant context.”

It returned:

Something… technically related.

Emotionally unrelated.

Final Lesson

A RAG pipeline is not:

just cleaning
just chunking
just embedding

It’s:

making sure your future self doesn’t question your life choices.

Truth

If your RAG output is bad…

It’s not the model.

It’s your pipeline.

And that’s when I realized:

I didn’t build a feature pipeline.

I built a system that politely reflects my bad decisions… at scale.

Why I built a SQLite workbench in bash

Allen McCabe — Fri, 03 Apr 2026 20:03:59 +0000

You SSH into a server. The SQLite database is right there — you can see it in the filesystem.
Every GUI tool you own stops working. TablePlus, DB Browser, Beekeeper — all of them need a local connection. sqlite3 is available, but it's raw SQL with no browsing. litecli is read-biased and still needs installing.
You need to look at some rows, update a field, check an index. You end up writing SELECT statements into a CLI, copying output into a notes file, writing UPDATE statements by hand.
There's a better way.

The build

ShellQL is built on shellframe — a TUI framework I wrote in bash. shellframe handles screen management, keyboard routing, dirty-region rendering, and component lifecycle. Writing a new application on top of it is closer to writing a React app than writing a bash script.

The surprising parts:

Mouse support in bash is real, and it's not that hard once you understand xterm escape sequences
SQLite's .schema output is parseable enough to build a schema browser without any external tools
Tab management (multiple tables open simultaneously) required rethinking shellframe's focus model

The SSH use case

This is the thing that makes ShellQL different from every other SQLite tool.

If the machine has bash and sqlite3, ShellQL runs. That means:

Production servers (read and write, with care)
Docker containers
CI environments for debugging test databases
Remote dev boxes

No GUI install. No port forwarding. No pulling the file to your laptop and pushing it back.

SSH in, run shql /var/app/production.db, browse your data.

Full CRUD

Most TUI database tools are read-only. ShellQL isn't.

The record editor is a schema-aware form overlay. It shows column types and NOT NULL constraints. Tab through fields, edit values, press Enter to submit. Insert new rows the same way.

Table creation uses a SQL query tab preloaded with a CREATE TABLE template — you get full DDL control without a rigid GUI wizard.

Mouse support

This one surprised people in early demos. Most bash tools are keyboard-only by design. ShellQL supports both.

Keyboard navigation is fast once you learn it — the keybindings are shown at the bottom of every screen. Mouse works for everything else: clicking into tables, scrolling rows, selecting records.

This matters for adoption. Not everyone who SSHes into a server is a power user.

Install and try it

brew install fissible/tap/shellql
shql my.db

Tool page: https://fissible.dev/tools/shellql
GitHub: https://github.com/fissible/shellql

Can We Ever Achieve a Utopian Release?

Isabelle M. — Fri, 03 Apr 2026 20:03:50 +0000

What if releases didn't feel stressful?

Not just "we followed the process" safe, but actually safe. The kind where you don't hesitate before deploying, don't keep checking Slack afterward, and don't quietly wonder what might go wrong this time.

Because if we're honest, most of us recognize a very specific moment.

A release finishes. Everything is deployed.
Dashboards are open. People are watching.

Slack goes a bit quieter than usual.

No one says anything, but the same thought is there in the background:

Let's see what breaks.

We spend a lot of time trying to improve releases.

We add better pipelines. We introduce more automation. We create more environments.

On paper, things look more mature over time.
And yet, the feeling often doesn't change.

That's because the real issue is not only technical.

Releases don't feel risky because they fail. They feel risky because they are unpredictable.

The Myth of the "Perfect Release"

There is a quiet assumption behind many teams: If everything is done correctly, nothing will go wrong.

It sounds reasonable. It's also not true.

Systems are complex. Dependencies are not always visible. Production behaves differently. And people make decisions under pressure.

You don't get perfect releases. You get managed risk.

Where Things Actually Go Wrong

Most issues don't come from the places we expect.
They come from small decisions that feel harmless:

"It's a small change"
"Let's include this one as well"
"We don’t need to wait for this"

Each decision makes sense on its own. But they don't exist in isolation.
Over time, they accumulate. And the system becomes harder to reason about.

That's when releases start to feel risky.

Most teams try to solve this with process and tooling.

They define what "done" means.
They rely on automation.
They introduce canary releases.
They build dashboards.

And all of these help. But they also create a dangerous illusion: That if everything looks correct, everything is correct.

In reality:
A ticket can be "done" and still hide assumptions.
Tests can pass and still miss real behavior.
A canary can look healthy at 5% and fail at scale.
Dashboards can show green while something important is broken.

Release problems rarely come from one big mistake. They come from many small ones.

One extra ticket.
One skipped validation.
One assumption left unchecked.

Each decision feels reasonable. Together, they create unpredictability.

What Actually Helps

There's no single fix.
What works is consistency:

Only shipping work that is truly ready
Introducing changes in small steps
Detecting issues early
Recovering quickly and calmly

These are simple ideas. But they require discipline.

Practical Takeaways

If you want to improve your releases, start here:

Define what "release-ready" actually means — and stick to it
Reduce how much you ship at once
Keep your main branch releasable at all times
Monitor a few critical user flows closely after deployment
Make rollback simple and familiar

You don't need to fix everything at once.
Even one improvement can make releases feel more predictable.

Closing Thought

A utopian release is not one where nothing ever goes wrong.
It's one where things can go wrong — and it doesn't turn into chaos.
Where issues are expected, visible, and manageable.
Where releases stop feeling like events and start feeling like routine.

The goal isn't perfect releases.
It's releases you don’t have to be afraid of.

That's probably the closest thing to utopia we get.

PeachBot: Rethinking AI as a Distributed System (Not Another Model)

Swapin Vidya — Fri, 03 Apr 2026 20:03:08 +0000

Most AI today is impressive.
Almost none of it works where it actually matters.

⚠️ The Moment It Breaks

AI demos are easy.

Clean datasets
Stable internet
Unlimited compute

Everything looks great.

Until you move it into the real world:

A rural clinic with unstable connectivity
A wetland ecosystem with noisy sensor data
A farm where conditions change every hour

And suddenly…

The “intelligent system” stops being intelligent.

Not because the model is bad.
Because the architecture is wrong.

The Uncomfortable Truth

Most AI today is built like this:

input → model → output

Or worse:

input → API → LLM → output

This creates systems that are:

Stateless
Centralized
Latency-dependent
Probabilistic

Which means:

They don’t understand systems.
They just predict outputs.

The Shift We’re Making

We stopped asking:

“How do we improve models?”

And started asking:

“What if intelligence isn’t a model at all?”

That question led to this:

signals → state → reasoning → decision → feedback

This is not a pipeline.

It’s a living system.

Enter PeachBot

PeachBot is a biologically-grounded, edge-native intelligence framework.

Not a wrapper.
Not a model.
Not an API layer.

A system.

❌ What We Explicitly Avoided

Let’s be clear:

No LLMs
No API orchestration
No cloud dependency
No hallucinated outputs

Not because they’re bad.

But because they don’t solve real-world system problems.

The Core Idea: Intelligence is State, Not Output

Most AI systems:

Take input
Produce output
Forget everything

PeachBot systems:

Maintain state
Continuously update
Adapt decisions over time

Think:

Less like a chatbot
More like a control system + biological organism

⚙️ Under the Hood (Simplified)

A PeachBot node looks like this:

Real-world signals
    ↓
Structured state
    ↓
Knowledge integration
    ↓
State-based reasoning (SBC)
    ↓
Safety validation
    ↓
Action / alert

And across the system:

Local intelligence → coordination → emergent global behavior

SBC — Synthetic Biological Computation

This is the core shift.

SBC treats intelligence as:

A continuously evolving state machine

Not:

A function call to a model

This enables:

Context-aware reasoning
Continuous adaptation
Deterministic behavior

FILA — Distributed Intelligence Layer

Instead of centralizing everything:

Each node:

Sees a partial view
Learns locally
Shares structured updates (not raw data)

Result:

Privacy-preserving
Scalable
Fault-tolerant

This is closer to:

Distributed systems + biological networks

Why This Actually Matters

Because real-world systems have constraints:

Latency is not optional
Privacy is not negotiable
Connectivity is not guaranteed

And most AI ignores all three.

Where This Is Being Used

This isn’t theoretical.

🏥 Clinical intelligence systems
🌊 Environmental monitoring (live deployments)
🌾 Precision agriculture
🧬 Biological modeling

These are environments where:

“Almost working” = failing.

The Bigger Realization

We didn’t just build a new system.

We realized something uncomfortable:

AI is being treated as a feature.
It should be treated as infrastructure.

This Is an Open System

We’re building this as a modular ecosystem:

👉https://github.com/peachbotAI

Core layers:

SBC (state-centric computation)
Knowledge graphs
Edge runtime
FILA coordination
Deployment stack

We Need Builders (Not Just Users)

If this resonates, you’re probably not here for tutorials.

You’re here to build.

Where You Can Contribute

We’re actively looking for people interested in:

Systems & Infrastructure

Distributed systems
Protocol design
Edge orchestration

Intelligence Layer

Knowledge graphs
Hybrid reasoning systems
Graph-based models (GNNs)

Engineering

Embedded / edge systems
Performance optimization
Real-time pipelines

Safety & Validation

Deterministic validation layers
Policy enforcement
Risk systems

Who This Is For

Engineers tired of building wrappers
Researchers questioning model-centric AI
Builders interested in real-world systems

What We Want Feedback On

We’re still early.

We’d love input on:

SBC as a computation paradigm
FILA as a distributed cognition model
Real-world deployment constraints
Developer experience

🔗 Dive Deeper

👉 Full blog:
https://peachbot.in/blogs/peachbot-the-future-of-edge-ai-biologically-grounded-intelligence-at-the-source

👉 GitHub:
https://github.com/peachbotAI

Final Thought

We don’t need bigger models.

We need better systems.

Not AI that talks.
But AI that operates.

24 JavaScript Code Analysis Tools You Should Know

Rahul Singh — Fri, 03 Apr 2026 20:00:00 +0000

Why JavaScript code analysis matters

JavaScript is the most widely used programming language in the world, powering everything from simple landing pages to complex distributed systems running on Node.js and Deno. It is also one of the most permissive. The language happily lets you compare a string to an array, access properties on undefined, mutate global state from anywhere, and silently coerce types in ways that produce runtime bugs invisible to the naked eye.

This permissiveness is why JavaScript code analysis is not optional - it is essential. Unlike statically typed languages where the compiler catches type mismatches and missing imports before your code ever runs, JavaScript defers almost everything to runtime. A typo in a variable name does not fail to compile. A function that sometimes returns a number and sometimes returns null does not raise an error. A missing await on a Promise does not crash your build.

Static analysis tools fill this gap. They read your code without executing it and flag problems that would otherwise surface as production bugs, security vulnerabilities, or performance regressions. The JavaScript analysis ecosystem has matured dramatically: in 2026, you can lint, format, bundle-analyze, security-scan, and AI-review your code with tools that range from zero-config formatters to enterprise SAST platforms.

This guide covers 24 tools across six categories. Whether you are a solo developer setting up a side project or an engineering lead standardizing tooling for a 200-person team, you will find the right combination here.

Comparison table: all 24 tools at a glance

#	Tool	Category	Pricing	Languages	IDE Support
1	ESLint	Linter	Free (OSS)	JS, TS, JSX, TSX	VS Code, JetBrains, Vim, Neovim
2	Biome	Linter + Formatter	Free (OSS)	JS, TS, JSX, TSX, JSON, CSS	VS Code, JetBrains, Neovim
3	oxlint	Linter	Free (OSS)	JS, TS, JSX, TSX	VS Code (via extension)
4	typescript-eslint	Linter (TS plugin)	Free (OSS)	TypeScript	Via ESLint IDE support
5	Standard	Linter	Free (OSS)	JS, TS	VS Code
6	XO	Linter	Free (OSS)	JS, TS	VS Code, Vim
7	Prettier	Formatter	Free (OSS)	JS, TS, HTML, CSS, JSON, MD, + more	VS Code, JetBrains, Vim, Neovim
8	dprint	Formatter	Free (OSS)	JS, TS, JSON, MD, HTML, CSS	VS Code
9	Biome Formatter	Formatter	Free (OSS)	JS, TS, JSX, TSX, JSON, CSS	VS Code, JetBrains, Neovim
10	webpack-bundle-analyzer	Bundler Analyzer	Free (OSS)	Any (webpack)	N/A (browser-based)
11	source-map-explorer	Bundler Analyzer	Free (OSS)	Any (source maps)	N/A (CLI + browser)
12	bundlephobia	Bundler Analyzer	Free (web)	npm packages	N/A (web-based)
13	Semgrep	Security Scanner	Free / $35/contributor/mo	30+ including JS, TS	VS Code, JetBrains
14	Snyk Code	Security Scanner	Free (limited) / $25/dev/mo	19+ including JS, TS	VS Code, JetBrains, Visual Studio
15	npm audit	Security Scanner	Free (built-in)	npm packages	N/A (CLI)
16	Socket	Security Scanner	Free (OSS) / paid plans	npm, PyPI	GitHub app
17	SonarQube	Code Quality Platform	Free (Community) / ~$2,500/yr	35+ including JS, TS	VS Code (SonarLint), JetBrains
18	CodeClimate	Code Quality Platform	Free (OSS) / $600+/mo	22+ including JS, TS	N/A (CI-based)
19	DeepSource	Code Quality Platform	Free (individual) / $12/user/mo	16 including JS, TS	VS Code
20	Codacy	Code Quality Platform	Free (limited) / $15/user/mo	49 including JS, TS	VS Code (AI Guardrails)
21	CodeRabbit	AI Code Reviewer	Free (unlimited) / $24/user/mo	30+ including JS, TS	GitHub, GitLab, Azure DevOps, Bitbucket
22	CodeAnt AI	AI Code Reviewer	Free (Basic) / $24/user/mo	30+ including JS, TS	GitHub, GitLab, Bitbucket, Azure DevOps
23	GitHub Copilot Code Review	AI Code Reviewer	$19/user/mo (with Copilot)	All GitHub languages	GitHub (native)
24	Sourcery	AI Code Reviewer	Free (OSS) / $10/user/mo	JS, TS, Python, Go	GitHub, GitLab, VS Code

Linters

Linters are the foundation of any JavaScript code analysis pipeline. They parse your source code into an abstract syntax tree and check it against a set of rules that catch bugs, enforce coding conventions, and prevent anti-patterns. Every JavaScript project should have a linter. The only question is which one.

1. ESLint - The industry standard

ESLint is the most widely used JavaScript linter, with over 30 million weekly downloads on npm and an ecosystem of thousands of plugins. If you have worked on a JavaScript project in the last decade, you have used ESLint. It remains the default choice in 2026, though the landscape around it has changed significantly.

What changed with v9. ESLint v9, released in 2024, introduced the flat config system - a single eslint.config.js file that replaces the old .eslintrc.* cascade. The flat config is simpler, more predictable, and eliminates the confusion of config inheritance across nested directories. The migration from legacy config to flat config is the biggest thing teams need to handle, and the eslint.org migration guide covers it well.

// eslint.config.js (flat config)

export default [
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    rules: {
      "no-unused-vars": "error",
      "no-console": "warn",
      "prefer-const": "error",
    },
  },
  {
    ignores: ["dist/", "node_modules/", "*.config.js"],
  },
];

Key features. Over 200 built-in rules. Thousands of community plugins covering React (eslint-plugin-react, eslint-plugin-react-hooks), accessibility (eslint-plugin-jsx-a11y), import management (eslint-plugin-import), and framework-specific patterns. Autofix support for many rules. The --fix flag resolves fixable issues automatically on save or in CI.

Pricing. Free and open source under MIT license.

When to use it. ESLint is the right choice for any project that needs extensive customization, has an existing ESLint configuration, or relies on framework-specific plugins. If your project uses React, Vue, Svelte, Angular, or any major framework, the ESLint plugin ecosystem is unmatched.

2. Biome - The Rust-powered successor to Rome

Biome is the community fork and successor to Rome, the ambitious all-in-one JavaScript toolchain project. Written in Rust, Biome combines linting and formatting into a single tool that runs 20-35x faster than ESLint on most codebases. It has rapidly grown from experimental to production-ready, and in 2026 it is the strongest challenger to the ESLint + Prettier combination.

What makes it fast. Biome parses your code once and runs both lint rules and formatting in a single pass. ESLint and Prettier each parse your code separately, which means the ESLint + Prettier combo parses every file twice. Biome's Rust implementation also avoids the startup overhead of Node.js. On a 100,000-line codebase, Biome typically completes in 200-500ms where ESLint alone takes 8-15 seconds.

// biome.json
{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "complexity": {
        "noForEach": "warn"
      },
      "suspicious": {
        "noExplicitAny": "error"
      }
    }
  },
  "formatter": {
    "indentStyle": "space",
    "indentWidth": 2
  }
}

Key features. Over 270 lint rules with strong TypeScript, React, and accessibility coverage. Built-in formatter that is 97%+ compatible with Prettier output. Import sorting. JSON and CSS support. Zero configuration needed for most projects - npx @biomejs/biome init generates a sensible default config.

Pricing. Free and open source under MIT license.

When to use it. Biome is the best choice for new projects that want fast linting and formatting without managing two tools. For existing projects with complex ESLint configurations, migration effort depends on how many ESLint plugins you rely on - Biome covers the most common rules but does not replicate every niche plugin.

3. oxlint - The fastest pure linter

oxlint is part of the Oxidation Compiler (oxc) project, a collection of Rust-based JavaScript tools built for raw speed. While Biome aims to be an all-in-one toolchain, oxlint focuses exclusively on linting and pushes performance to the extreme. It is designed to complement ESLint, not replace it.

How fast is it. oxlint is 50-100x faster than ESLint on benchmarks. On a large monorepo, oxlint can complete a full lint pass in under 100ms. This speed makes it practical to run on every keystroke in the IDE without any perceptible delay.

Key features. Over 400 rules ported from ESLint, typescript-eslint, eslint-plugin-react, eslint-plugin-jest, and eslint-plugin-import. Cross-file analysis support. Automatic detection of existing ESLint configs to avoid duplicate warnings. Designed to run alongside ESLint - oxlint handles the rules it supports, and ESLint handles the rest.

# Run oxlint on your project
npx oxlint@latest

# With specific rules
npx oxlint@latest --deny-warnings -D correctness

Pricing. Free and open source under MIT license.

When to use it. oxlint is ideal as a fast first-pass linter that catches the most common issues instantly, with ESLint running behind it for framework-specific rules that oxlint does not yet cover. As the rule library grows, it may become a standalone ESLint replacement for some projects.

4. typescript-eslint - Type-aware linting for TypeScript

typescript-eslint is the official ESLint plugin for TypeScript. It bridges ESLint's rule-based analysis with TypeScript's type system, enabling lint rules that reason about types - something ESLint alone cannot do.

Why type-aware rules matter. Standard ESLint rules operate on the abstract syntax tree without understanding types. They can tell you that a variable is unused, but they cannot tell you that a function returns Promise<string> and you forgot to await it. Type-aware rules from typescript-eslint use the TypeScript compiler's type information to catch this class of bugs.

// eslint.config.js

export default tseslint.config(
  tseslint.configs.recommendedTypeChecked,
  {
    languageOptions: {
      parserOptions: {
        projectService: true,
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
  {
    rules: {
      "@typescript-eslint/no-floating-promises": "error",
      "@typescript-eslint/no-misused-promises": "error",
      "@typescript-eslint/await-thenable": "error",
      "@typescript-eslint/no-unnecessary-type-assertion": "warn",
    },
  }
);

Key features. Over 100 TypeScript-specific rules. Type-aware rules that catch floating promises, misused async functions, unnecessary type assertions, and unsafe any usage. Full compatibility with ESLint's plugin ecosystem. The recommendedTypeChecked config provides a battle-tested set of rules for most TypeScript projects.

Pricing. Free and open source under MIT license.

When to use it. Every TypeScript project should use typescript-eslint. The type-aware rules catch a category of bugs that no other linter can detect. The performance cost of type-checking is real (slower than non-type-aware linting), but the bugs it catches justify the trade-off.

5. Standard - Zero-config JavaScript style

Standard (standardjs) is a JavaScript linter and style guide that requires zero configuration. You install it, run it, and it enforces a fixed set of rules with no config files, no rule arguments, and no debates about semicolons. The answer is always: no semicolons, 2-space indentation, single quotes.

# Install and run
npm install standard --save-dev
npx standard

# Autofix
npx standard --fix

Key features. Zero config - no .eslintrc, no biome.json, nothing. Catches common bugs alongside style enforcement. Built on ESLint internally, so the underlying analysis is battle-tested. Used by companies like npm, GitHub, and Express.js.

Pricing. Free and open source under MIT license.

When to use it. Standard is best for small projects, prototypes, and open-source libraries where you want consistent style without spending time debating lint rules. If your team has strong opinions about formatting (semicolons, tabs vs spaces), Standard is not for you - the entire point is that these decisions are made for you.

6. XO - Opinionated ESLint wrapper

XO is an opinionated ESLint wrapper maintained by Sindre Sorhus. It bundles ESLint with a curated set of plugins and rules, providing a more opinionated and maintained alternative to Standard. Where Standard is minimal, XO is comprehensive.

# Install and run
npm install xo --save-dev
npx xo

# Autofix
npx xo --fix

Key features. Built-in TypeScript support without additional config. Includes popular plugins like eslint-plugin-unicorn, eslint-plugin-import, and eslint-plugin-n by default. Prettier integration - XO detects Prettier and disables conflicting rules automatically. Opinionated defaults that cover more edge cases than Standard.

Pricing. Free and open source under MIT license.

When to use it. XO is ideal for developers who want a stricter, more comprehensive linting experience than Standard but without the configuration overhead of building their own ESLint config from scratch. It is particularly popular in the Sindre Sorhus ecosystem of npm packages.

Formatters

Formatters handle code style: indentation, line breaks, semicolons, quote style, trailing commas, and every other aspect of how your code looks on screen. Unlike linters, formatters do not find bugs - they make code consistently readable. The modern consensus is to use a separate formatter rather than relying on your linter for stylistic rules.

7. Prettier - The standard code formatter

Prettier is the most widely adopted code formatter in the JavaScript ecosystem. It takes an opinionated approach: you configure a few options (print width, tab width, semicolons, quote style) and Prettier handles everything else. The key design principle is that Prettier's output is deterministic - two developers formatting the same code will always get the same result.

// .prettierrc
{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true
}

Key features. Supports JavaScript, TypeScript, JSX, TSX, CSS, SCSS, HTML, JSON, Markdown, YAML, GraphQL, and more. Deterministic output - eliminates style debates in code review. Integrates with every major editor and CI system. The --check flag validates formatting in CI without modifying files. Over 40 million weekly npm downloads.

Pricing. Free and open source under MIT license.

When to use it. Prettier is the right formatter for any team that wants to eliminate formatting discussions from code reviews. If you use ESLint, pair Prettier with eslint-config-prettier to disable ESLint's formatting rules and let Prettier handle style. If you use Biome, its built-in formatter replaces Prettier.

8. dprint - The Rust-based Prettier alternative

dprint is a code formatter written in Rust that offers Prettier-like formatting with significantly better performance. It formats JavaScript, TypeScript, JSON, Markdown, HTML, and CSS with configurable rules and a plugin architecture.

// dprint.json
{
  "typescript": {
    "quoteStyle": "preferSingle",
    "semiColons": "always",
    "trailingCommas": "onlyMultiLine",
    "indentWidth": 2
  },
  "json": {},
  "markdown": {},
  "plugins": [
    "https://plugins.dprint.dev/typescript-0.93.3.wasm",
    "https://plugins.dprint.dev/json-0.19.4.wasm",
    "https://plugins.dprint.dev/markdown-0.17.8.wasm"
  ]
}

Key features. 10-30x faster than Prettier on most codebases. Plugin-based architecture - plugins are WebAssembly binaries that run in a sandboxed environment. More configuration options than Prettier for teams that want fine-grained control. Incremental formatting - only reformats changed lines.

Pricing. Free and open source under MIT license.

When to use it. dprint is the right choice for teams that find Prettier too slow (common in large monorepos) or too opinionated (Prettier intentionally limits configuration options). The plugin architecture means you can mix and match formatters for different file types.

9. Biome Formatter - Built into Biome, Prettier-compatible

Biome's built-in formatter is 97%+ compatible with Prettier's output, making it a drop-in replacement for most projects. Since it runs alongside Biome's linter in the same pass, you get both linting and formatting from a single tool invocation.

# Format files with Biome
npx @biomejs/biome format --write ./src

# Check formatting without modifying (CI mode)
npx @biomejs/biome format ./src

Key features. Near-identical output to Prettier. Runs in the same pass as linting - no double-parsing overhead. Configured in the same biome.json file as lint rules. Supports JavaScript, TypeScript, JSX, TSX, JSON, and CSS. The biome migrate prettier command auto-converts a .prettierrc to biome.json settings.

Pricing. Free and open source under MIT license.

When to use it. If you are already using Biome for linting, use its built-in formatter instead of adding Prettier as a separate tool. The single-tool approach is faster and simpler. If you are on ESLint and considering a switch, the Prettier-compatible output means the migration will not cause massive diffs in your codebase.

Bundler analyzers

JavaScript applications are shipped as bundles - compiled, minified files that combine your source code with dependencies. Bundle size directly impacts page load times, user experience, and Core Web Vitals scores. Bundler analyzers help you understand what is in your bundles, how big each dependency is, and where to cut bloat.

10. webpack-bundle-analyzer - Interactive treemap visualization

webpack-bundle-analyzer generates an interactive zoomable treemap of your webpack bundles. Each rectangle represents a module, sized proportionally to its contribution to the bundle. It is the fastest way to visually identify which dependencies are consuming the most space.

// webpack.config.js
const BundleAnalyzerPlugin =
  require("webpack-bundle-analyzer").BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: "static", // generates HTML file
      openAnalyzer: false,
      reportFilename: "bundle-report.html",
    }),
  ],
};

Key features. Interactive treemap opens in the browser. Shows parsed size, gzip size, and stat size for every module. Supports tree-shaking visualization - see what was eliminated and what was not. Works with webpack 4 and 5. The static mode generates a standalone HTML report you can share with your team or archive in CI.

Pricing. Free and open source under MIT license.

When to use it. Use webpack-bundle-analyzer whenever you suspect your bundle is too large. Run it after adding new dependencies, during performance audits, or on a schedule in CI to track bundle size trends. If you are not using webpack, see source-map-explorer for a bundler-agnostic alternative.

11. source-map-explorer - Bundler-agnostic bundle analysis

source-map-explorer analyzes JavaScript bundles using source maps to determine exactly which source files contribute to your final output. Unlike webpack-bundle-analyzer, it works with any bundler that produces source maps - webpack, Vite, Rollup, esbuild, Parcel, and Next.js.

# Analyze a production bundle
npx source-map-explorer dist/main.js

# Output as HTML report
npx source-map-explorer dist/main.js --html report.html

# Analyze multiple bundles
npx source-map-explorer dist/*.js

Key features. Works with any bundler that generates source maps. Interactive treemap visualization. Shows byte-level attribution of every source file. Detects duplicate modules included multiple times. CLI-based with HTML, JSON, and TSV output options for CI integration.

Pricing. Free and open source under Apache-2.0 license.

When to use it. source-map-explorer is the best choice for projects using Vite, Rollup, esbuild, or any non-webpack bundler. It is also useful for debugging production bundles where you only have the compiled output and source maps - common when auditing third-party applications or investigating performance issues in deployed code.

12. bundlephobia - Check package size before installing

bundlephobia is a web tool that shows you the cost of adding an npm package to your bundle before you install it. Enter a package name and you immediately see its minified size, gzipped size, download time on 3G/4G, composition breakdown, and whether it supports tree-shaking.

Key features. Instant size lookup for any npm package. Shows the full dependency tree and which transitive dependencies contribute the most weight. Compares package sizes side-by-side. Export cost analysis shows the size of individual named exports. Scan your package.json to audit all dependencies at once.

Pricing. Free web tool.

When to use it. Check bundlephobia before adding any new dependency. A 2KB utility library and a 200KB utility library might have the same API, but only one belongs in a performance-sensitive frontend bundle. Bundlephobia is also invaluable when choosing between competing packages - date-fns (16KB tree-shakeable) vs moment (72KB non-tree-shakeable), for example.

Security scanners

JavaScript applications face a unique threat surface. The npm ecosystem has over 2 million packages, and supply chain attacks are increasingly common. Client-side JavaScript is exposed to XSS, CSRF, and injection attacks. Server-side Node.js code handles user input, database queries, and file system access. Security scanners detect vulnerabilities in both your code and your dependencies.

13. Semgrep - Rule-based SAST with 1,000+ JavaScript rules

Semgrep is an open-source static analysis tool that uses pattern-matching rules written in a syntax that mirrors the target language. For JavaScript and TypeScript, Semgrep has over 1,000 community rules covering XSS, SQL injection, prototype pollution, NoSQL injection, command injection, path traversal, insecure deserialization, and framework-specific vulnerabilities for Express, React, Next.js, Angular, and Vue.

# Custom Semgrep rule for Express.js
rules:
  - id: express-sql-injection
    patterns:
      - pattern: |
          $DB.query($QUERY + $INPUT, ...)
      - pattern-inside: |
          function $FUNC($REQ, $RES, ...) { ... }
    message: >
      SQL query built with string concatenation using request input.
      Use parameterized queries instead.
    severity: ERROR
    languages: [javascript, typescript]

Key features. Over 3,000 total rules across 30+ languages, with 1,000+ covering JavaScript and TypeScript. The rule syntax mirrors JavaScript, making custom rules intuitive to write. Scans complete in seconds - full project scans typically run in 8-15 seconds. The Pro tier adds cross-file taint analysis that traces user input from Express req objects through middleware and service layers to dangerous sinks. Semgrep Assistant uses AI to triage findings and reduce false positives by up to 60%.

Pricing. OSS CLI is free (LGPL-2.1). Full platform is free for up to 10 contributors. Team tier is $35/contributor/month.

When to use it. Semgrep is the best security scanner for JavaScript teams that want customizable, fast, CI-friendly scanning. Its rule syntax is developer-friendly enough that frontend engineers can write custom rules for their own frameworks and libraries. For deeper analysis, see our Semgrep setup guide.

14. Snyk Code - AI-powered cross-file security analysis

Snyk Code is the SAST component of the Snyk platform. Its DeepCode AI engine performs interfile dataflow analysis, tracing the path of user input across multiple files to detect vulnerabilities that single-file scanners miss entirely. For JavaScript and TypeScript projects, this means catching prototype pollution through recursive merge utilities, XSS through React dangerouslySetInnerHTML fed by unsanitized API responses, and NoSQL injection through Mongoose query builders.

Key features. Real-time scanning in VS Code and JetBrains - vulnerabilities appear as you type. Cross-file taint analysis that follows data from req.body through service layers to database queries. AI-powered fix suggestions with data flow visualizations showing exactly how tainted data reaches a dangerous sink. The broader Snyk platform adds SCA (dependency scanning), container security, and IaC scanning.

Pricing. Free tier for 1 user with limited scans. Team plan at $25/dev/month. Enterprise pricing is custom.

When to use it. Snyk Code is the best choice for JavaScript teams that want IDE-integrated security scanning with the deepest cross-file analysis available. It is particularly strong for Node.js backend applications where vulnerabilities often span request handlers, middleware, and data access layers. For setup instructions, see our Snyk setup guide.

15. npm audit - Built-in dependency vulnerability scanning

npm audit is npm's built-in tool for checking your dependency tree against the GitHub Advisory Database. It scans your package-lock.json and reports known vulnerabilities in both direct and transitive dependencies.

# Check for vulnerabilities
npm audit

# Only show high and critical severity
npm audit --audit-level=high

# Automatically fix vulnerabilities where possible
npm audit fix

# Generate a JSON report for CI
npm audit --json > audit-report.json

Key features. Built into npm - no additional installation required. Covers the entire dependency tree, including transitive dependencies. Shows severity ratings (low, moderate, high, critical), affected versions, and patched versions. The npm audit fix command automatically updates packages to patched versions when semver-compatible updates exist. The npm audit signatures command verifies package integrity against registry signatures.

Pricing. Free, built into npm.

When to use it. Run npm audit in CI on every build. It catches known dependency vulnerabilities with zero configuration. However, npm audit only covers known CVEs in published packages - it does not analyze your own source code for vulnerabilities. Pair it with a SAST tool like Semgrep or Snyk Code for comprehensive security coverage.

16. Socket - Supply chain security and malicious package detection

Socket takes a fundamentally different approach to npm security. Instead of matching packages against a CVE database (like npm audit), Socket analyzes the actual behavior of packages to detect supply chain attacks - malicious code, typosquatting, install scripts that exfiltrate data, and packages that suddenly add network access or file system operations in a patch update.

Key features. Behavioral analysis of npm packages - detects when a package adds unexpected network requests, file system access, or shell execution in new versions. Typosquatting detection - warns when a package name is suspiciously similar to a popular package. Install script analysis - flags postinstall scripts that execute arbitrary code. GitHub PR integration - Socket comments on pull requests when new dependencies introduce risk indicators.

Pricing. Free for open-source projects. Paid plans for private repositories start at team tiers. Enterprise pricing is custom.

When to use it. Socket is essential for teams that install npm packages frequently and want protection against supply chain attacks that CVE databases do not cover. It is complementary to npm audit: npm audit catches known vulnerabilities, Socket catches malicious behavior. Use both.

Code quality platforms

Code quality platforms go beyond single-file linting to provide project-wide analysis, technical debt tracking, code coverage integration, and quality gate enforcement. They run in CI/CD pipelines and provide dashboards that track code health over time.

17. SonarQube - Enterprise code quality with 300+ JavaScript rules

SonarQube is the most widely deployed code quality platform in enterprise environments. For JavaScript and TypeScript, it provides over 300 rules covering bugs, code smells, security vulnerabilities, and security hotspots. Its quality gate system lets you define pass/fail criteria for every pull request and block merges that do not meet your standards.

Key features. Over 300 JavaScript/TypeScript rules across bugs, code smells, vulnerabilities, and security hotspots. Quality gate enforcement - block PRs that introduce critical issues, drop below coverage thresholds, or exceed duplication limits. Technical debt tracking with trend visualization over weeks and months. Compliance mapping to OWASP Top 10, CWE, and SANS Top 25. SonarLint IDE extension provides real-time feedback in VS Code and JetBrains with connected mode for shared rule configuration.

# sonar-project.properties
sonar.projectKey=my-javascript-project
sonar.sources=src
sonar.tests=tests
sonar.javascript.lcov.reportPaths=coverage/lcov.info
sonar.exclusions=**/node_modules/**,**/dist/**
sonar.coverage.exclusions=**/*.test.ts,**/*.spec.ts

Pricing. Community Build is free (no branch analysis or PR decoration). SonarQube Cloud starts free for up to 50K LOC. Self-hosted Developer Edition starts at approximately $2,500/year. Enterprise Edition starts at approximately $20,000/year.

When to use it. SonarQube is the right choice for enterprise teams that need quality gate enforcement, compliance reporting, and long-term technical debt tracking. For smaller teams, the Community Build is a strong free option, though the lack of PR decoration limits its usefulness in pull request workflows. For setup help, see our SonarQube setup guide.

18. CodeClimate - Maintainability metrics and technical debt tracking

CodeClimate Quality analyzes your JavaScript and TypeScript code for maintainability, providing letter grades (A through F) for every file based on complexity, duplication, and structural issues. It visualizes technical debt as estimated remediation time, making it easy for non-technical stakeholders to understand code health.

Key features. Maintainability ratings with letter grades for every file. Technical debt estimation in hours/days of remediation time. Code duplication detection across the entire project. Cognitive complexity scoring that identifies functions that are too hard to understand. Test coverage integration with trend tracking. GitHub and GitLab PR integration with inline annotations.

Pricing. Free for open-source projects. Paid plans start at approximately $600/month for private repositories. Enterprise pricing is custom.

When to use it. CodeClimate is best for teams that want maintainability metrics and technical debt visibility, particularly when communicating code health to engineering leadership. Its letter-grade system makes code quality tangible for stakeholders who do not read lint output. However, its rule depth for JavaScript is narrower than SonarQube, and it does not offer security scanning.

19. DeepSource - Autofix with the lowest false positive rate

DeepSource is a code quality platform that optimizes for precision over detection volume. It reports a sub-5% false positive rate - the lowest of any platform we have evaluated. For JavaScript and TypeScript, DeepSource detects anti-patterns, performance issues, potential bugs, and security vulnerabilities with AI-powered autofix that generates fix PRs automatically.

Key features. Sub-5% false positive rate - when DeepSource flags an issue, developers trust it. AI Autofix generates pull requests with correct fixes for roughly 70% of detected issues. JavaScript and TypeScript analyzers cover over 150 rules including React, Node.js, and Express patterns. Performance issue detection including unnecessary re-renders, memory leaks, and inefficient data structures. Integration with GitHub, GitLab, and Bitbucket.

Pricing. Free for individual developers with unlimited repositories. Team plan at $12/user/month. Enterprise at custom pricing.

When to use it. DeepSource is the best choice for teams that have been burned by noisy analysis tools. If your developers ignore code quality findings because too many are false positives, DeepSource's precision-first approach restores trust. The AI Autofix feature is particularly valuable for JavaScript projects where fixes like adding null checks or replacing deprecated API calls are repetitive. For a deeper look, see our DeepSource review.

20. Codacy - Automated reviews with 40+ tool integrations

Codacy is an all-in-one code quality platform that bundles multiple analysis engines under a single dashboard. For JavaScript and TypeScript, it runs ESLint, Semgrep, PMD, and other engines simultaneously, aggregating findings into a unified view with code quality grades, coverage tracking, and security scanning.

Key features. Aggregates findings from 40+ analysis engines including ESLint, Semgrep, and JSHint. Supports 49 programming languages - the widest coverage of any platform on this list. SAST security scanning, SCA dependency scanning, and secrets detection included. Coverage tracking with integration for Istanbul, Jest, and other JavaScript coverage reporters. AI Guardrails free IDE extension scans AI-generated code in VS Code, Cursor, and Windsurf in real time. Predictable pricing at $15/user/month with unlimited scans.

Pricing. Free tier covers up to 5 repositories. Pro plan at $15/user/month. Business plan with self-hosted options at approximately $37.50/user/month.

When to use it. Codacy is the best value option for teams of 10-50 developers who want code quality, security scanning, and coverage tracking without managing multiple tools. At $15/user/month, a 20-person team pays $300/month for comprehensive analysis - less than most competitors charge for code review alone. For integration guides, see our Codacy GitHub integration and Codacy setup guide.

AI code reviewers

AI code review tools use large language models to analyze pull requests and provide feedback that goes beyond what rule-based linters can detect. They catch logic errors, identify performance anti-patterns, flag security issues, and suggest improvements based on understanding the intent of code - not just its syntax.

21. CodeRabbit - AI PR review with zero-config setup

CodeRabbit is the most widely installed AI code review tool on GitHub, with over 2 million repositories connected and 13 million pull requests reviewed. It uses LLMs to understand code semantics and provides structured PR reviews with walkthrough summaries, inline comments, and one-click fix suggestions.

What makes it stand out for JavaScript. CodeRabbit understands JavaScript and TypeScript idioms in a way that rule-based tools cannot. It catches issues like using == where === is needed in a context where type coercion would cause a subtle bug, missing error boundaries in React component trees, promises that are constructed but never awaited in an async flow, and API endpoints that accept user input without validation. The natural language instruction system lets you define review behavior in plain English:

# .coderabbit.yaml
reviews:
  instructions:
    - "Flag any React component that uses useEffect without a dependency array"
    - "Warn when API routes do not validate request body with Zod or Joi"
    - "Check that all database queries use parameterized inputs"
    - "Ensure error responses include appropriate HTTP status codes"

Key features. PR walkthrough generation with file-by-file summaries explaining what changed and why. Inline code suggestions with one-click apply. Over 40 built-in linters complementing AI analysis with deterministic rules. Natural language configuration via .coderabbit.yaml. Multi-platform support for GitHub, GitLab, Azure DevOps, and Bitbucket.

Pricing. Free tier with unlimited repositories and unlimited reviews. Pro plan at $24/user/month adds advanced features and priority support.

When to use it. CodeRabbit is the default recommendation for any JavaScript team that wants AI-powered PR review. The free tier is generous enough for most small to mid-size teams. Pair it with a linter (ESLint or Biome) and a formatter (Prettier or Biome) for comprehensive coverage. For setup instructions, see our CodeRabbit setup guide and configuration guide.

22. CodeAnt AI - AI code health with auto-fix suggestions

CodeAnt AI is a Y Combinator-backed platform that combines AI-powered PR reviews with SAST security scanning, secret detection, infrastructure-as-code security, and DORA engineering metrics. For JavaScript teams, it provides a single platform that replaces the need for separate review, security, and engineering metrics tools.

Key features. Line-by-line AI PR feedback with one-click auto-fix suggestions. SAST scanning covering OWASP Top 10 vulnerabilities in JavaScript and TypeScript. Secrets detection for accidentally committed API keys, tokens, and credentials. IaC scanning for Terraform and CloudFormation misconfigurations. DORA metrics for tracking deployment frequency, lead time, and change failure rate. Supports GitHub, GitLab, Bitbucket, and Azure DevOps.

Pricing. Free Basic plan with AI code review. Premium plan at $24/user/month adds SAST, secrets, IaC, and DORA metrics. Enterprise pricing at $40/user/month.

When to use it. CodeAnt AI is the best choice for JavaScript teams that want a consolidated platform covering code review and security without stitching together multiple tools. At $24-40/user/month, it replaces what would otherwise require separate subscriptions for an AI review tool, a SAST scanner, and a secrets detector.

23. GitHub Copilot Code Review - Built into GitHub, agentic review

GitHub Copilot Code Review is GitHub's native AI review feature, available to Copilot subscribers. It reviews pull requests directly within the GitHub UI, leaving comments, suggesting fixes, and identifying potential issues. In 2026, GitHub has expanded it with agentic capabilities - Copilot can now follow up on its own suggestions and verify fixes.

Key features. Native GitHub integration - no third-party app installation required. Suggests code changes directly as GitHub suggested changes that can be committed with one click. Understands GitHub-specific context like issue references, linked PRs, and repository conventions. Agentic mode can perform multi-step review tasks. Available on all Copilot plans.

Pricing. Included with GitHub Copilot Individual ($19/user/month), Pro+ ($39/user/month), Business ($39/user/month), and Enterprise ($39/user/month).

When to use it. If your team already uses GitHub Copilot, the code review feature is included at no additional cost. It provides useful first-pass review, though dedicated tools like CodeRabbit and CodeAnt AI offer deeper analysis with better cross-file context and more actionable suggestions. For a detailed comparison, see our CodeRabbit vs GitHub Copilot analysis.

24. Sourcery - AI-powered refactoring suggestions

Sourcery focuses on code quality improvement through AI-powered refactoring suggestions. For JavaScript and TypeScript projects, it identifies code that works but could be written more clearly, more efficiently, or more idiomatically - and suggests specific refactorings.

Key features. AI-powered refactoring suggestions that go beyond linting - Sourcery identifies opportunities to simplify complex conditionals, extract helper functions, replace imperative loops with functional patterns, and improve variable naming. PR review integration with GitHub and GitLab. IDE extension for real-time suggestions in VS Code. Supports JavaScript, TypeScript, Python, and Go.

Pricing. Free for open-source projects. Pro plan at $10/user/month.

When to use it. Sourcery is the best choice for teams that care specifically about code readability and want AI-driven refactoring suggestions alongside standard linting. At $10/user/month, it is the most affordable AI review option. Its narrower language support (4 languages) means it is best for teams working primarily in JavaScript/TypeScript and Python. For a comparison with alternatives, see our CodeRabbit vs Sourcery analysis.

How to choose the right tools

With 24 tools across six categories, the decision can feel overwhelming. Here is a practical framework for choosing the right combination based on your project type and team size.

By project type

Frontend-only (React, Vue, Svelte). Your primary concerns are code quality, bundle size, and accessibility. Start with ESLint (or Biome) + Prettier + webpack-bundle-analyzer or source-map-explorer. Add CodeRabbit for AI review on teams of 3+.

Full-stack (Next.js, Nuxt, SvelteKit). You need both frontend and backend coverage. Use ESLint with typescript-eslint for type-aware linting, Prettier for formatting, Semgrep or Snyk Code for security scanning on API routes, and CodeRabbit for comprehensive PR review.

Node.js backend (Express, Fastify, NestJS). Security is your top priority. Use ESLint with typescript-eslint, Semgrep for SAST (especially injection and auth patterns), npm audit + Socket for dependency security, and SonarQube or Codacy for code quality tracking.

npm library or open-source package. Consistency and contributor experience matter most. Use Biome (or ESLint + Prettier), bundlephobia to keep your package lean, and CodeRabbit (free for unlimited repos) for reviewing contributor PRs.

Recommended tool combinations

Starter stack (free, solo developers and small teams).

Layer	Tool	Cost
Linting	ESLint or Biome	Free
Formatting	Prettier or Biome	Free
Security	npm audit + Semgrep OSS	Free
AI Review	CodeRabbit (free tier)	Free
Total		$0/month

Intermediate stack (growing teams, 5-20 developers).

Layer	Tool	Cost
Linting	ESLint + typescript-eslint	Free
Formatting	Prettier	Free
Security	Semgrep (free for 10 contributors)	Free-$35/contributor/mo
Code Quality	Codacy or DeepSource	$12-15/user/mo
AI Review	CodeRabbit Pro	$24/user/mo
Bundle Analysis	source-map-explorer	Free
Total (10 devs)		~$390/month

Enterprise stack (50+ developers, compliance requirements).

Layer	Tool	Cost
Linting	ESLint + typescript-eslint	Free
Formatting	Prettier	Free
Security	Snyk Code + Socket	$25/dev/mo + paid plan
Code Quality	SonarQube Enterprise	~$20,000/yr
AI Review	CodeRabbit Enterprise	$24/user/mo
Supply Chain	npm audit + Socket	Free + paid
Bundle Analysis	webpack-bundle-analyzer	Free
Total (50 devs)		~$3,900/month

Setting up a complete JavaScript analysis pipeline

The real power of code analysis comes from combining multiple tools into an automated pipeline that runs on every pull request. Here is a production-ready GitHub Actions workflow that combines ESLint, Prettier, Semgrep, and CodeRabbit.

# .github/workflows/code-analysis.yml
name: Code Analysis

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]

jobs:
  lint-and-format:
    name: Lint & Format Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"

      - run: npm ci

      - name: Run ESLint
        run: npx eslint . --max-warnings=0

      - name: Check Prettier formatting
        run: npx prettier --check .

      - name: Run TypeScript type check
        run: npx tsc --noEmit

  security-scan:
    name: Security Scanning
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/javascript
            p/typescript
            p/react
            p/nodejs
            p/owasp-top-ten
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

      - uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"

      - run: npm ci

      - name: Run npm audit
        run: npm audit --audit-level=high

  code-quality:
    name: Code Quality
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"

      - run: npm ci

      - name: Run tests with coverage
        run: npx vitest run --coverage

      - name: Check bundle size
        run: |
          npm run build
          npx source-map-explorer dist/**/*.js --json > bundle-report.json
          echo "Bundle analysis complete. Check artifacts for details."

      - name: Upload coverage
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

      - name: Upload bundle report
        uses: actions/upload-artifact@v4
        with:
          name: bundle-report
          path: bundle-report.json

How the pipeline works. Three jobs run in parallel for maximum speed. The lint-and-format job catches style violations and type errors in under 30 seconds. The security-scan job runs Semgrep against JavaScript, TypeScript, React, Node.js, and OWASP Top 10 rulesets, then checks dependencies with npm audit. The code-quality job runs tests with coverage and generates a bundle size report. CodeRabbit runs separately via its GitHub App - once installed, it automatically reviews every PR with no workflow configuration needed.

Adding CodeRabbit. CodeRabbit does not require a GitHub Actions workflow. Install the CodeRabbit GitHub App, grant it repository access, and it begins reviewing PRs automatically. To customize its behavior, add a .coderabbit.yaml file to your repository root:

# .coderabbit.yaml
language: en
reviews:
  profile: chill
  high_level_summary: true
  poem: false
  path_instructions:
    - path: "src/api/**"
      instructions: "Check all API routes for input validation and proper error handling"
    - path: "src/components/**"
      instructions: "Verify React components handle loading and error states"
  auto_review:
    enabled: true
    drafts: false

This configuration tells CodeRabbit to use a balanced review tone, generate high-level summaries for each PR, apply stricter review criteria for API routes and React components, and skip draft PRs.

Key takeaways

JavaScript code analysis in 2026 is not about picking a single tool - it is about building a layered pipeline where each tool handles what it does best.

Linters catch syntax and pattern issues. ESLint remains the standard for its plugin ecosystem, but Biome is the faster modern alternative. Every JavaScript project needs one or the other.

Formatters eliminate style debates. Prettier is the established choice. Biome's built-in formatter is a strong alternative if you are already using Biome for linting. Either way, formatting should be automated, not discussed in code review.

Bundler analyzers keep your builds lean. Check webpack-bundle-analyzer or source-map-explorer periodically. Use bundlephobia before adding any new dependency.

Security scanners protect your code and dependencies. Semgrep and Snyk Code catch vulnerabilities in your source code. npm audit and Socket protect your dependency tree. Use at least one tool from each category.

Code quality platforms track health over time. SonarQube, Codacy, and DeepSource provide dashboards, quality gates, and trend analysis that point-in-time tools cannot offer.

AI reviewers catch what rules miss. CodeRabbit, CodeAnt AI, and GitHub Copilot Code Review understand code intent and catch logic errors, performance issues, and architectural problems that no amount of lint rules can detect.

The best JavaScript analysis setup is one your team actually uses. Start with the free starter stack - ESLint, Prettier, npm audit, and CodeRabbit's free tier. That combination costs nothing and catches the majority of issues. Add specialized tools as your project grows, your team scales, or your compliance requirements demand it.

Frequently Asked Questions

What is the best JavaScript linter in 2026?

ESLint remains the dominant JavaScript linter with the largest ecosystem of plugins and rules. However, Biome (the Rome successor) is gaining traction as a faster alternative that combines linting and formatting. For new projects, Biome offers the best performance; for existing projects with complex ESLint configs, staying with ESLint v9's flat config is recommended.

What is the fastest JavaScript linter?

Biome is the fastest JavaScript linter, running 20-35x faster than ESLint on most codebases. It's written in Rust and handles both linting and formatting in a single pass. oxlint is another Rust-based alternative that's even faster for pure linting but has fewer rules than Biome.

Do I need both a linter and a formatter for JavaScript?

Yes, but modern tools combine both. Biome handles linting and formatting in one tool. If using ESLint, pair it with Prettier for formatting. The ESLint team recommends against using ESLint for formatting rules (they deprecated stylistic rules) and suggests using a dedicated formatter.

What tools detect security vulnerabilities in JavaScript code?

Semgrep (free, rule-based SAST), Snyk Code (AI-powered, cross-file analysis), SonarQube (broad security rules), and npm audit (dependency vulnerabilities). For React-specific security, eslint-plugin-security and Semgrep's JavaScript rulesets cover XSS, injection, and prototype pollution patterns.

Are AI code review tools worth it for JavaScript projects?

Yes. AI tools like CodeRabbit catch logic errors, performance anti-patterns, and security issues that rule-based linters miss. They're particularly valuable for reviewing business logic, API usage patterns, and architectural decisions. Most teams use them alongside traditional linters for comprehensive coverage.

Originally published at aicodereview.cc

Stop Burning Money on AI: Cost Tracking & Rate Limiting for Local LLMs

Programming Central — Fri, 03 Apr 2026 20:00:00 +0000

Running Large Language Models (LLMs) locally offers incredible privacy and control, but it’s easy to spin up costs you didn’t anticipate. Just like a cloud API bills per token, your local LLM consumes valuable resources – CPU, GPU, memory, and even electricity. Without careful management, you risk system instability, poor user experience, and ultimately, wasted hardware. This post dives into the operational economics of local AI, showing you how to track costs and implement rate limiting to keep your LLM applications running smoothly and efficiently.

The Economics of Local AI: From Compute to Cash

We’ve all been there: a functional prototype that works beautifully… until multiple users hit it simultaneously. Integrating LLMs into your Node.js applications (using tools like Ollama and Transformers.js) is just the first step. To move to production, you need to treat inference as a finite resource with tangible costs.

Think of it like a database. A query consumes CPU cycles and I/O. An LLM request consumes computational power, memory bandwidth, and time. In the cloud, this translates directly to monetary cost per token. Locally, the cost manifests as hardware wear, electricity, and, crucially, the opportunity cost of blocking the system for other users. A runaway LLM process can easily bring a server to its knees.

Understanding the Costs: Token Usage, Latency & Hardware

Effective cost tracking requires understanding the key metrics. It’s more granular than traditional web application monitoring.

1. Token Throughput: The Core Metric

The most fundamental metric is token throughput (tokens per second - TPS). Break it down:

Input Tokens: Tokens in the user’s prompt and any retrieved context (from RAG – Retrieval Augmented Generation).
Output Tokens: Tokens generated by the model.

Why it matters: LLM execution time is proportional to sequence length. Generating 100 tokens takes roughly twice as long as 50. This non-deterministic latency demands a different mental model than standard HTTP request-response cycles.

Analogy: Imagine an LLM as a novelist. Input tokens are research notes, output tokens are written pages, and latency is the time to write. You can’t predict the book’s completion time until the final sentence. Similarly, you can’t know the exact inference cost until generation finishes.

2. Hardware Overhead: VRAM & Compute

In a local deployment, “cost” is physical. The primary constraints are:

VRAM (Video RAM): Memory for model weights and the "KV Cache" (Key-Value Cache).
Compute Units: GPU core or CPU vector instruction utilization.

The KV Cache Bottleneck: LLMs remember context by storing intermediate calculations (Keys and Values) in memory. This cache grows linearly with input and output tokens. An 8GB model on a 12GB GPU has 4GB headroom. But a 50,000-token document as context could fill that 4GB, causing an Out-Of-Memory (OOM) error – a costly crash.

Analogy: Think of a restaurant kitchen. Model weights are permanent appliances. The KV Cache is counter space for preparing a dish. A simple dish needs little space; a complex banquet needs all of it. Rate limiting prevents accepting orders that overwhelm the kitchen.

Rate Limiting: The Token Bucket Algorithm

Rate limiting protects your hardware from overload. Unlike cloud APIs that throttle based on credits, local servers throttle based on capacity. The Token Bucket algorithm is superior to simple "requests per minute" counters because it handles traffic bursts while enforcing a steady-state average.

How it works:

The Bucket: A container with a maximum capacity (burst size).
The Tokens: Represent "permission to process."
The Refill Rate: Tokens are added at a fixed rate (e.g., 10 tokens/second).
The Request: Consumes tokens. If the bucket is empty, the request is rejected (or queued).

Optimizing Performance: Batching & Context Management

Maximizing value requires optimizing hardware usage.

1. Request Batching

Modern inference engines (like Ollama) support dynamic batching – grouping multiple requests into a single inference call. GPUs process matrix multiplications in parallel. Sending four requests simultaneously fills the GPU cores more efficiently, increasing aggregate throughput, even if per-request latency increases slightly.

Analogy: A city bus is more efficient than individual taxis for transporting many passengers.

2. Context Window Management

The "Context Window" is the maximum text the model can consider (e.g., 4096 or 8192 tokens). In RAG, this is critical. Blindly pasting retrieved text can exceed the window or “drown out” the user’s question.

Optimization Strategies:

Re-ranking: Use a smaller model to score the relevance of retrieved chunks and keep only the top-N.
Summarization: Summarize long context before injection.

Code Example: TypeScript Token Bucket Rate Limiter

This example implements a Token Bucket algorithm with cost tracking in TypeScript, suitable for a Node.js backend.

// pages/api/chat.ts
// Next.js API Route Handler

import { NextApiRequest, NextApiResponse } from 'next';

interface RateLimiterConfig {
  capacity: number;
  refillRate: number;
  costPerRequest: number;
}

interface RateLimiterState {
  tokens: number;
  lastRefill: number;
}

interface CostMetrics {
  promptTokens: number;
  completionTokens: number;
  latencyMs: number;
  estimatedComputeCost: number;
}

interface ChatRequestPayload {
  query: string;
  userId: string;
}

const CONFIG: RateLimiterConfig = {
  capacity: 10,
  refillRate: 2,
  costPerRequest: 1,
};

const userStates = new Map<string, RateLimiterState>();

function refillBucket(state: RateLimiterState): RateLimiterState {
  const now = Date.now();
  const timePassed = (now - state.lastRefill) / 1000;
  const tokensToAdd = timePassed * CONFIG.refillRate;
  const newTokens = Math.min(CONFIG.capacity, state.tokens + tokensToAdd);
  return { ...state, tokens: newTokens, lastRefill: now };
}

function tryConsume(state: RateLimiterState): [RateLimiterState, boolean] {
  const refilledState = refillBucket(state);
  if (refilledState.tokens >= CONFIG.costPerRequest) {
    return [
      { ...refilledState, tokens: refilledState.tokens - CONFIG.costPerRequest },
      true,
    ];
  }
  return [refilledState, false];
}

async function handleRequest(req: NextApiRequest, res: NextApiResponse) {
  const { query } = req.body as ChatRequestPayload;
  const userId = req.body.userId || 'anonymous';

  let currentState = userStates.get(userId) || {
    tokens: CONFIG.capacity,
    lastRefill: Date.now(),
  };

  const [newState, allowed] = tryConsume(currentState);
  userStates.set(userId, newState);

  if (!allowed) {
    return res.status(429).json({ message: 'Too many requests' });
  }

  // Simulate LLM inference (replace with Ollama/Transformers.js call)
  const startTime = Date.now();
  const promptTokens = query.length / 4; // Rough estimate
  const completionTokens = 50; // Example
  const latencyMs = Math.random() * 400 + 100;
  await new Promise((resolve) => setTimeout(resolve, latencyMs));

  const costMetrics: CostMetrics = {
    promptTokens,
    completionTokens,
    latencyMs,
    estimatedComputeCost: 0.01, // Example cost
  };

  res.status(200).json({ response: `Processed: ${query}`, costMetrics });
}

export default handleRequest;

Conclusion: Sustainable Local AI

Cost tracking and rate limiting aren’t just about preventing crashes; they’re about building sustainable local AI applications. By understanding the economics of inference and implementing these techniques, you can maximize the value of your hardware, deliver a consistent user experience, and avoid unexpected costs. Remember to adapt the configuration and metrics to your specific hardware and application needs. Don't just run your LLM – manage it.

The concepts and code demonstrated here are drawn directly from the comprehensive roadmap laid out in the book The Edge of AI. Local LLMs (Ollama), Transformers.js, WebGPU, and Performance Optimization Amazon Link of the AI with JavaScript & TypeScript Series.
The ebook is also on Leanpub.com: https://leanpub.com/EdgeOfAIJavaScriptTypeScript.

👉 Free Access now to the TypeScript & AI Series on Programming Central, it includes 8 Volumes, 160 Chapters and hundreds of quizzes for every chapter.

Building a GDPR-Compliant Multi-Tenant CRM with Laravel

WISSEN BERATUNG — Fri, 03 Apr 2026 19:59:44 +0000

Building a CRM that handles personal data (names, emails, phone numbers, addresses) in the EU means you can't treat GDPR as an afterthought. Here's how we implemented it in WB-CRM, our multi-tenant CRM built with Laravel 12.

1. Database-per-Tenant Architecture

We use stancl/tenancy v3 with database-per-tenant isolation. Each tenant gets their own MySQL database (tenant_acme, tenant_demo, etc.).

// Central models explicitly set their connection
protected $connection = 'central';

// Tenant models rely on the bootstrapper — no $connection property
// stancl/tenancy switches the default connection automatically

Why not shared database with row-level security?

In a shared database, one missing WHERE tenant_id = ? clause leaks data across companies. With DB-per-tenant, it's architecturally impossible.

2. Field-Level Encryption for PII

Laravel's encrypted cast encrypts individual database fields with AES-256:

protected function casts(): array
{
    return [
        'name'       => 'encrypted',
        'email'      => 'encrypted',
        'phone'      => 'encrypted',
        'address'    => 'encrypted',
        'ip_address' => 'encrypted',
    ];
}

The tradeoff: You can't query encrypted fields with WHERE email = ?. We solve this with companion hash columns:

// email_hash stores a HMAC-SHA256 hash for lookups
$contact = Contact::where('email_hash', hash_hmac('sha256', $email, config('app.key')))->first();

3. GDPR Data Subject Rights in Code

Articles 15-21 are not just checkboxes — they need actual endpoints:

Right	Article	Implementation
Access	Art. 15	JSON/CSV export endpoint with re-authentication
Rectification	Art. 16	Profile edit functionality
Erasure	Art. 17	Account deletion + cascading DB cleanup
Restriction	Art. 18	Account freeze (disable without delete)
Portability	Art. 20	Machine-readable export (JSON)
Objection	Art. 21	Marketing opt-out

Every GDPR operation writes an audit log entry with: who, when, what, which tenant, old values, new values.

4. Audit Trail

Every state-changing operation produces an audit log entry. This is mandatory for GDPR Art. 30 (records of processing activities):

TenantAuditLog::create([
    'uuid'           => Str::uuid(),
    'auditable_type' => get_class($model),
    'auditable_id'   => (string) $model->uuid,
    'event'          => 'gdpr_data_export',
    'old_values'     => null,
    'new_values'     => ['format' => 'json', 'fields' => $exportedFields],
    'user_type'      => TenantUser::class,
    'user_id'        => $tenantUser->id,
    'ip_address'     => request()->ip(),
    'user_agent'     => request()->userAgent(),
]);

5. What I Wish I Knew Earlier

Herd/CLI bcrypt incompatibility: CLI PHP and Herd PHP on macOS produce incompatible bcrypt hashes. Always set passwords from the web context.
Session connection must be central: With database-per-tenant, sessions stored in a tenant DB are lost when switching tenants.
ENUM columns are evil in migrations: Adding a value requires recreating the column in MySQL. Use string columns with validation instead.
getCustomColumns() in stancl/tenancy: If you add a column to the tenants table but forget to register it in getCustomColumns(), it silently lands in the JSON data column. Hours of debugging.

We built WB-CRM with these principles. Free ONE plan available (500 contacts, 1 user). Built and hosted in Germany.

MiniStack vs Floci vs LocalStack: Honest Performance Benchmark (April 3rd 2026)

Nahuel Nucera — Fri, 03 Apr 2026 19:57:59 +0000

We ran 30 API operations, throughput tests, and service coverage checks against real Docker containers. No cherry-picking. No marketing. Just numbers.

TL;DR

Metric	MiniStack	Floci	LocalStack Free
Services supported	31	20	~15 (rest paywalled)
Image size	211 MB	276 MB	~1 GB
Memory after load	39 MB	56 MB	~500 MB
Startup time	<2s	~3s	~15-30s
Median API latency	4.6 ms	5.2 ms	varies
License	MIT	MIT	BSL (restricted)

Methodology

Fresh docker system prune -af --volumes before each run
Both images pulled from Docker Hub (nahuelnucera/ministack:latest, hectorvent/floci:latest)
Each operation run 5 times, median taken
All tests use boto3 with endpoint_url=http://localhost:{port}
Machine: Apple Silicon M4, 24 GB RAM, Docker Desktop
No warm-up runs — cold container, first request measured

Image Size

nahuelnucera/ministack:latest    211 MB
hectorvent/floci:latest          276 MB
localstack/localstack:latest    ~1.0 GB

MiniStack is 24% smaller than Floci and 5x smaller than LocalStack. MiniStack uses Alpine + Python + Node.js. Floci uses a JVM-based stack.

Startup Time

	First Response
MiniStack	1 ms
Floci	15 ms
LocalStack	15-30 seconds

MiniStack starts instantly. No JVM warm-up, no class loading. The ASGI server is ready before the health check even fires.

API Latency (median of 5 runs, single operation)

S3

Operation	Floci	MiniStack	Difference
CreateBucket	5.9 ms	5.6 ms	-5%
PutObject (1 KB)	6.3 ms	6.4 ms	+2%
PutObject (100 KB)	10.6 ms	7.3 ms	-31%
GetObject	4.8 ms	5.4 ms	+13%
ListObjectsV2	5.5 ms	6.2 ms	+13%

S3 is competitive. Floci edges ahead on small reads. MiniStack is significantly faster on larger writes (100 KB: 31% faster).

SQS

Operation	Floci	MiniStack	Difference
CreateQueue	4.5 ms	4.4 ms	-2%
SendMessage	9.8 ms	8.3 ms	-15%
ReceiveMessage	7.8 ms	6.5 ms	-17%

MiniStack is consistently faster on SQS operations.

DynamoDB

Operation	Floci	MiniStack	Difference
CreateTable	3.7 ms	3.4 ms	-8%
PutItem	3.7 ms	4.2 ms	+14%
GetItem	3.8 ms	4.4 ms	+16%
Query	4.3 ms	5.0 ms	+16%
Scan	4.2 ms	4.6 ms	+10%

Floci wins on DynamoDB read/write operations. This is likely due to Java's optimized JSON parsing for the DynamoDB wire format.

Other Services

Operation	Floci	MiniStack	Difference
SNS CreateTopic	3.9 ms	3.8 ms	-3%
SNS Publish	8.5 ms	8.8 ms	+4%
IAM CreateRole	5.0 ms	5.9 ms	+18%
STS GetCallerIdentity	5.1 ms	4.5 ms	-12%
SSM PutParameter	6.6 ms	4.7 ms	-29%
SSM GetParameter	4.7 ms	5.2 ms	+11%
SecretsManager Create	4.8 ms	4.4 ms	-8%
SecretsManager Get	4.7 ms	4.4 ms	-6%
EventBridge PutRule	5.3 ms	4.7 ms	-11%
EventBridge PutEvents	4.8 ms	5.5 ms	+15%
Kinesis CreateStream	5.6 ms	5.1 ms	-9%
CW PutMetricData	4.9 ms	4.4 ms	-10%
Logs CreateLogGroup	6.5 ms	4.6 ms	-29%
Route53 CreateHostedZone	ERR	4.3 ms	Floci doesn't support Route53

MiniStack is faster on SSM, SecretsManager, CloudWatch, and Logs. Floci is faster on IAM and EventBridge PutEvents. Route53 only works on MiniStack.

Throughput

Test	Floci	MiniStack
SQS SendMessage x500	221 ops/s	233 ops/s

On sustained SQS throughput, MiniStack is 5% faster. Earlier cold-start benchmarks showed Floci ahead, but with warm containers the gap disappears.

Memory Usage

State	Floci	MiniStack
At idle	26 MB	38 MB
After 500+ operations	56 MB	39 MB

Interesting: Floci uses less memory at idle (JVM lazy class loading) but grows to 56 MB after load. MiniStack starts at 38 MB and barely grows. Over time, MiniStack's memory profile is more predictable.

Service Coverage

Service	Floci	MiniStack
S3	YES	YES
SQS	YES	YES
SNS	YES	YES
DynamoDB	YES	YES
Lambda	YES	YES
IAM	YES	YES
STS	YES	YES
SecretsManager	YES	YES
CloudWatch Logs	YES	YES
SSM	YES	YES
EventBridge	YES	YES
Kinesis	YES	YES
CloudWatch Metrics	YES	YES
SES	YES	YES
Step Functions	YES	YES
Cognito	YES	YES
RDS	YES	YES
CloudFormation	YES	YES
ACM	YES	YES
KMS	YES	YES
ECS	NO	YES
ElastiCache	NO	YES
Glue	NO	YES
Athena	NO	YES
Firehose	NO	YES
Route53	NO	YES
EC2/VPC	NO	YES
EMR	NO	YES
ELBv2/ALB	NO	YES
WAF v2	NO	YES
ECR	NO	YES
Total	20	31

MiniStack supports 55% more services. The gap is particularly significant for infrastructure-heavy workloads (ECS, RDS with real Docker, EC2/VPC, Route53, ALB).

Feature Comparison

Feature	MiniStack	Floci	LocalStack Free
Lambda Python execution	YES	YES	YES
Lambda Node.js execution	YES	NO	YES
Lambda warm workers	YES	NO	YES
RDS real Postgres/MySQL	YES	YES	NO (Pro)
ECS real Docker containers	YES	NO	NO (Pro)
ElastiCache real Redis	YES	NO	NO (Pro)
Athena real SQL (DuckDB)	YES	NO	NO (Pro)
CloudFormation	YES (12 types)	YES	YES
Step Functions TestState API	YES	NO	NO
SFN Mock Config (SFN Local compat)	YES	NO	YES
State persistence	YES (20 services)	NO	Partial
S3 disk persistence	YES	YES	YES
Detached mode (`-d` / `--stop`)	YES	NO	NO
Terraform v6 compatible	YES	Partial	YES
AWS SDK v2 chunked encoding	YES	NO	YES
Testcontainers examples	Java, Go, Python	NO	Java
`docker run` one-liner	YES	YES	YES
PyPI installable	YES	NO	YES

What Floci Does Better

Let's be honest about where Floci wins:

DynamoDB read latency — 15-16% faster on GetItem/Query/Scan. Java's JSON processing is well-optimized for DynamoDB's wire format.
Idle memory — 26 MB vs 38 MB at cold start. JVM defers class loading.

What MiniStack Does Better

11 more services — ECS, ElastiCache, Glue, Athena, Route53, EC2, EMR, ALB, WAF, Firehose, ECR.
Real infrastructure — RDS spins up actual Postgres/MySQL. ECS runs real containers. Athena runs real SQL via DuckDB.
Lambda Node.js — warm worker pool for both Python and Node.js.
State persistence — 20 services survive restarts.
Faster on most operations — SSM, SecretsManager, SQS, CloudWatch, Logs are 15-30% faster.
Terraform v6 ready — EC2 stubs, S3 Control routing, DynamoDB WarmThroughput.
Smaller image — 211 MB vs 276 MB (24% smaller).

When to Use What

Use MiniStack if:

You need ECS, Route53, EC2, Glue, Athena, ALB, or any of the 11 extra services
You're migrating from LocalStack and need maximum service coverage
You want state persistence across container restarts
You use Terraform v6
You want Lambda Node.js support

Use Floci if:

You only need the core 20 services
DynamoDB read performance is critical for your test suite
You want the smallest possible idle memory footprint

Use LocalStack Pro if:

You need IAM policy enforcement
You need Lambda container image support
Budget isn't a constraint

Benchmark Reproducibility

All benchmarks can be reproduced with:

docker system prune -af --volumes
docker pull nahuelnucera/ministack:latest
docker pull hectorvent/floci:latest

docker run --rm -d --name ms -p 4568:4566 nahuelnucera/ministack:latest
docker run --rm -d --name fl -p 4567:4566 hectorvent/floci:latest

# Run your own boto3 tests against both ports

Versions Tested

MiniStack: v1.1.27 (April 2026)
Floci: latest (April 2026)
LocalStack: comparison based on published documentation (not benchmarked directly)
boto3: 1.34+
Docker Desktop: latest
Hardware: Apple M4, 24 GB RAM

This benchmark was created by the MiniStack team. We tried to be as fair as possible — if you find any methodology issues, please open an issue on GitHub.

I analyzed 187 Claude Code sessions. $6,744 worth of tokens. Here's where they actually went.

SingYee — Fri, 03 Apr 2026 19:57:11 +0000

I've been using Claude Code heavily for the past month. Building trading bots, automation tools, side projects.

I knew I was burning through tokens but never looked at the numbers.

So I built a small CLI to parse my local session data. The result: 187 sessions. 3.3 billion tokens. $6,744 equivalent API cost.

I'm on Max, so this is equivalent API cost, not what I actually paid. But the token patterns are what matter here.

97% of my tokens were something I couldn't control

That was the first surprise. 97% were cache reads. Every turn, Claude re-reads the entire conversation context. Think of it like re-reading an entire book every time you turn a page.

The good news: cache reads are cheap ($1.5/M tokens) and completely normal. The bad news: it means the part you can actually control is tiny.

Only 2.8% of my tokens were controllable. Of that, 92.5% was cache creation (CLAUDE.md, MCP tools, system prompt loading), 6.6% was Claude's actual output, 0.9% was my input.

What I wouldn't have caught from /cost

This was the most useful part:

86 sessions over 30 turns without /compact, each one letting context balloon to 2-3x what it needed to be
840 subagent calls, every single one duplicating the full conversation context just to do a search
35 anomaly sessions burning tokens at 2-3x my normal rate
Bash was 40% of all tool calls, pumping long command outputs back into context every time
Peak hours (Mon-Fri 5-11am PT) used 1.3x more tokens on average than off-peak

What I actually changed

After seeing the data, three things:

I use /compact after ~20 turns now instead of letting sessions run endlessly
I stopped defaulting to Agent for codebase searches and use Grep/Glob directly
I try to keep heavy sessions out of peak hours when possible

Small changes, but the anomaly sessions have mostly stopped showing up.

The tool

Open sourced it. Called ccwhy, written in Rust, runs completely offline on your local ~/.claude/ data. No API keys needed.

brew install SingggggYee/tap/ccwhy

Or: cargo install ccwhy

Or: grab the binary

It's not a replacement for ccusage. ccusage tells you how much you spent. ccwhy tells you why, and what to change.

GitHub

Curious what other people's breakdowns look like. Is 97% cache reads normal, or is my setup unusually heavy?