DEV Community: Alex

I counted every Bun bug before and after the Rust rewrite

Alex — Mon, 10 Aug 2026 13:09:13 +0000

On May 14, Bun merged PR #30412. One pull request: 1,009,257 lines added, 2,188 files changed. The entire runtime, ported from Zig to Rust in 11 days by roughly 50 parallel Claude Code workflows, at about $165,000 in API costs. Jarred Sumner figures a human team would have needed a year.

Reactions split exactly how you'd guess. Andrew Kelley, Zig's creator, called it "a million lines of unreviewed slop". Rust people called it the future. Three months of arguing, and as far as I can tell, nobody on either side pulled the actual numbers.

So I did. Every issue filed against oven-sh/bun from six months before the merge until last week: 2,981 of them, bucketed into weeks anchored on the merge timestamp, each one classified by which build the reporter was running. The dataset and scripts live in this repo, and there's a much drier interactive report with every chart, if you want to check my work.

What the tracker shows

The pitch for the rewrite was memory safety. Bun's tracker was drowning in use-after-free and double-free crashes, and in safe Rust those are compile errors. Sumner put the whole thesis in one line: "Compiler errors are a better feedback loop than a style guide."

Canary is where you test that claim, because canary is the only channel where the Rust build has ever shipped. Same channel, same self-selected users who run prereleases, Zig builds before May 14, Rust builds after. The cut is unusually clean: I checked every version string in six months of pre-merge issues, and not one names a 1.4.x Bun build. A grep finds nine matches, and all nine turn out to be library versions like elysia 1.4.x. The 1.4 line simply did not exist for users until the morning of the merge.

Bug reports on canary went from 5.9 a week to 20.7. I don't read that as "Rust tripled the bugs", because two other things changed at the same moment: canary became the only way to get the new engine, so its population grew, and the PR literally asked people to file issues. Report volume is exposure times defect rate times willingness to report, and you only ever observe the product.

The ratios don't care about population size though, and they're stubborn:

Before the rewrite, 43.5% of canary bug reports eventually got closed as fixed. After: 41.9%.
Canary bugs fixed per week: 2.6 before, 8.7 after. Proportional to the report flood, not better.
Median time to fix across all bug reports: 2.7 days before, 3.2 after.

Same machine, three times the input.

