DEV Community: Alex

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

First really useful AI tool - AI code review

Alex — Thu, 14 Nov 2024 20:42:30 +0000

Finally, I found at least 1 really useful AI service.

The service

It's called CodeRabbit, the idea behind it is pretty simple, AI review code changes and give you recommendations how to fix it with explanation.

AI is working as pattern recognition, so, it's perfectly suitable for recognizing antipatterns in pull requests.

How it looks like

After PR created, GitHub action run and analyze changes. It's post summary like this:

The second comment contains recommendations:

Conclusion

This service already found few minor mistakes that I missed. Definitely worth trying.

Reviewing PRs is a very tedious task, AI can actually help with it.

Of course there are probably 3 useful comments out of 10, but it is very similar with human reviewers, e.g. they're either nitpicking the every line or blindly approve huge PR.

Treat such comments as possibly useful recommendation, not like obligation to fix everything.

Price

Currently, you can use it for free with basic functionality, and 12$/month for Pro version.
Probably, this promotion-like pricing will change in the future, but again, worth giving it a try.

Solving slow compilation in dev mode for Next.js

Alex — Fri, 08 Nov 2024 12:04:05 +0000

Noticed that Next.js dev server is really slow, annoying that it can't precompile pages in the background.
There is a discussion about it.

Ways to make it faster

Turbopack

Can use turbopack, can run it with next dev --turbo, downsides that if you use some fine tweaks for Webpack, not everything works correctly with turbopack (at least for v14).

Upgrade to Next.js v15

v15 is faster by default, some common issues were solved. There is a codemod that will do most of the things for you in a few seconds.
Still, requires some effort.

Config tweaks

There is onDemandEntries option for next.config.js, can use it to force dev server to store more compiled pages in memory, so you will see fewer compiling /page ... lines.
For example:

const nextConfig = {
  onDemandEntries: {
    // period (in ms) where the server will keep pages in the buffer
    maxInactiveAge: 15 * 60 * 1000, // 15 minutes
    // number of pages that should be kept simultaneously without being disposed
    pagesBufferLength: 4,
  },

Tnx for reading.

DEV Community: Alex

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

First really useful AI tool - AI code review

The service

How it looks like

Conclusion

Price

Solving slow compilation in dev mode for Next.js

Ways to make it faster

Turbopack

Upgrade to Next.js v15

Config tweaks

`count`

`group` and `groupCollapsed`

`dir`

`assert`

`time`

`trace`

`clear`