Before you reach for the obvious objection: I stress-tested the classifier. A stricter rule that only accepts a version string in real Bun context (a build hash, or next to the template's "What version of Bun is running?") moves the counts by under 1% and leaves both fix rates identical to one decimal. If anything it makes the jump slightly bigger, 3.6x instead of 3.5x. The repo has the robustness script and an independent verification that re-derives all 31 published figures from the frozen data.

Meanwhile the process around the code seized up. Last November, only 1–3% of new Bun issues went unlabeled; triage was already slipping through spring, and since the merge roughly half of new issues never get a label at all. Bun shipped 12 stable releases in the six months before May 14. Since: zero, in 89 days. The longest gap between any two Bun releases across 2024–2026 had been 27 days. Every stable user today still runs the Zig binary the project supposedly left behind.

Whether that's caution or paralysis I can't tell from outside. Probably some of both.

This was Rust's best-case scenario

The flat fix rate gets interesting once you notice the conditions it happened under.

A port is the friendliest possible job for a rigid language. The spec was frozen: behave exactly like old Bun. A million-assertion TypeScript test suite sat there as an oracle, checking every step. For 11 days, the requirements did not move. Even people who can't stand Rust concede it this territory. The much-shared "Leaving Rust gamedev after 3 years" essay, written by someone with over 100k lines of Rust behind them, says it flat out: "Rust fits very nicely in the low level algorithmic areas where one knows exactly what the problem is and just needs to solve it."

So Rust got its dream conditions, plus an AI to absorb every borrow checker complaint, and delivered a fix rate identical to the Zig era and a release pipeline in a coma.

Your project is not a port

This is where I stop reporting and start arguing.

I've spent over a decade building software, mostly products, and almost none of it resembled that port. There was no oracle. The spec was a Slack thread and a mockup. Requirements changed the first time a user touched the feature, then changed again. Half the job was finding out what we were supposed to build, usually by building the wrong thing first.

That's the regime where language rigidity hurts, and the people saying so are not beginners who bounced off the borrow checker in week one. The gamedev essay again: "the borrow checker forces a refactor at the most inconvenient times." John Nagle, of Nagle's algorithm, some 45k lines of Rust into a metaverse client, seconds it: "It's quite common for some change to require extensive plumbing work", noting the C#/Unity teams on the same problem move faster than he does. A 25-year veteran of Epic and Valve spent 14 months building his game on Rust, redid it in Unity in six weeks, and shipped. Graydon Hoare, the man who created Rust, wrote in 2023 that shipped Rust is far from the language he wanted, that he'd argued against explicit lifetimes, first-class borrows, and the trait system. And in Rust's own annual survey, the top worry among its users about the language's future is "Rust becoming too complex", at 43%.

Rob Pike caught endless grief for his reason Go is simple: "our programmers are Googlers, they're not researchers... They're not capable of understanding a brilliant language but we want to use them to build good software." Every time I reread that quote it sounds less like an insult and more like the only statement in language design anchored in how teams actually work. Your teammates are busy and distracted. So are you, so am I. A language that assumes otherwise sends the bill exactly when a deadline and a requirement change arrive together.

Steelman break

The counterevidence is real and I won't hide it. Google reports Rust changes in Android roll back 4x less often than C++ and spend 25% less time in review; across 1,000+ of their developers they found no productivity penalty. Dropbox rewrote its sync engine, the most edge-case-infested thing they own, in Rust and called the bet a force multiplier.

Look at what those wins share, though. Android platform code and a file-sync engine are among the most precisely specified software in existence. The invariants are known before anyone writes a line. Both camps in this fight agree on the boundary without noticing they agree: when you know exactly what you're building, rigidity is scaffolding. When you don't, you're paying interest on it every sprint.

The question was never "is Rust good". It's what share of your roadmap is spec-frozen execution versus "we'll understand this feature after we ship it twice". Be honest about the split. On most teams I've seen, it's one part execution to five parts figuring things out.

"But AI pays the complexity tax now"

The newest argument for maximal rigidity: language difficulty stopped mattering, because agents write the code and the compiler verifies them. There's real research behind it. An LLM looping on rustc's error messages fixes about 74% of real-world compile errors on its own. Constrain the model's decoding with the type system and compile errors drop by more than half.

Bun is the largest field test of that thesis to date, and the result is lopsided: the machine half worked and the human half didn't. Claude satisfied the borrow checker a million lines' worth. Then triage collapsed, review became the choke point, and nothing shipped for three months. Kelley's jab lands here whether you like Zig or not: "It's not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in [a] million lines of unreviewed slop?"

Worth adding: Armin Ronacher, who ran Rust in production at Sentry for years, experiments constantly with coding agents and recommends Go for them, not Rust. In his tests, putting strict type checking inside the agent loop made results worse.

A compiler can prove what the code does. It can't prove that's what the code was for. That second question is the entire job, it stays with humans, and no amount of language rigidity shrinks it.

Where I land

Disclosures first, because this story is soaked in them: Anthropic acquired Bun in December 2025, the rewrite ran on a prerelease Claude model, Sumner's speed and cost numbers are self-reported, and I did this analysis with Claude's help too.

But the data as of today says: in the single most favorable setup a rigid language will ever get, frozen spec, perfect oracle, tireless AI labor, it produced no measurable improvement in how bugs get handled, while the humans around it lost the ability to ship. Your project runs with none of those advantages. Your spec moves weekly. Your oracle is whatever the PM remembers agreeing to. Your test suite is not a million assertions.

Pick the strict, complex language when the problem is genuinely pinned down. It will hold the line for you there. For everything else, and I think that's most software, complexity is a tax collected on every change, and the compiler's certainty is always about yesterday's requirements.

The numbers, the scripts, and the full study are in the repo. If you think I've read the data wrong, that's what the comments are for.

Your SPA probably leaks memory. Your Playwright suite can catch it

Alex — Thu, 06 Aug 2026 11:39:35 +0000

[soak] drawer — 80 iterations
    base     heap   2.83MB  nodes    675  listeners   163  docs 1
    @   40   heap   3.50MB  nodes   5675  listeners   163  docs 1
    @   80   heap   4.18MB  nodes  10675  listeners   163  docs 1
    delta  heap +1.36MB  nodes +10000  listeners +0  docs +0
    per-iteration  heap 17.35KB  nodes 125.00
    nodes  ++++++++  +10000 total, biggest stretch 13% of it (spread out, so accumulating)

That's a memory leak failing a CI build. Playwright doesn't do this out of the box, and memory is a blind spot for e2e suites in general: here a store subscriber outlives the drawer it closes over, every open/close cycle keeps 125 DOM nodes alive, and the tests stay green the whole time. In development you never notice this stuff, you reload the page every few minutes anyway. The person who notices is the one with your app in a pinned tab since morning.

Recently I read Den Odell's Your SPA is leaking memory — soak test it and the framing stuck with me: stop hunting leaks with a profiler after someone complains, catch them in CI like any other regression. I liked it enough to turn it into a package. playwright-soak runs inside the Playwright suite you already have. You give it a flow, say open a drawer and close it, and it repeats that flow a few hundred times with forced garbage collection in between, and fails the test if memory keeps piling up.

npm install -D playwright-soak

The bug that always ships

The leaks worth chasing are the small ones that repeat per interaction. A one-time allocation costs you a few megabytes and nobody cares. A subscriber that's recreated on every drawer open, or a listener added without a matching removal, grows without bound. And it survives code review easily, because the bug is a missing line, not a wrong one.

Nothing in a typical pipeline catches it either. Unit and e2e tests run a flow once, and Lighthouse only ever sees a fresh page load. Profiling in DevTools would show it, but someone has to remember to do that, and nobody profiles the drawer they just refactored. So the leak ships and comes back weeks later as a vague complaint that the app "gets slow after a while". In the Performance Monitor the complaint looks like this:

The fix is boring on purpose: make leak detection a test, so it runs on every PR whether anyone remembers or not.

Why the obvious test doesn't work

If you've tried to write that test before, you probably measured the heap before and after the flow and asserted the difference is small. I started there too. It fails in both directions.

It flags healthy apps, because plenty of legitimate allocation happens once and stays: a cache filling up on first use, a global listener registered on first interaction. And it trips over the browser having a life of its own. In one clean run I watched Chromium register an extra listener around iteration 50 and drop it again before iteration 75. Land that blip on your final reading and the build fails over a listener the browser itself was about to remove. Tests like that get deleted within a month, which I suspect is why most teams don't guard against leaks at all.

Two numbers can't tell "grew once" apart from "grows every time", so playwright-soak takes readings all the way through and judges the shape instead. A leak repeats, which means its growth spreads evenly across the run. Caches and browser blips pile all of theirs into one moment. This gets counterintuitive: a flow that ends +2 listeners can pass while one that ends +4 fails, because the pattern matters and the size doesn't:

listeners ·+·····+·  +2 total, growth piled in one spot (a one-off step, passes)
listeners ·+·+·+·+·  +4 total, growth spread across the run (accumulating, fails)

That's what makes it stable enough to gate a PR.

What a run looks like

import { test } from "@playwright/test";
import { attachCDP, expectNoLeak, formatSoak, soak } from "playwright-soak";

test("opening and closing the drawer does not leak", async ({ page }) => {
  await page.goto("/dashboard");

  const client = await attachCDP(page);
  const result = await soak({
    client,
    flow: async () => {
      await page.getByRole("button", { name: "Open" }).click();
      await page.getByRole("button", { name: "Close" }).click();
    },
  });

  console.log(formatSoak("drawer", result));
  expectNoLeak(result);
});

soak warms up first (so one-time allocation lands before the baseline), then runs the flow 200 times with readings every 25 iterations. Each reading covers four counters, and each catches a different kind of leak:

"nodes"     - detached DOM kept alive by a closure, a cache or a stale ref
"listeners" - handlers added without a matching removal
"documents" - iframes that mount per interaction and never unmount
"heap"      - everything else: closures, growing arrays, unbounded caches

The last row matters more than it looks. A stale callback that closes over a component tree, or an in-memory log nobody bounds, moves zero nodes and zero listeners. Only the heap gives it away, so expectNoLeak also checks the heap curve: a real leak keeps climbing at the same rate all run, while warm-up allocation flattens out.

Typing flows aren't flaky, they're billed

Chromium keeps roughly one DOM node per text-editing gesture. That's the browser's own bookkeeping, not your framework; a bare document.createElement('input') bound to nothing shows the same growth. Type a five-letter word 200 times and that's a thousand nodes of pure browser overhead sitting on top of whatever your app does. It looks exactly like a leak. No wonder typing soak tests have a reputation for flakiness.

So the package measures the browser's own rate against a throwaway control input and budgets for it:

const typingCost = await calibrateTypingCost(page, client, type);
const result = await soak({ client, flow: () => type(page.locator("#name")) });

expectNoLeak(result, { typingCost });

With that budget in place, typing flows are as stable as click flows.

Smoke alarm, not debugger

playwright-soak tells you that a flow accumulates memory, and which flow. It does not tell you which object leaked or what's retaining it. That job belongs to memlab, which diffs heap snapshots and gives you actual retainer paths, but is Puppeteer-only and heavy enough that nobody runs it on every PR.

In practice you want both: soak tests on every PR, memlab when one of them goes red and you need to know what's actually holding the memory.

Try it

If you have a Playwright suite and an app people keep open all day, write one soak test for your most-used flow and see what comes back.

npm install -D playwright-soak

No runtime dependencies. Chromium only, since the readings come from the Chrome DevTools Protocol. The repo ships a small example app where every kind of leak has a matched broken/fixed pair of tests, and a set of TanStack Intent skills so a coding agent can write these tests for you. The source is on GitHub, MIT licensed. If it catches something in your app, or misses something it shouldn't have, open an issue, I want to know. And a star on the repo is the easiest way to help the next person find it.

I built llm-queue: one local model, one queue

Alex — Mon, 29 Jun 2026 09:44:15 +0000

BEFORE  two processes, two private queues, one small GPU

  jobbot       ─┐
                ├──▶  Ollama
  slop filter  ─┘

  both hit the model at once → reload thrash, ~4x slower


AFTER  one shared queue over HTTP, in front of one model

  jobbot       ─┐
                ├─ HTTP ─▶  llm-queue ─ fetch ─▶  Ollama
  slop filter  ─┘

  one request at a time → the model loads once and stays put

I have two side projects that both lean on a local LLM, and for a while they kept making each other slow. Fixing that turned into a small package called llm-queue: one process that owns the model and runs every request, from every program, through a single serialized priority queue behind an OpenAI-compatible HTTP API.

The two projects are jobbot, a bot that scrapes job boards and classifies each posting with a local model (is this actually a job? is it remote? does it want a language I don't speak?), and a browser extension that hides LinkedIn feed slop the same way. One's a Node cron job, the other's an MV3 service worker. Both reach for the same Ollama model on my laptop.

The problem: one model, one small GPU

Two facts make concurrency a bad bet here. A local model answers one request at a time, so parallel callers don't actually run in parallel. And my GPU has 6 GB, which barely fits a single model, so there's no room to load a second one beside it.

So the obvious plan, let both projects run and hit Ollama whenever they want, fell apart fast. When two processes hit it at once with different models, or even the same model at a different context size, Ollama unloads one and loads the other on every call. That reload is gigabytes off disk, and it turns out to be most of your wall-clock time. I benchmarked it to be sure: throughput dropped to about a quarter of what a single client got. Concurrency made things slower. About four times slower.

Pinning both models in memory doesn't save you either. They don't fit, so they spill onto the CPU and fight over cores, and now both are slow. On this hardware, nothing beats one request at a time.

The fix: one shared queue

The answer is boring. Don't run requests in parallel. Put them in one line and serve them one at a time. The line just has to be global, shared across every process, and the one thing all my programs already speak is HTTP.

So llm-queue is a single process that owns the Ollama endpoint and the model. Everything else talks to it over HTTP. One queue, one model, one request in flight, ever, so the model loads once and stays put.

There's one wrinkle: not every request is equal. jobbot fires off dozens of background classifications while it scrapes, but when I click a job to draft an application, I'm waiting on that one answer right now. So it's a priority queue. A request marked priority jumps the waiting backlog, though it never interrupts whatever's already running.

Making it speak OpenAI

I didn't want to ship a client library. Everything already speaks the OpenAI API, so I made the service speak it too. Point any OpenAI client at http://localhost:11500/v1 and you get the queue for free, no SDK swap:

import OpenAI from 'openai'

const client = new OpenAI({ baseURL: 'http://localhost:11500/v1', apiKey: 'unused' })
const r = await client.chat.completions.create({
  model: 'granite4.1:8b',
  messages: [{ role: 'user', content: 'hello' }],
})

The two knobs the queue needs don't exist in the OpenAI shape, so they ride along as extra body fields. priority is the line-jump from above. numCtx is the context window a client wants; the service runs at the largest size any client asks for and never shrinks back, so the model doesn't reload to a smaller window mid-day. Stock OpenAI servers ignore fields they don't recognize, so the exact same request still works against the real API. It just drops the two extras.

The service also hands back the model's raw string and nothing else. No JSON parsing, no schema validation. My two consumers parse the output differently, and every time I pictured "helping" them inside the queue, I was really just guessing wrong on their behalf. The queue does the one job only it can do: serialize access, with a per-attempt timeout and one retry. The rest is the caller's problem.

Two projects, one queue, no shared code

The part I like most is that neither consumer depends on the package. jobbot doesn't npm install llm-queue. Neither does the extension. They just POST to the running service:

const res = await fetch('http://localhost:11500/v1/chat/completions', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    messages: [
      { role: 'system', content: SYSTEM_PROMPT },
      { role: 'user', content: pageText },
    ],
    response_format: { type: 'json_object' }, // ask for JSON
    numCtx: 8192,                             // llm-queue extension
  }),
})
const { choices } = await res.json()

That's the whole integration. The extension, running in a completely separate browser, sends its own classifications to the same service. (Browsers block a content script from calling localhost, so that fetch lives in the service worker, and the service sends permissive CORS headers so it goes through.) The two projects have never heard of each other. They don't share a queue in code. They share one in production, because there is exactly one and it's reachable over HTTP. On a 6 GB GPU that's the difference between a model that loads once and one that thrashes all day.

Building it

It's small on purpose: about 700 lines across the queue, the HTTP server, the fetch transport, and the CLI. TypeScript, ESM, Node 20+, almost no dependencies, talking to Ollama over plain fetch. tsup builds it, vitest covers the queue and the server, and release-please turns my conventional commits into the version bump, changelog, and npm publish on merge.

Try it

If you run a local model and more than one thing wants to use it, this is the missing piece:

npm i -g llm-queue
OLLAMA_MODEL=granite4.1:8b llm-queue serve   # → http://127.0.0.1:11500

Then point anything OpenAI-shaped at http://localhost:11500/v1, or just fetch it directly. It's on npm, the source is on GitHub, MIT licensed. If it saves your local model from thrashing the way it saved mine, a star on the repo is the easiest way to help the next person find it.

Testing Next.js SSR with Playwright: record real responses instead of writing mocks

Alex — Thu, 18 Jun 2026 11:56:04 +0000

If you write Playwright tests for a Next.js app, you've probably hit this wall. You reach for page.route() to stub an API call, the test still fails, and after twenty minutes you realize the request you're trying to mock never went through the browser at all. Your server component fetched it during SSR. Playwright never saw it, because Playwright drives a browser, and that fetch happened in Node.

This is the gap nobody upstream has closed cleanly. routeFromHAR is browser only. The Next.js team has an open discussion about mocking server actions in e2e tests and another about middleware, both still unresolved. There's a four-year-old Playwright feature request asking for exactly the thing you want: record network requests, save them as ready-to-use mocks. Still open.

So people work around it. The current options are all variations on the same idea: hand-write the mocks.

The hand-written mock treadmill

MSW is the popular answer. It intercepts in both the browser and Node, and since Next.js 15 it can finally see server-side calls. But you still author every handler by hand, keep its shape in sync with the real API, and update it when the backend changes. MSW also keeps its state globally, so running tests in parallel gets fiddly fast. Mocky Balboa, the experimental Next.js test proxy, request-mocking-protocol, they all land in the same place. You're maintaining a second, fake copy of your API forever.

I did this for a while and got tired of it. The mocks drift. The real API adds a field, your mock doesn't have it, the test passes anyway, and you ship a bug that only shows up against production data. The whole point of an e2e test is to run against something that behaves like the real thing, and a mock I typed out by hand at 2am is the opposite of that.

What I actually wanted was the VCR pattern. Ruby had this nailed years ago: hit the real API once, save the interaction to a file, replay it from disk on every run after that. The JavaScript version of this was Polly.js from Netflix, but it's effectively unmaintained now (last meaningful push was a while back), and it never had a clean story for SSR plus Playwright anyway. The throne was empty. So I built test-proxy-recorder.

The idea: record once, replay forever

The model is simple. There are two modes.

In record mode, your app talks to the real backend through a proxy. The proxy forwards everything and writes each request and response to disk as it goes.

In replay mode, the proxy serves those saved responses straight from disk. No backend, no network, same bytes every time.

                        Record mode                          Replay mode

  Browser/App ──> Proxy ──> Real API        Browser/App ──> Proxy ──> Disk
                    │                                         │
                    └──> saves to disk                        └──> serves saved responses

The trick for SSR is that it's a proxy, not a browser hook. Your Next.js server fetches go through it just like browser fetches do, so it captures both. Browser-side requests get recorded separately as HAR files (the format Playwright already understands), and server-side requests land in .mock.json files. You don't think about which is which day to day, you just record and commit.

The thirty-second version of the pitch: record your tests against the real API, delete the backend, run the tests again, watch them pass. There's a short video of exactly that on the site, test-proxy-recorder.dev.

Wiring it into Next.js

The only genuinely Next-specific part is letting the proxy know which test a server-side fetch belongs to. The browser request carries a header that ties it to the running test; you forward that same header on your SSR fetches. A tiny middleware does it for you:

// proxy.ts  (Next.js 16 middleware convention)
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { setNextProxyHeaders } from 'test-proxy-recorder/nextjs';

export function proxy(request: NextRequest) {
  const response = NextResponse.next();
  setNextProxyHeaders(request, response); // no-op in production
  return response;
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};

That's a no-op in production, so it's safe to leave in. On Next.js 15 and earlier the file is middleware.ts with the function named middleware, otherwise identical.

Then point your API base URL env var at the proxy in dev and test only, and write a normal Playwright test:

import { test, expect } from '@playwright/test';
import { playwrightProxy } from 'test-proxy-recorder';

// Flip to 'record' to hit the real API and refresh recordings.
const MODE = 'replay' as const;

test.beforeEach(async ({ page }, testInfo) => {
  await playwrightProxy.before(page, testInfo, MODE, { url: /localhost:8100/ });
});

test('homepage loads', async ({ page }) => {
  await page.goto('/');
  await expect(page.getByText('Welcome')).toBeVisible();
});

Record once with MODE = 'record', switch it back to 'replay', commit the e2e/recordings/ folder, and CI never touches the network again. If the setup above looks like a few too many moving parts, npx test-proxy-recorder init scaffolds the config, the fixture, the teardown, and the package scripts in one shot.

The parts that were actually hard

The recording loop is the easy 80%. The interesting problems are the reasons people abandon record-replay tools, so most of my time went there.

Secrets. A record-replay tool quietly tells you to commit real API responses to git, which means it's one missed review away from committing a live token. So redaction is on by default now. Authorization, Cookie, and Set-Cookie get stripped before anything hits disk, and you can add your own header names or body regexes for API keys. It's safe because replay matching ignores those headers anyway, so scrubbing them never breaks playback. For login itself, the recommended pattern keeps the whole auth flow out of recordings: run it in a Playwright setup project with the proxy in transparent mode and persist storageState to a gitignored file. There's a working example against a real AWS Cognito pool in the repo.

WebSockets. This one surprised me. Recording a socket is fine, but how do you replay it? Real time? Then a test that watches a price ticker takes as long as the recording did. So the default replays server messages as a burst on connect, which is fast and deterministic, since tests usually assert on the state that arrived, not the timing. If you do care about timing, --ws-timing original re-paces the messages from their recorded timestamps. I validated it against Binance's live BTC-USD feed: record the real stream once, replay deterministic prices on CI with no exchange account.

Non-deterministic requests. Timestamps, UUIDs, CSRF tokens in the URL. This is the classic record-replay killer, and I'll be honest, it's the area still getting work. Matching is currently method plus path plus a hash of the query string, and configurable matchers for volatile params are the next thing on the list. If your URLs are stable, you won't notice. If they're full of cache-busters, that's the rough edge today.

When this is the wrong tool

It's not a unit-test mock. If you want to assert "the UI shows an error when the API returns 500," hand-writing that one response with page.route() is faster and clearer. test-proxy-recorder earns its keep when you have real, complicated API responses you don't want to reproduce by hand, especially across SSR and browser and sockets in the same test run. It also assumes you can reach the real backend at least once to record. Fully air-gapped from day one, it can't help you.

Try it

npm install --save-dev test-proxy-recorder
npx test-proxy-recorder init

The site is test-proxy-recorder.dev, and the repo is on GitHub with runnable examples for Next.js 16, a Chrome extension hitting X's API, the crypto ticker, and a real-auth Cognito app. MIT licensed.

If you've been fighting Playwright over SSR mocking, give it a run against your own API and tell me where it breaks. Open an issue, send a PR, or come ask in the Discord if you get stuck wiring it up. The honest edges above are exactly the kind of feedback that moves the roadmap.

Attempt to stop npm postinstall scripts from stealing your secrets

Alex — Thu, 14 May 2026 13:18:36 +0000

Every time you run npm install, you're rolling dice. A postinstall script from some dependency three layers deep gets unrestricted access to your filesystem. .env files, SSH keys, cloud credentials, your whole $HOME directory. It can read it all, and it can ship it anywhere because the network is wide open.

In May 2026, a supply chain worm compromised 84 npm packages that had valid SLSA Build Level 3 provenance. Postinstall scripts siphoned CI/CD secrets, SSH keys, cloud credentials, crypto wallets. It spread quietly because everything looked legitimate. The attack got nicknamed "Shai-Hulud" after the Dune sandworm that swallows everything in its path.

ringfence blocks this class of attack at the OS level. Zero config. It wraps your package manager commands in a sandbox so a compromised dependency can't see anything worth stealing.

One thing to be clear about: ringfence doesn't stop you from installing malicious code. If a package is bad, it still gets installed. What ringfence does is make sure that the postinstall script running on your machine can't read your secrets, can't touch your SSH keys, can't sniff your .env. It sits between the compromised package and your filesystem, not between you and the registry.

How it works

Ringfence is basically a shim. It drops a handful of shell scripts at ~/.ringfence/bin/ and shoves that directory onto the front of your PATH. When you type npm install, the shim catches it and asks: does this command trigger lifecycle scripts? If yes, it goes through the sandbox. If it's npm run build or npm test or npx tsc, it passes straight through to the real binary. You pay about 80ms of Node startup overhead either way.

On Linux it leans on bubblewrap. The sandbox replaces $HOME with an empty tmpfs. After that it selectively brings back only what the package manager needs: .npm, pnpm's store directories, yarn's cache, and registry auth files like .npmrc (those are mounted read only). ~/.ssh, ~/.aws, ~/.gnupg stay invisible because they were never added to the blank tmpfs in the first place.

Next, every secret looking file in your project directory gets masked with /dev/null. .env, .env.*, *.pem, id_rsa*, credentials.json, service account JSON files, and a bunch of other patterns. The files are there, they're just zero bytes.

Environment variables that smell like secrets get unset: anything with TOKEN, SECRET, API_KEY, or PASSWORD in the name, plus prefixes like AWS_, GITHUB_, NPM_, DATABASE_. The network stays open. Registries, git deps, tarball URLs all work fine. The defense isn't blocking exfiltration. It's making sure there's nothing to exfiltrate.

On macOS there's no bubblewrap (no Linux namespaces), so ringfence falls back to Docker. The project directory gets copied to a temp location with all secret files filtered out, mounted into an ephemeral node:lts container with HOME=/work, and after the install finishes only the non-secret files sync back. It's slower than the Linux path, but the security model is the same.

The test suite includes a leak probe: a synthetic malicious script that tries reading .env files, SSH keys, ~/.aws/ credentials, ~/.gnupg/ keys, and secret shaped env vars. Under ringfence, every single probe fails.

Install

npm i -D ringfence && npx ringfence

Two commands. It detects your OS, installs bubblewrap if you're on Linux (using whatever package manager your distro ships), validates Docker if you're on macOS, creates shims for npm/pnpm/yarn/bun, and adds itself to your shell's PATH via .bashrc, .zshrc, and .profile.

After that, every npm install, pnpm add, yarn add, or bun add runs sandboxed. You don't set anything up per project. Commands like npm run dev and npm test and npx go through untouched, those aren't install commands.

To get rid of it: npx ringfence-uninstall. Cleans up the PATH entries and deletes ~/.ringfence/.

Stuff worth knowing

Secret files become zero byte files, not missing files. Making a file absent risks breaking scripts that check for existence. An empty read is safer than ENOENT. The tradeoff: if a dependency genuinely needs a .env file with actual content during install, things break. The README is upfront about this.

Ringfence unsets env vars and masks files. Your GITHUB_TOKEN doesn't leak through the environment just because it wasn't stored in a .env file.

bwrap containers launched by ringfence include --die-with-parent. If ringfence crashes, the sandboxed process dies too. No orphaned containers.

On macOS, packages removed during a container run stick around in node_modules until you clean them manually. The sync back doesn't delete files, it only adds or overwrites. Uninstalled packages linger.

Ringfence only protects install time, when lifecycle scripts fire. Once packages are on disk, npm start or node server.js runs with full host access. That's intentional. It's a supply chain guard, not a runtime sandbox.

No Windows support.

Why bother

The TanStack worm hit packages that had provenance. SLSA Build Level 3, verified. Provenance says where code came from, not what it does. That's the whole problem.

Ringfence is two commands and covers npm, pnpm, yarn, and bun on Linux and macOS. If you're installing dependencies on either platform, there's not much reason to skip it.

If you give ringfence a try, I'd love to hear how it goes. The macOS path in particular could use more real world testing, so feedback from Mac users is especially welcome. Bug reports, edge cases, or just "works fine on my machine" — all useful. Drop an issue on GitHub.

https://ringfence.pages.dev/

How I Built state-in-url: My Journey Turning the URL Bar into Real React State

Alex — Mon, 13 Apr 2026 13:39:54 +0000

I'm the developer behind state-in-url. The library lets you put real JavaScript values - numbers, Date objects, nested arrays, objects - directly into browser query parameters. It keeps full TypeScript support throughout. The hook behaves exactly like useState, but the state lives in the URL. It survives reloads. You can share the link and nothing gets lost.

Try the live demo at https://state-in-url.dev

Type in the form. Watch the URL change instantly. Refresh the page. The data stays exactly as you left it. The example sits right in the repo too.

This project grew from a frustration I hit again and again while working on dashboards and larger forms. State ended up split across local variables, a store, and the URL for sharing. Other libraries came close, yet they always added too much setup or turned everything into strings and dropped my types. I decided to build the version I actually wanted to use every day.

The repo now sits at 400+ stars on GitHub. Version 6.1.2 shipped a few weeks ago. It still surprises me that people use it. Here is the full story - the frustrations, the choices that worked, the testing struggles, and what stayed with me afterward.

The Problem

You have probably faced this situation. A page holds filters or a detailed form. State lives in three places at once. Local component values. Maybe a store. Plus the URL so users can bookmark or share their exact view. Syncing it all felt like constant extra work.

I wanted the hook to stay dead simple. Return state and a setter, just like useState, but with TypeScript awareness of the exact shape. Real data types that survive the URL round trip. Clean support for Next.js App Router with SSR, plus React Router and Remix. No interference with other query parameters. And keep the whole thing tiny - zero runtime dependencies, under 2 KB gzipped.
That became my starting point in spare time.

The solution

The choice I remain happiest about is straightforward. I used one plain JavaScript object for both default values and the type definition. Without separate schema or heavy generics. You write code like this

export const formState = {
 name: '',
 age: undefined as number | undefined,
 agree_to_terms: false,
 tags: [] as { id: string; value: { text: string; time: Date } }[],
} as const;

type FormState = typeof formState;

Pass that object to the hook and everything flows. Types and defaults work out of the box.
For shared state with useSharedState, I relied on a single JavaScript object. Components subscribe to changes, without React Context. It handled cases where unrelated parts of the app needed the same data without added complexity.
The encoder and decoder required some tuning. The goal was a readable URL that still preserved real types. Encoding a larger object takes roughly a millisecond on my machine.

Building the Library and the Framework Challenges

I structured the project as a pnpm monorepo. TypeScript dominates the codebase. Core logic lives in one package. Thin adapters cover Next.js, React Router, and Remix. Rollup manages the build. Nothing overly complicated.
Next.js App Router created the biggest difficulties. The way searchParams moves between server and client components caused repeated issues. I added a small header workaround to carry data through on the server side. Hydration stayed intact. Remix and React Router presented fewer obstacles, yet I still needed to handle history modes, push versus replace, and debounce settings so the URL stayed calm during typing.

Here is a real section from the Next.js 15 demo that runs live at state-in-url.dev

'use client'
import { useUrlState } from 'state-in-url/next';
import { formState } from './formState';

function Form() {
   const { urlState, setUrl, setState } = useUrlState(formState, { searchParams });
    return (
     <input
       value={urlState.name}
       onChange={(e) => setState(curr => ({ …curr, name: e.target.value }))}
       onBlur={() => setUrl()} // update URL on blur for smoother typing
     />
     {/* tags, dates, checkboxes - all typed correctly */}
   );
}

The code stays simple. It is just state that happens to live in the URL.

Testing was hard but important

I needed the library to feel reliable across frameworks and browsers. Real example apps for Next.js 14+, React Router v6+, and Remix live in the repo. Vitest covers the encoder and decoder basics. More real world tests cases covered with Playwright running full end-to-end tests in Chrome, Firefox, and Safari.

A fix in one place often broke something elsewhere. The commit message "Tests finally passing on Next.js 15" appeared more times than I care to count. It took quite few attempts adjusting Playwright configurations and the CI matrix.
GitHub Actions now runs linting, building, unit tests, and the complete browser suite on every push and PR. Semantic-release automates version bumps, changelog updates, GitHub releases, and npm publishing. Husky keeps commits tidy. Once the pipeline ran smoothly, maintaining the library stopped feeling like a burden.

Launching

I published to npm. The README received every recipe I could gather - debounced updates, resetting to defaults, multiple independent state objects on one page. I linked the live demo and waited.
The first stars arrived and felt surprisingly satisfying. Issues opened, mostly kind ones. Solid CI let me ship fixes quickly. I wrote the honest limits in a separate Limits.md file. URLs hold only so much - around 12 KB stays practical. Readers seemed to value the directness.

Lessons

Making the API match useState exactly shaped every other decision and made the library pleasant to use.
That single object for shape and defaults removed a lot of complexity.
Testing inside real frameworks felt painful yet essential - skipping it would have limited adoption.
Automating releases and chores with semantic-release and GitHub Actions turned maintenance into something manageable.
Keeping the bundle tiny happened on purpose. I watched the size and avoided dependencies deliberately. Would I change anything today? I might add Svelte or Astro support earlier. Hash routing could be interesting. The roadmap still has room to grow.

If this sound interesting give it a try

pnpm add state-in-url

The demo lives at state-in-url.dev. The repository sits here. Star it if the approach fits your work.

I would enjoy hearing about the URL-state problems you encounter. Leave a comment. Open an issue. Send a pull request. Sharing the process publicly became one of the most rewarding aspects.
Happy coding, MIT license, of course. Build something useful with it.

New portfolio website

Alex — Mon, 15 Sep 2025 15:24:22 +0000

Tried few new things this time.

Created an initial design with V0, had to refactor a lot, and change many details.

Chose an Astro framework for a minimal footprint on bundle size, and the best performance.

It's quite simple, but hopefully worth it. Will appreciate any feedback.

Portfolio link

React rendering quiz

Alex — Thu, 08 May 2025 09:55:24 +0000

A simple quiz to illustrate how React rendering works.

import React from "react";

export default Parent;

function Parent() {
  console.log("1");
  React.useEffect(() => {
    console.log("2");
  }, []);

  return (
    <>
      Parent component
      <br />
      <Child />
    </>
  );
}

function Child() {
  console.log("3");

  React.useEffect(() => {
    console.log("4");
  }, []);

  return <span>Child component</span>;
}

Try to guess what will be printed to console.

Answer

Some explanation:
⇾ First Parent is parsed and rendered, without useEffect,
⇾ after that Child, when there is no more nested components is turn of async hooks
⇾ React will run useEffect from children to parents.

Few more logs, probably related to dev mode.

Breakpoints variables with pure CSS

Alex — Thu, 01 May 2025 10:28:18 +0000

In CSS can use variables most of the time.

:root {
  --color-main: red;
}

But, can't use variables in @media queries.

@media (min-width: var(--br-md) {
/* will never work */
}

Unexpected solution is to use @container queries:

:root {
  --is-tablet: true;

  @media (min-width: 1200px) {
    --is-tablet: false;
  }
}

...

@container style(--is-tablet: false) {
  .content {
    grid-template-areas:
      'header aside'
      'feed   aside';
    grid-template-rows: minmax(7.16rem, 17.6rem) minmax(7.16rem, max-content);
    grid-template-columns: var(--feed-columns);
  }
}

Only downside is Firefox lacks support of it, but it doesn't do so well on many things.

Next.js usage

In Next.js can use postcss-custom-media plugin to achieve same outcome, for all browsers and with css modules.

How it looks like

@custom-media --is-desktop (min-width: 1200px);

...
@media (--is-desktop) {
  .content {
    grid-template-areas:
      'header aside'
      'feed   aside';
    grid-template-rows: minmax(7.16rem, 17.6rem) minmax(7.16rem, max-content);
    grid-template-columns: var(--feed-columns);
    gap: 1.75rem;
    width: 100%;
  }
}

Setup

Official docs

Install all dependencies:
npm install --save-dev postcss autoprefixer postcss-flexbugs-fixes @csstools/postcss-global-data postcss-custom-media postcss-preset-env
Add PostCSS config to package.json:

  "postcss": {
    "plugins": [
      "postcss-flexbugs-fixes",
      [
        "@csstools/postcss-global-data",
        {
          "files": [
            // need to use file with global variables here
            "core/styles/vars.css"
          ]
        }
      ],
      "postcss-custom-media",
      [
        "postcss-preset-env",
        {
          "autoprefixer": {
            "flexbox": "no-2009"
          },
          "stage": 3,
          "features": {
            "custom-properties": false
          }
        }
      ]
    ]
  }

Minification bugs

Alex — Fri, 04 Apr 2025 11:37:21 +0000

Today I learned that minification in JS is a double-edged sword.

It was a weird bug, took me quite some time to figure out that problem in minification.
Stopped using terser for the same reasons.

Next.js at refactor or extinct situation.

Alex — Fri, 13 Dec 2024 08:21:03 +0000

Next.js become a hype of the day (or year), but it's slowly suffocating under the weight of technical debt.

There are many big enough pain points with Next.js:

Slow and painful dev mode, if you changed something and need to check more than 1 route, you need to wait till route compiled. Next.js server also uses few gigabytes of RAM. Turbopack complaining about perfectly working TS code, and struggle to understand :global in CSS modules, still not production ready.
Whole workflow is intended to be used mostly with server components, but in real world applications big chunks of applications use client side JS, because it's way faster and more responsive.
Routing is a mess, pages router was good enough, but App Router it's just a wrapper around it, that lead to more bugs and complexity.
Vercel service is good, but if popularity of your project going parabolic, costs will follow - 96k bill

Just stumbled upon a bug when useParams hook periodically returning dead wrong values.

Searched for existing issues, didn't find any, tried to open issue on their GitHub, can't do than without providing reproducible example. Repository is private, I can't share all of it. And I can't pinpoint the exact condition for a bug to appear in a big enough codebase.

Similar situation was with Cypress testing framework. For years people opened issues about flaky tests and memory leaks, all of them were closed, because can't properly reproduce them. Easy to make something works in a TODO app, real challenge is a big and complex application. Usually, people work under NDA and can't just share the whole repository.
After some time Playwright came and Cypress isn't relevant any more.

Let's see approximate quality ratio, by calculating stars to bugs for Cypress.

47600 stars / 14600 bugs = 34 quality

Cypress's successor - Playwright

67_700 stars / 692 issue = 97 quality

I'm aware that many bugs issues it's just misunderstanding or duplicates, still, if something confusing in a documentation/example, it is a con of software.

Let's see about Next.js

128_000 stars / 3000 bugs = 42 quality

Let's see React.js repo for context

230_000 stars / 754 bugs = 305 quality

And Remix.js repo (SSR framework from react-router team)

30_300 stars / 295 bugs = 102 quality

All of this just my opinions, but it's backed by years of experience with different frameworks/libraries and observations.

Beyond console.log

Alex — Sun, 24 Nov 2024 09:49:53 +0000

intro

As much as I hope that things will always work from first try, better to be prepared to debug it. console.log remains the main tool to do it, because it is the simplest and fastest.

Few console methods are known to everybody, log, warn and error.

Going deeper

There are more tricks to it.

`count`

For example, if you need to count how many times component re-render can use console.count, e.g. console.count('comp1')

`group` and `groupCollapsed`

Can log some info in a collapsed group with console.groupCollapsed, great in case of many error messages, when they printed collapsed it's less distracting, but Node.js/Sentry probably will print all expanded.

After click

styling

Can use some CSS

`dir`

Can log properties of an object with console.dir

objects

Can log few objects with curly braces like console.log({ obj1, obj2 }), instead of console.log('Ojb1', obj1)

`assert`

Can assert things with console.assert

`time`

Can measure how long some operation takes with console.time

`trace`

Print a stack trace with console.trace()

`clear`

Clear things up with console.clear()

Check out great old post - https://dev.to/lissy93/fun-with-consolelog-3i59

DEV Community: Alex

I counted every Bun bug before and after the Rust rewrite

What the tracker shows

This was Rust's best-case scenario

Your project is not a port

Steelman break

"But AI pays the complexity tax now"

Where I land

Your SPA probably leaks memory. Your Playwright suite can catch it

The bug that always ships

Why the obvious test doesn't work

What a run looks like

Typing flows aren't flaky, they're billed

Smoke alarm, not debugger

Try it

I built llm-queue: one local model, one queue

The problem: one model, one small GPU

The fix: one shared queue

Making it speak OpenAI

Two projects, one queue, no shared code

Building it

Try it

Testing Next.js SSR with Playwright: record real responses instead of writing mocks

The hand-written mock treadmill

The idea: record once, replay forever

Wiring it into Next.js

The parts that were actually hard

When this is the wrong tool

Try it

Attempt to stop npm postinstall scripts from stealing your secrets

How it works

Install

Stuff worth knowing

Why bother

How I Built state-in-url: My Journey Turning the URL Bar into Real React State

The Problem

The solution

Building the Library and the Framework Challenges

Testing was hard but important

Launching

Lessons

New portfolio website

React rendering quiz

Breakpoints variables with pure CSS

Next.js usage

Setup

Minification bugs

Next.js at refactor or extinct situation.

Beyond console.log

intro

Going deeper

count

group and groupCollapsed

styling

dir

objects

assert

time

trace

clear

Related

`count`

`group` and `groupCollapsed`

`dir`

`assert`

`time`

`trace`

`clear`