DEV Community: mk668a

Run Claude across all your repos from one session — without merging anyone's .claude/

mk668a — Mon, 22 Jun 2026 18:15:13 +0000

Run Claude across all your repos from one session

claude-muster is an orchestrator for Claude Code: it leaves every repo's .claude/ exactly where it is and runs that repo's own Claude inside it, while the Claude at your root decides who gets the work.

Here's the whole thing in one session:

$ cd ~/work
$ claude-muster repos

  3 repos you can dispatch to:

  webapp
  api
  mobile

$ claude-muster dispatch api "fix the failing test in handler.ts"

  [api] ok

  Found it: handler.ts called the old two-arg `parse()`.
  Updated the call and the test passes.

That child ran claude inside api/ — with api's real working directory, environment, skills, agents, hooks, and permissions, exactly as if you'd opened Claude there yourself. Nothing was copied. Nothing was merged. There's nothing to drift or clean up.

The gap it fills

Say your work lives in one folder full of separate git repos, each carrying its own .claude/:

~/work/
├── webapp/    → .claude/skills/deploy, .claude/commands/release
├── api/       → .claude/skills/lint, .claude/agents/db-reviewer, .claude/hooks/pre-commit
└── mobile/    → .claude/commands/build

Open Claude Code inside api/ and you get all of api's tooling. Good. But open it in ~/work/ to work across all three at once and that tooling vanishes — because Claude Code reads .claude/ from the current folder and the folders above it, never the folders below.

The obvious fix is to drag everything up: copy or symlink each repo's .claude/ into ~/work/.claude/. That works for skills, and then quietly breaks the rest:

A hook written to run inside api/ now fires from ~/work/ with the wrong working directory.
One repo's deny permission silently blocks every other repo.
Two repos that both set API_URL collide into one value.
Agents have to be copied, so they drift out of date the moment the source changes.

You end up babysitting a merged .claude/ instead of working.

claude-muster takes the opposite approach. Instead of pulling every repo's tooling up into one session, it leaves each .claude/ in place and runs that repo's own Claude inside that repo. The Claude at your root becomes a dispatcher: it decides which repo a task belongs to, hands it off, and reads back the result.

	merge it all up	claude-muster
Hook working directory	wrong (runs from root)	correct (the repo's own folder)
Permissions / `deny` rules	cross-fire across repos	scoped to each repo's session
Agents	copied, drift out of date	read live from the repo
Environment	collides on shared keys	isolated per child process
Cleanup	merged settings, symlinks, manifest	one skill; `uninstall` removes it

Teach your root Claude to do it on its own

Calling dispatch by hand is the manual gear. Install the routing skill and your root Claude learns to delegate without being told which repo to hit:

$ claude-muster install     # adds a small skill to ~/work/.claude/

$ claude
> fix the failing test in api and tell me what web's build command is

  (Claude dispatches to api, dispatches to web, and reports both back)

Want your root Claude to know its repos the instant a session starts, instead of waiting for the skill to kick in? Add --hook:

$ claude-muster install --hook    # also registers a SessionStart hook

Now every session here opens with a one-line briefing of which repos it can dispatch to. That hook is the only thing claude-muster writes to your settings.json, and uninstall takes it back out exactly — deleting the file if nothing else is left in it.

One repo, or fan out to all

dispatch <repo> "<task>" sends one self-contained task to one repo. Write it as you would to a fresh Claude opened in that repo, because that's exactly what it is — the child starts with no memory of your root conversation.

dispatch --all "<task>" sends the same task to every repo in parallel and collects the results. It's built for surveys and sweeps:

$ claude-muster dispatch --all --json "what's your test command?"
[
  { "repo": "webapp", "ok": true,  "text": "npm test", "code": 0 },
  { "repo": "api",    "ok": true,  "text": "pytest -q", "code": 0 },
  { "repo": "mobile", "ok": true,  "text": "flutter test", "code": 0 }
]

"is there a TODO about auth anywhere?", "bump the version to 2.0" — same shape. Pair it with --json when you want to aggregate the answers yourself.

By default every sibling repo with a .claude/ is included. Drop a claude-muster.json in the root to narrow it down:

{
  "include": ["webapp", "api/*", "services/**"],   // globs, relative to root
  "exclude": ["legacy-*"],
  "depth": 2,                                       // how deep to look (default: 1)
  "paths": ["../shared-tools", "/abs/path/to/repo"] // extra repos anywhere on this machine
}

How it works

Claude Code reads each repo's .claude/ from the repo's own folder and the folders above it. claude-muster never fights that — it just starts claude with the child repo as the working directory:

Step	What happens
discover	Walk the root for sibling directories that contain a `.claude/` (respecting `claude-muster.json`).
decide	The Claude at your root (or you on the command line) picks which repo a task belongs to.
dispatch	Run `claude -p "<task>" --output-format json` with `cwd` set to that repo.
collect	Parse the child's final result and hand it back to the orchestrator.

Because the child is a real claude process rooted in its own repo, every problem the merge-it-all approach creates simply doesn't arise: the working directory is right, hooks and permissions stay scoped, agents are never stale, environments don't collide, and there's nothing to clean up.

Why it's safe to rely on

The most important line in the README is this one: claude-muster never calls an LLM itself. dispatch launches your local claude CLI, which runs on your own Anthropic auth and your own wallet, in Claude Code's documented headless mode (claude -p). No API keys of its own, no network, no telemetry. claude-muster only decides where to send work and collects what comes back.

It also barely touches disk. dispatch and repos only read your folders to discover repos. The one thing it ever writes is the routing skill from install (plus the optional SessionStart hook), and uninstall removes exactly that.

What it doesn't do yet

I'd rather you hit these knowingly:

Persistent child sessions. Each dispatch is a fresh, single-shot claude -p run, so a child doesn't remember the previous task you sent it. Warm, long-lived sessions per repo are a planned follow-up.
Repos on other machines. Anywhere on your local filesystem works (see paths), but remote or networked repos don't.
Guessing when it's ambiguous. If a task could belong to several repos, the routing skill is written to ask rather than guess.

One practical note: dispatch --all starts several claude processes at once, which can hit Anthropic's rate limits if you fan out widely. Keep concurrency reasonable.

Install

Not on npm yet — for now, clone and build:

git clone https://github.com/mk668a/claude-muster
cd claude-muster
npm install && npm run build
npm link            # makes `claude-muster` available everywhere

cd ~/work
claude-muster repos

Node 18+. You also need the claude CLI on your PATH — that's what dispatch runs. Prefer not to npm link? Call the built file directly: node /path/to/claude-muster/dist/cli.js.

Repo: https://github.com/mk668a/claude-muster · MIT.

The pitch fits in a sentence: stop merging everyone's .claude/ into one session and let each repo's Claude do its own work, in its own folder, with its own tooling intact. If you run it across a workspace where the merge approach was biting you, I'd love to hear which of the five collisions it quietly fixed first.

Grammarly costs $12/mo — a local LLM does it for free (Chrome + Ollama)

mk668a — Mon, 15 Jun 2026 13:15:18 +0000

I write a lot in the browser — email, GitHub comments, contact forms — and I wanted proofreading without uploading every keystroke to a company's cloud. My workplace bans Grammarly for exactly that reason.

So I built inline-scribe: a Chrome extension that proofreads your text with an AI that runs on your own machine (Ollama). Nothing leaves your computer. And the fixes show up like Word's Track Changes — accept or reject each one individually with ✓ / ✕.

This post is about the two design decisions I found most interesting while building it. Both generalize to anyone wiring a local LLM into a product.

The LLM never produces the diff.
Silencing Ollama's 403 with declarativeNetRequest — zero-config, no OLLAMA_ORIGINS.

The missing ingredient was never the AI

If you write in a browser today, you pick one of three bad options:

Grammarly — great UX, but every keystroke goes to their cloud, the good features are behind a subscription, and many workplaces ban it (legal docs, unreleased code, patient data).
Paste into ChatGPT — you get one big rewritten blob back. Which words changed? Did it alter your meaning? You re-read everything, every time, and your text still went to someone else's server.
Nothing — and ship the typos.

The thing is, the AI isn't the hard part anymore. Anyone can run a capable model locally with Ollama in two commands, for free. What's missing is the interface. The reason Grammarly was worth paying for was never the grammar engine — it was the friendly diff that lets you see and control each change.

That interface, on top of a model you own, is the whole product.

	corrections	your text goes to	inline diff, per-fix accept/reject	price
Grammarly	cloud AI	their servers	✅ (the reason people pay)	$12+/mo
Harper (10k★)	local, rule-based	nowhere ✅	❌ underlines typos only — can't rewrite a clumsy sentence	free
scramble / Typollama	local LLM ✅	nowhere ✅	❌ whole-text replacement or popup	free
inline-scribe	local LLM ✅	nowhere ✅	✅	free

Design decision #1: the LLM never produces the diff

This is the one I most want to share.

The intuitive move is to ask the model for structured output: "return the changes as JSON," something like [{ "delete": "...", "insert": "..." }, ...], and pipe it straight into the UI.

But small local models break when you do this. A model like llama3.2 (3B) is surprisingly good at fixing prose and terrible at structured output: it breaks the JSON, adds explanations, wraps everything in a code fence, renames your keys. A chatty 3B model means a broken UI.

So I split the responsibilities:

The model's job: return corrected prose — just text.
The extension's job: compute the changes (hunks) from (original, corrected) with a deterministic algorithm.

you press Alt+G in a text field
   │
   ▼
the extension sends your text to YOUR endpoint     ← default: Ollama on 127.0.0.1
(an OpenAI-compatible /chat/completions API)          model: llama3.2 (~2GB, free)
   │
   ▼
the model returns corrected prose — just text
   │
   ▼
inline-scribe computes a word-level diff           ← deterministic algorithm,
between your text and the correction                  NOT the LLM's opinion
   │
   ▼
review panel: accept ✓ / reject ✕ each change → Apply writes back only what you approved

The diff tokenizes into words + whitespace + punctuation runs, then does an LCS (longest common subsequence) walk:

// Tokenize into words/whitespace/punctuation, preserving everything
export function tokenize(text: string): string[] {
  return text.match(/\s+|[^\s\w]+|\w+/gu) ?? [];
}

export function diffText(original: string, corrected: string): Hunk[] {
  const a = tokenize(original);
  const b = tokenize(corrected);
  // DP table of LCS lengths over a × b (Uint32Array rows)
  // Walk the table emitting equal / delete / insert, merging adjacent ops.
  // Collapse delete+insert neighbours into one `replace` so a phrase rewrite
  // reads as a single reviewable hunk instead of three.
  ...
}

This split has a lot of happy side effects:

Model-agnostic. Any OpenAI-compatible endpoint works (llama.cpp, LM Studio, vLLM, or your own key). Since nothing depends on structured-output quality, the UI behaves the same whether you run 3B or 70B.
Deterministic, so reproducible. Same input/output → same hunks. Easy to unit-test.
Accept/reject is trivial. A hunk is { kind, original, corrected }. Accepted hunks take corrected, rejected take original, concatenate — done.

export function applyDecisions(hunks: Hunk[], accepted: boolean[]): string {
  let result = '';
  hunks.forEach((h, idx) => {
    if (h.kind === 'equal') result += h.original;
    else result += accepted[idx] ? h.corrected : h.original;
  });
  return result;
}

Even with "return only text," small models still wrap output in fences or quotes. I gave up on prompting that away and instead strip the obvious wrappers in post — without touching real content:

export function stripWrapping(reply: string, original: string): string {
  let out = reply.replace(/\r\n/g, '\n');
  const fence = out.match(/^\s*```[a-z]*\n([\s\S]*?)\n```\s*$/);
  if (fence) out = fence[1];                       // strip ```...```
  out = out.replace(/^\s+|\s+$/g, '');
  if (/^".*"$/s.test(out) && !/^"/.test(original.trim())) out = out.slice(1, -1); // strip whole-reply quotes
  if (original.endsWith('\n') && !out.endsWith('\n')) out += '\n'; // preserve trailing-newline convention
  return out;
}

Takeaway: let small local models do what they're good at (return natural language) and keep the structure — diffs, JSON, state — in deterministic code. This isn't specific to proofreading; it's a general principle for putting a local LLM into a product.

Design decision #2: silencing Ollama's 403 with declarativeNetRequest

This is the pothole every Chrome-extension × Ollama project hits.

Stock Ollama rejects requests carrying a chrome-extension://... Origin with a 403 — a guard against cross-origin access from extensions. The official workaround is to have the user set the OLLAMA_ORIGINS env var. But asking for that means:

exporting OLLAMA_ORIGINS=chrome-extension://<id-that-changes>
different steps depending on shell config and how Ollama is launched
the single biggest "I installed it and it doesn't work" drop-off point

In other words, the moment your README documents an env var, you've lost. It should just work with a stock ollama serve.

The fix: use MV3's declarativeNetRequest (DNR) to strip the Origin header from requests to the configured endpoint with a dynamic rule. No Origin, no 403.

async function syncOriginRule(): Promise<void> {
  const stored = await chrome.storage.sync.get('config');
  const endpoint = stored.config?.endpoint ?? DEFAULT_CONFIG.endpoint;
  const host = new URL(endpoint).host; // e.g. 127.0.0.1:11434

  await chrome.declarativeNetRequest.updateDynamicRules({
    removeRuleIds: [1],
    addRules: [{
      id: 1,
      priority: 1,
      condition: { urlFilter: `||${host}/`, resourceTypes: ['xmlhttprequest'] },
      action: {
        type: 'modifyHeaders',
        requestHeaders: [{ header: 'origin', operation: 'remove' }],
      },
    }],
  });
}

Key points:

Scope the rule to the user's configured host only (urlFilter). It's not a dangerous "strip Origin everywhere" rule.
The endpoint is configurable, so watch chrome.storage.onChanged and re-apply the rule whenever config changes.
The only permissions needed are declarativeNetRequest plus localhost host_permissions.

// manifest.json (excerpt)
"permissions": ["storage", "activeTab", "declarativeNetRequest", "contextMenus"],
"host_permissions": ["http://127.0.0.1/*", "http://localhost/*"],

The result: the user's steps are "install Ollama, ollama serve, install the extension." Zero env vars.

MV3 architecture: do the fetch in the service worker

One more thing. The actual fetch (the request to 127.0.0.1) happens in the service worker, not the content script:

// content → background message; background runs the check and replies
chrome.runtime.onMessage.addListener((msg, _sender, sendResponse) => {
  if (msg?.type !== 'inline-scribe:check') return undefined;
  (async () => {
    const config = { ...DEFAULT_CONFIG, ...(await chrome.storage.sync.get('config')).config };
    try {
      const corrected = await new OllamaChecker(config).check(msg.text);
      sendResponse({ ok: true, corrected, model: config.model });
    } catch (err) {
      sendResponse({ ok: false, error: /* CheckerError message */ });
    }
  })();
  return true; // keep the channel open for the async response
});

Two reasons:

It isn't bound by the page's CSP. A fetch from a content script gets blocked when the page's Content-Security-Policy restricts connect-src. The service worker runs in the extension's context and is unaffected.
It plays well with the DNR Origin strip. The request now originates from the extension's service worker as an xmlhttprequest, so the rule above applies cleanly.

The UI (review panel, the ✎ selection icon, in-place replacement) is rendered in a shadow DOM from the content script so it doesn't collide with the page's CSS.

Wrapping up

inline-scribe is, at its core, "Grammarly's diff UX on top of a local LLM." The design decisions that made it work:

Don't let the LLM build the diff — use a deterministic algorithm. The UI never breaks on small models, it's model-agnostic, and it's easy to test.
Strip the Origin with DNR. No OLLAMA_ORIGINS, zero config.
Fetch in the service worker. Not bound by page CSP.

Swap the system prompt and the same diff UI becomes a translator or a tone-shifter. Source is MIT.

Repo: https://github.com/mk668a/inline-scribe

If you're putting a local LLM into a product, the leverage is in deciding what the model does — and what it doesn't.

Position tooltips and popovers with native CSS — zero runtime JS

mk668a — Thu, 04 Jun 2026 19:51:39 +0000

Repo: https://github.com/mk668a/css-anchor-kit · MIT.

css-anchor-kit is floating-ui's React API with the JavaScript runtime deleted — positioning happens in the browser's layout engine, not in a requestAnimationFrame loop.

Here's a tooltip. The whole thing:

import { useAnchor } from 'css-anchor-kit'

function Tooltip() {
  const { anchorProps, floatingProps } = useAnchor({ placement: 'top', offset: 8 })
  return (
    <>
      <button {...anchorProps}>Hover me</button>
      <div {...floatingProps} role="tooltip">Type less. Think more.</div>
    </>
  )
}

No refs to wire. No effect to keep position in sync on scroll. anchorProps and floatingProps are just inline styles that compile to anchor-name, position-anchor, anchor(), and position-try-fallbacks. When the page scrolls or the anchor moves, the browser repositions the box — the same way it already keeps position: sticky glued in place. Your JavaScript never runs.

That badge under the button is the snippet above, live. The arrow points at the trigger and the box sits 10px below it — placement the browser computed from inline anchor-name / anchor(), not a measurement loop.

The gap it fills

floating-ui is one of the most-downloaded packages on npm — ~28M installs a week — and its core job is keep this box next to that box. To do that in 2020 you had to: measure the anchor's rect, measure the floating box, compute a position, write it to style, and then re-run that whole pipeline on every scroll, resize, and layout shift via an autoUpdate loop. That's the runtime cost. That's why there's a library.

Browsers now do this natively. CSS Anchor Positioning reached Baseline in 2026 (Chrome/Edge 125+, Safari 26+; Firefox behind a flag with a solid polyfill). You name an anchor, point a floating element at it, and the layout engine keeps them together — no measurement, no loop, no reflow in the scroll path.

The catch: the raw CSS API is verbose and unfamiliar. anchor-name: --foo, position-anchor: --foo, top: anchor(bottom), position-try-fallbacks: flip-block… nobody has muscle memory for that yet, and mapping "I want bottom-start with an 8px gap that flips on overflow" onto it by hand is fiddly.

So there's a hole: the platform can do the work, but the ergonomics everyone learned belong to floating-ui. css-anchor-kit is the thin headless layer that bridges it — floating-ui's placement / offset / flip / arrow vocabulary on top, native CSS underneath, nothing in between at runtime.

	floating-ui	css-anchor-kit
Position computed by	JS, on every scroll/resize	the browser's layout engine
Runtime cost	measure → place → `autoUpdate` loop	none — it's CSS
Bundle (min+gzip)	~6–10 KB core + React	< 1 KB, React optional
Arrow stays on anchor when edge-aligned	needs JS middleware	a sibling anchored to the same element
Works without React	yes	yes — `buildAnchorStyles`

The API is the one you already know

If you've written floating-ui, you can read this without docs:

const { anchorProps, floatingProps, arrowProps, supported } = useAnchor({
  placement: 'bottom',  // the 12 floating-ui placements
  offset:    8,          // gap in px
  flip:      true,       // flip to the opposite side on overflow (default)
  hide:      false,      // hide when the anchor scrolls out of view
  size:      false,      // match the anchor's size: 'width' | 'height' | true
})

The repo ships a docs app that turns every one of those options into a live control. Change placement to bottom, drag offset to 10, and the canvas re-positions while the generated code on the right rewrites itself to match — there's no measurement step in between, the engine just resolves the new anchor() insets:

useAnchor only computes position. It deliberately doesn't own visibility or interaction — pair it with the native popover attribute, a hover/focus state, or your own useState. That separation is the whole reason it stays under a kilobyte.

A few things worth calling out:

Arrows are a sibling, not middleware. The arrow element is anchored to the same anchor as the floating box, so it stays centered on the trigger even when the popover is edge-aligned or flips. floating-ui needs an arrow() middleware and a ref for this; here it's just {...arrowProps} on a sibling <div>.
size matches the trigger. size: 'width' emits anchor-size(width) — exactly what you want for a combobox/select popover that should be as wide as its button.
RTL is free. -start/-end placements pin logical edges (inset-inline-*), so bottom-start aligns to the right edge in RTL automatically — matching floating-ui, with zero JS.

Prefer composition? There's optional headless sugar that tree-shakes away if unused:

import { Anchored, Anchor, Floating, Arrow } from 'css-anchor-kit'

<Anchored placement="top" offset={8}>
  <Anchor as="button">Hover me</Anchor>
  <Floating role="tooltip">Type less. Think more.</Floating>
  <Arrow className="arrow" />
</Anchored>

This is exactly how you build a real dropdown. The menu below pairs <Anchored size="width"> with the native popover attribute — so the list renders in the top layer (no z-index wars) and matches its trigger's width via anchor-size(width), which floating-ui needs a JS size middleware to do:

And it isn't even React-locked — the framework-agnostic core has zero dependencies:

import { buildAnchorStyles } from 'css-anchor-kit/core'

const { anchor, floating } = buildAnchorStyles('--my-tooltip', { placement: 'top', offset: 8 })
Object.assign(anchorEl.style, anchor)
Object.assign(floatingEl.style, floating)

You don't have to migrate by hand

If you have an existing floating-ui codebase, there's a jscodeshift codemod that does the mechanical 80%:

npx css-anchor-kit migrate "src/**/*.{ts,tsx}"        # rewrite in place
npx css-anchor-kit migrate "src/**/*.tsx" --dry --print # preview only

It rewrites useFloating(...) → useAnchor(...), maps offset/flip/hide middleware to options, drops the now-pointless autoUpdate loop, rewires ref={refs.setReference} / setFloating to {...anchorProps} / {...floatingProps}, and fixes the imports.

Crucially, it does not silently drop what has no native equivalent. shift, autoPlacement, inline, and arrow ref-wiring get a // TODO(css-anchor-kit) comment left in place, so you can finish those by hand:

grep -rn "TODO(css-anchor-kit)" src

The codemod is a dev-time CLI only — it's never imported by the library, so it has zero effect on your runtime bundle.

Honest limitations

CSS Anchor Positioning is discrete, not continuous. The platform's fallback model is "try position A, then B, then C" — not "slide pixel by pixel." That means:

shift — continuously sliding a popover to keep it in view — has no native equivalent. flip covers the common overflow case; if you genuinely need continuous shifting, floating-ui is still the right tool.
autoPlacement isn't mapped; pick a placement and let flip handle overflow.

Everything else the 90% tooltip/popover/menu case actually uses — placement, offset, flip, hide, size, arrows, RTL/logical alignment — is covered natively, with no JS in the scroll path.

Verified in Chromium 148: all 12 placements position correctly (right side, ~8px gap, logical -start/-end alignment), size matches the anchor, and flip kicks in on overflow.

Install

npm i css-anchor-kit

React 18+ is an optional peer dependency — you only need it for the hook. For older browsers, detect support with the supported flag and lazy-load the @oddbird/css-anchor-positioning polyfill yourself — it's BYO and not bundled, so supporting browsers ship nothing extra.

const { supported } = useAnchor()
useEffect(() => {
  if (!supported) import('@oddbird/css-anchor-positioning/fn').then((m) => m.default())
}, [supported])

Repo: https://github.com/mk668a/css-anchor-kit · MIT.

The pitch is small enough to fit in a sentence: the thing you were shipping 10 KB of JavaScript for is a CSS feature now. Keep the API, drop the runtime. If you try the codemod on a real floating-ui app and it leaves a TODO you think should have a native mapping, open an issue — those edges are exactly where the discrete-vs-continuous line gets interesting.

Which package is bloating your Docker image?

mk668a — Mon, 25 May 2026 11:24:56 +0000

layer-blame is git blame for image layers — it names the package responsible for every byte.

Here's what it prints when you point it at a stock Alpine image:

$ docker save alpine:3.20 -o alpine.tar
$ layer-blame alpine.tar

Image total: 8.4 MB across 1 layers  ·  package attribution: 100%

Layer 0  8.4 MB  ADD alpine-minirootfs-3.20.10-aarch64.tar.gz /
      4.8 MB  libcrypto3                      pkg   ← largest line highlighted
    911.7 KB  libssl3                         pkg
    906.0 KB  busybox                         pkg
    706.5 KB  musl                            pkg
    327.1 KB  apk-tools                       pkg

Every byte in that layer now has an owner. libcrypto3 is 4.8 of the 8.4 MB. That's the whole pitch: it's git blame, but the blamed thing is the package responsible for a layer's size.

The gap it fills

You already have two tools for image size, and between them there's a hole.

docker history tells you that a layer is 95 MB. It will not tell you what's in it.

dive (~54k⭐) lets you browse what's in it — file by file, interactively. It answers what is in a layer.

Neither answers the question you actually walked up with: "which package put those bytes here?" So the standard ritual is: read docker history for the fat layer, open dive, eyeball the tree, and guess. People have asked dive for package-level breakdown directly — see dive#291, open for years.

layer-blame JOINs each layer's added files against the image's own package databases — apk for Alpine, dpkg for Debian/Ubuntu — and attributes every byte to a package. It's not a browser. It's a non-interactive report you can paste into a PR or wire into CI.

dive for browsing, layer-blame for attribution. They're complementary.

Where do Python's 137 MB actually go?

This is the example that sold me on building it. python:3.12-slim is famously chunky. Here's the breakdown:

$ docker save python:3.12-slim -o py.tar
$ layer-blame --top 5 py.tar

Image total: 137.7 MB across 4 layers  ·  package attribution: 69%

Layer 0  95.8 MB  # debian.sh --arch 'arm64' out/ 'trixie' ...
     22.5 MB  libc6                           pkg
      9.1 MB  coreutils                       pkg
      7.4 MB  perl-base                       pkg
      7.3 MB  libssl3t64                      pkg
      6.6 MB  util-linux                      pkg

Layer 2  38.2 MB  RUN /bin/sh -c set -eux; savedAptMark="$(apt-mark showmanual)"; …
      6.3 MB  /usr/local/lib/libpython3.12.so.1.0                          file
      1.8 MB  /usr/local/lib/python3.12/ensurepip/_bundled/pip-...whl       file
      1.1 MB  /usr/local/lib/python3.12/lib-dynload/unicodedata...so        file
      ...

Look at Layer 2. The big contributors come back as files, not packages. That isn't a bug — it's the finding. This image compiles Python from source, so those bytes belong to no dpkg package. The layer's weight is build artifacts, not an installed package, and the tool says so by falling back to file-level attribution instead of pretending. The package attribution: 69% header is telling you exactly that: 69% of the image mapped cleanly to packages, the rest is unowned bytes worth a second look.

Using it

docker save <image> -o image.tar
layer-blame [flags] image.tar

No Docker daemon needed at read time — it parses the docker save tarball (or a plain OCI layout) directly. That's what makes it CI-friendly: save the artifact in your build job, run layer-blame against the file.

Flag	Default	Meaning
`--top N`	5	Top N contributors per layer
`--no-color`	false	Disable ANSI color (also honors `NO_COLOR` and non-TTY output)
`--version`	false	Print version, commit, build date

How it works

Five steps, all deterministic — no network, no daemon, no model:

Load the tarball / OCI layout via go-containerregistry, which normalizes Docker-save, BuildKit, and containerd/OCI formats for you.
Walk each layer's filesystem diff, recording every added file and its size. Whiteout (deletion) markers are skipped — you can't blame a layer for bytes it removed.
Build a file→package index from the image's own package DBs: /lib/apk/db/installed (Alpine) and /var/lib/dpkg/info/*.list (Debian/Ubuntu).
For each layer, group added bytes by owning package. Files with no owner are reported individually, so a large unattributed artifact still surfaces by name.
Map each layer back to the Dockerfile instruction that created it (created_by from the image config) and print the table.

The novel part is step 4 — the JOIN between added bytes and the package database. Everything else is plumbing.

Known boundaries

I'd rather you hit these knowingly than be surprised:

scratch / distroless have no package database, so attribution falls back to file level. Still useful, no package names.
Multi-stage COPY --from files are disconnected from their origin package, so they show as unattributed in the destination layer.
v1 handles apk (Alpine) and dpkg (Debian/Ubuntu) only. rpm and language package managers (npm, pip) aren't in yet.

Install

It's a single Go binary, MIT-licensed.

# Prebuilt binary (Linux/macOS/Windows, amd64+arm64) — from the latest release
curl -sSfL https://github.com/mk668a/layer-blame/releases/latest/download/layer-blame_<version>_linux_amd64.tar.gz \
  | tar -xz layer-blame

# or with Go
go install github.com/mk668a/layer-blame@latest

Repo: https://github.com/mk668a/layer-blame

Next time a PR balloons your image and the size-budget review asks "why is this 800 MB?", you'll have a one-command answer with a package name attached — instead of an afternoon in dive. If you try it on a weird image and the attribution surprises you, open an issue; the edge cases (rpm, cross-stage COPY) are exactly where it gets interesting.

Your polyfills are dead. Here's a robot that buries them.

mk668a — Mon, 25 May 2026 03:56:01 +0000

The problem: polyfills never leave

A polyfill is a deal you make with the past. A browser doesn't support some
feature yet, so you npm install a shim, ship it, and move on. The deal is
supposed to be temporary — but nobody ever collects the other half.

Years pass. The feature ships in every browser. The polyfill is now pure dead
weight: it bloats your bundle, slows your installs, and adds one more link to
your supply-chain attack surface. And nothing tells you to delete it.

Renovate / Dependabot dutifully bump the polyfill's version forever. They keep the corpse fresh; they never tell you it's a corpse.
Linters flag some redundant dependencies, but they don't act, and they don't know whether the underlying feature is actually safe to rely on yet.

So @oddbird/css-anchor-positioning, @ungap/structured-clone,
array.prototype.flat, and a dozen friends quietly live in your package.json
for years after they stopped doing anything.

The signal: Web Platform Baseline

The missing piece is a trustworthy, dated answer to "is this feature safe to
use natively yet?" That signal now exists: Baseline.

The web-features dataset
tags each web feature with a Baseline status. The one that matters here is
Widely available (status.baseline === "high") — roughly 30 months after
the feature reached every major browser engine. Once a feature is Widely
available, the polyfill that shimmed it is, by definition, redundant.

That's a calendar-driven trigger: a polyfill becomes removable on a specific
day, whether or not anyone is paying attention.

The tool: `baseline-polyfill-pruner`

baseline-polyfill-pruner watches that signal for you and removes the dead
polyfills it finds. It runs as a CLI, or — better — as a GitHub Action that
opens a pull request the moment a polyfill becomes removable.

How it decides

A dependency becomes a removal candidate only when both of these are true:

baseline-high(feature)  AND  browserslist-targets-all-support(feature)
        →  polyfill is dead weight  →  removal candidate

Baseline says so. The feature the polyfill maps to is Baseline Widely available in the web-features dataset.
Your targets agree. Your project's own browserslist targets all support that feature natively.

Step 2 is the important one. "Widely available" is a global statement about
the web. But if your browserslist still targets ie 11 or an ancient
Safari, the polyfill is still doing real work — so the tool keeps it.

The guiding principle is "when in doubt, don't remove." A missed removal is
harmless (you keep a dependency a little longer). A wrong removal breaks
someone's build. The whole design is biased toward the safe mistake.

How it maps polyfills to features

A hand-curated registry maps ~30 well-known polyfills (the es-shims
ECMAScript ponyfills, plus DOM/CSS shims like intersection-observer,
dialog-polyfill, whatwg-fetch, and @ungap/structured-clone) to their
web-features ids.

Crucially, every id in the registry is checked against the live dataset in
CI. If a feature gets renamed or someone fat-fingers an id, the build fails —
instead of silently mis-flagging your dependency. It's quality over quantity by
design.

Using it

As a CLI

baseline-prune --diff           # report removable polyfills (default, no writes)
baseline-prune --fix            # remove them from package.json + list import sites
baseline-prune --json           # machine-readable report
baseline-prune --cwd ./app      # target a specific project root

A dry run looks like this:

would remove  array.prototype.flat  — array-flat is Baseline Widely available (since 2022-07-15)

✓ 1 removable polyfill(s) found.
   Run with --fix to apply.

--fix removes the dependency from package.json — preserving your
indentation, key order, and trailing newline — and then hands you a checklist of
every import site that still references it:

removed  array.prototype.flat  — array-flat is Baseline Widely available (since 2022-07-15)

⚠  2 import site(s) still reference the removed package(s).
   Remove these manually, then run your build/tests:
   - src/list.js:2  (array.prototype.flat)
   - src/list.js:8  (array.prototype.flat)

Note what --fix doesn't do: it never rewrites your source code. Automatic
import-site rewriting (an AST codemod) is deliberately out of scope. A wrong
edit to your source breaks builds and burns trust — so the tool edits the
manifest and lets you handle the import lines.

As a GitHub Action (the point)

The real value is automation. A polyfill becomes removable on the day Baseline
flips, and no human remembers to re-check. So put it on a schedule:

# .github/workflows/baseline-prune.yml
name: Baseline polyfill prune
on:
  schedule:
    - cron: "0 9 * * 1" # Mondays
  workflow_dispatch: {}
permissions:
  contents: write
  pull-requests: write
jobs:
  prune:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: mk668a/baseline-polyfill-pruner@v1

Every Monday, the Action runs the engine, applies --fix, and — if it finds
anything — opens a PR titled "Drop N polyfills Baseline reports as widely
available" with a rationale table and the import-site checklist in the body.
You review it and merge with confidence.

Why this didn't already exist

Tool	What it does	The gap
`eslint-plugin-depend`	Lints for redundant deps	Lint-only, no autofix, no Baseline
`module-replacements-codemods`	Codemods deps → native	Doesn't key off Baseline status
Renovate / Dependabot	Bump versions	Never say "this dep is removable"

Each piece existed. The combination — a live Baseline trigger plus an
automatic removal PR — is the thing none of them do. That combination is the
whole idea.

One design note worth stealing

baseline-polyfill-pruner uses no LLM at runtime. web-features is a
static, versioned dataset, and the removal decision is deterministic date
arithmetic plus a browserslist check. AI helped build the tool, but the
shipped binary is boring, predictable, and offline — exactly what you want from
something that edits your package.json on a cron schedule.

baseline-polyfill-pruner is MIT-licensed. Source:
github.com/mk668a/baseline-polyfill-pruner.

I built GhostType: inline AI text completion for every app on macOS

mk668a — Fri, 15 May 2026 04:37:21 +0000

Writing the same kind of sentences over and over — meeting replies, status updates, polite refusals — eats a surprising amount of the day. LLMs can finish those sentences for me, but only if I copy-paste into a chat window. By the time I've done that, I could have just typed the thing.

I wanted the LLM to be right where I'm already typing — in Gmail, in Notes, in the X compose box — and I wanted it to run on my own machine. So I built GhostType.

What it is

GhostType is a menu bar app for macOS 14+ that watches the text field you're typing in, sends the surrounding context to a local LLM server (LM Studio, Ollama, llama.cpp, vLLM — anything OpenAI-compatible), and shows the completion as translucent ghost text right at the cursor. Tab to accept, Esc to dismiss.

You type:  "The meeting covered "
           (pause)
GhostType: "The meeting covered quarterly sales targets and the product roadmap"
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                 Ghost text — press Tab to accept

It works in Safari, Notes, Pages, Mail, and most native macOS apps via the Accessibility API. For apps where AX doesn't expose text (Slack, Discord, some Electron apps), there's a manual trigger (Option + \) that uses an internal keystroke buffer.

Why local-only

Three reasons I didn't want this to be a cloud product:

Privacy. Every email draft, every DM, every half-written idea would otherwise hit someone else's server.
Latency. A round trip to the cloud is fine for chat, not great for completion-as-you-type.
Cost. Local inference on Apple Silicon is free. I run a 3B model on an M2 and it's snappy.

Recommended models that work well at this size:

Model	Size	Notes
Qwen2.5-Coder-3B	~2 GB	Best all-rounder
DeepSeek-Coder-V2-Lite	~2 GB	FIM-tuned, high quality
CodeGemma-2B	~1.5 GB	Lowest latency

How it works under the hood

NSEvent.addGlobalMonitorForEvents — watches keystrokes system-wide (requires Input Monitoring permission)
Accessibility API (AXUIElement) — reads the surrounding text from the focused field and writes back the accepted completion (requires Accessibility permission)
Overlay NSWindow — a borderless, click-through window draws the ghost text at the caret position
OpenAI-compatible client — talks to whatever local server you're running on 127.0.0.1

The whole thing is Swift, about 6 source files of core logic. No background daemons, no kernel extensions.

Try it

Install LM Studio or Ollama and pull a model
Download GhostType-0.1.0.dmg from the releases page
Grant Input Monitoring + Accessibility permissions
Start typing in any text field

Requirements: macOS 14+, Apple Silicon recommended, 8 GB RAM minimum.

What's next

This is v0.1.0. Stuff I'd like to tackle next:

Better context extraction for web inputs (currently falls back to keystroke buffer)
Per-app prompt presets (email tone vs. code comments vs. casual chat)
Multi-suggestion popup (cycle through alternatives)

Source is on GitHub under PolyForm Noncommercial: github.com/mk668a/GhostType

Happy to hear feedback, especially from people running it with non-default models or unusual local server setups. What would you want it to do that it doesn't?

Code Map: Visualize Code Dependencies with LLM

mk668a — Mon, 24 Nov 2025 12:40:57 +0000

Repository URL: https://github.com/mk668a/llm-codemap

Have you ever jumped into a new codebase and felt completely lost in a web of imports and function calls? Or maybe you are working with AI agents and want them to have a better spatial understanding of your project structure?

I'm excited to share a project I've been working on called LLM Code Map.

It is a VSCode extension designed to graphically visualize code dependencies and structure for TypeScript and JavaScript projects. But it goes a step further than just being a visualizer—it is built to work seamlessly with AI Agents via the Language Model Tool API.

🚀 What is LLM Code Map?

LLM Code Map analyzes your source code and renders an interactive graph in the VSCode sidebar. It helps you see not just file dependencies, but granular connections between functions, classes, and methods.

Key Features

Granular Analysis: It doesn't just look at files; it analyzes dependencies at the function, class, and method levels.
Interactive Visualization: Powered by D3.js, the graph is interactive, zoomable, and fixed conveniently in your sidebar.
AI Agent Integration: This is the game-changer. It supports the Language Model Tool API, meaning it can be automatically invoked by AI agents within VSCode.

🤖 The "Killer Feature": AI Integration

The most exciting part of this extension is its ability to communicate with AI. Because it implements the Language Model Tool API, you can simply chat with a supported AI agent in VSCode and say:

"Visualize the dependencies of this project"
"Display the code structure using #codemap"

The AI will recognize the tool, trigger the analysis, and present the structure to you instantly. This bridges the gap between raw code text and high-level architectural understanding for AI agents.

🛠️ How to Try It Out

The project is open source and currently in the development phase. You can try it out locally right now!

Quick Start (Development Mode)

1. Clone the Repository

git clone https://github.com/mk668a/llm-codemap.git
cd llm-codemap

2. Install Dependencies

npm install

3. Compile

npm run compile

4. Launch in VSCode

Open the project folder in VSCode.
Press F5 (or go to the "Run and Debug" panel and select "Run Extension").
A new VSCode window ("Extension Development Host") will open.

📖 How to Use

Once the extension is running, you have two ways to use it:

1. Manual Usage (Sidebar)

This is great for exploring the code yourself.

Open the "LLM Code Map" view in the Explorer sidebar.
Click the Refresh Button (🔄) at the top of the view.
The extension will analyze your current workspace and display the interactive graph. You can drag nodes and zoom in/out to explore the structure.

2. Usage via AI Agent

If you are using an AI assistant within VSCode (like Copilot or an agent that supports the Tool API), you can simply ask it to generate the map for you.

Example Prompts:

Visualize the dependencies of User Class

Display the code structure using #codemap

The AI will automatically invoke the tool and render the graph.

🏗️ Under the Hood

For those interested in the tech stack, here is a quick look at the file structure. It uses TypeScript for the core logic and Webviews for the visualization.

codemap/
├── src/
│   ├── extension.ts              # Entry point
│   ├── analyzer/                 # Code analysis logic (AST)
│   ├── visualizer/               # D3.js Graph visualization
│   ├── tools/                    # Language Model Tool API implementation
│   └── utils/                    # Utilities
├── media/                        # Webview resources (HTML/CSS/JS)
└── out/                          # Compiled files

🤝 Contributing

This project is open source (MIT License). I am actively looking for feedback, bug reports, and contributions.

If you are interested in AST analysis, data visualization with D3, or VSCode extension development, check out the repository.

Repository URL: https://github.com/mk668a/llm-codemap

If you find this tool interesting, please give it a star ⭐️ on GitHub!

Happy Coding!

What is Zero-Runtime CSS in JS? Which Library Should You Pick?

mk668a — Sun, 29 Oct 2023 15:46:31 +0000

Introduction: The End of CSS in JS and the Transition to Zero-Runtime

Front-end technology is changing rapidly.

In the midst of such change, React is leading the way among front-end frameworks, and in terms of CSS, CSS in JS is becoming mainstream.

On a side note, I used to worry about naming and designing CSS, using CSS Lint, and other aspects of efficient CSS management. However, I began to use component libraries like emotion for CSS in JS and MUI frequently, which made me stop thinking about CSS-related matters and made development easier. In recent projects, there are situations where there are no css or scss files present within the project.

However, believe it or not, CSS in JS is already being called outdated! I was curious about why it was being called outdated and found the following article:

Why We're Breaking Up with CSS-in-JS

Sam Magura ・ Oct 16 '22

#javascript #react #css #typescript

From here, I'll explain the contents of the above article.

Why We're Breaking Up with CSS-in-JS

Sam Magura is known as the second most active maintainer of the CSS-in-JS library, Emotion. From his experience and knowledge, he points out certain issues with using CSS-in-JS. He initially was captivated by the benefits of CSS-in-JS, but it seems he began to feel its limitations through performance issues and other challenges faced while using it with the Spot team.

Drawbacks of CSS in JS

Runtime Overhead: CSS-in-JS requires converting the style into plain CSS to insert it into the document when a component is rendered. This conversion process demands additional CPU cycles. This overhead can potentially impact the performance of the application.
Increased Bundle Size: Since users visiting a site need to download the JavaScript of the CSS-in-JS library, their bundle size increases. For example, Emotion is 7.9 kB (minzipped) and styled-components are 12.7 kB. While these libraries aren't massive, they do add to the overall size.
Cluttered React DevTools: Libraries like Emotion insert internal components into the React tree. This can make React DevTools cluttered, potentially complicating debugging.
Additional Browser Work: Frequently inserting CSS rules places more workload on the browser. Especially in React's concurrent rendering mode, when a new rule is inserted, the browser has to verify whether or not that rule applies to the existing tree. This results in a style recalculation for all CSS rules and all DOM nodes while React is rendering, which can be extremely slow.
Compatibility with SSR and Component Libraries: When using Emotion with server-side rendering or other component libraries that use Emotion, various issues can arise. These include multiple loads of the Emotion instance, not being able to fully control the order of style insertion, and differing SSR support for Emotion between React 17 and React 18.

The Future of CSS Libraries

As new styling approaches like CSS-in-JS emerge, traditional CSS libraries and frameworks continue to evolve. Preprocessors like Sass and Less provide features such as variables and mixins, making CSS writing more efficient.

Additionally, utility-first CSS frameworks like Tailwind CSS are gaining popularity. They allow rapid design construction by combining class names.

Considering the issues with CSS-in-JS, it's anticipated that traditional CSS libraries and the new utility-first approach will play a significant role in future web development.

Transition to Zero-Runtime CSS in JS

As mentioned in the previous article, there seems to be a problem with the occurrence of overhead. This overhead can decrease the overall page load and rendering speeds. This led to the introduction of zero-runtime CSS in JS.

What is Zero-Runtime CSS in JS?

Zero-runtime CSS in JS refers to the technique of writing CSS inside JavaScript and generating actual CSS files at build time. Compared to regular CSS in JS, its advantage is that it can reduce the execution time cost of JavaScript while retaining the convenience of writing CSS in JavaScript.

Benefits of Zero-Runtime CSS in JS

Zero-runtime CSS in JS is an approach that doesn't dynamically generate and inject CSS during runtime. All styles are generated at build time, which means there's no additional JavaScript overhead during runtime.

Performance: The zero-runtime approach has the potential to improve page load and rendering speeds because there's no overhead from dynamically generating and injecting styles during runtime.
Predictability: Since styles are generated at build time, there's a reduced risk of unexpected style changes or side effects during runtime.
Smaller Bundle Size: Some zero-runtime libraries can reduce the final bundle size by eliminating unnecessary runtime code.
Simplified Server-Side Rendering (SSR): Some CSS-in-JS solutions require additional configurations or steps during server-side rendering, but the zero-runtime approach can alleviate or eliminate this issue.
Advantages of Static Analysis: With styles generated at build time, tools and linters can more easily perform static analysis of the styles.
Environmental Compatibility: In some environments or frameworks, dynamically injecting styles during runtime can be challenging or not recommended. The zero-runtime approach works seamlessly in these situations.

Using CSS in JS with Next.js

The official Next.js documentation lists libraries that can be used within the App Router's app directory. As of the current date (2023/10/30), it appears that they only support usage within client components.

nextjs.org

List of Zero-Runtime CSS-in-JS Libraries

After researching the existing zero-runtime CSS-in-JS, here are the libraries that are still actively developed:

Linaria
vanilla-extract
Panda CSS
Goober
Astroturf
Treat

So, Which CSS-in-JS Library Should You Use?

I plan to compare each of them from various perspectives to determine the best CSS-in-JS solution.

Library	Link	Main Features	Static CSS Generation	TypeScript Support	SSR Support	GitHub Stars	Development Period
Linaria	Linaria on GitHub	CSS is extracted into a CSS file at build time. Compatible with almost all modern frameworks. Can use dynamic styles based on React props (using CSS variables). Easily locate where styles are defined with CSS source maps. Lint CSS in JS with stylelint. Use any CSS pre-processor like Sass or PostCSS if needed. Supports atomic styles with @linaria/atomic. Compared to regular CSS, selectors are scoped, styles are in the same file as components, making refactoring easier. Interoperable with other CSS in JS libraries. Operates without JavaScript.	Extracts CSS at build time and outputs it as a static CSS file.	Offers TypeScript support, but the setup might be a bit intricate.	None	10.9k	2017/5/21 (Latest: 2023/10/3)
vanilla-extract	vanilla-extract on GitHub	Write styles using locally scoped class names and CSS variables, and generate static CSS files at build time. A slight abstraction of standard CSS. Works with any frontend framework/no framework. Locally scoped CSS variables, @keyframes, and @font-face rules. A high-level theme system that supports multiple themes simultaneously without globals. Utilities for generating variable-based calc expressions. Type-safe styles via CSSType. Optional runtime version for development and testing. Optional API for dynamic runtime theming.	Generates static CSS at build time.	Provides type-safe styling with TypeScript.	None	8.8k	2021/2/21 (Latest: 2023/9/16)
Panda CSS	Panda CSS on GitHub	Extracts style objects and style props at build time. Modern CSS output - cascading layers @layer, CSS variables, etc. Compatible with most JavaScript frameworks. Supports recipes and variants like stitches (stitches.dev). A high-level design token system that supports multiple themes simultaneously. Type-safe styles and autocomplete through code generation. Inspired by projects like Chakra UI, Vanilla Extract, Stitches, Tailwind CSS, Styled System, etc.	Generates static CSS at build time.	Provides type-safe styling with TypeScript.	Supports SSG and SSR.	3.7k	2022/1/24 (Latest: 2023/10/29)
Goober	Goober on GitHub	Less than 1KB footprint. Developed with the intent of achieving the existing styled pattern with a smaller footprint. Supports the styled pattern similar to styled-components and emotion. Faster in SSR benchmarks compared to other major CSS-in-JS libraries. Goober is compatible with vanilla JavaScript, and frameworks like React, Vue.js, Angular, Svelte, etc. Integration with tools like Babel, Next.js, Gatsby, etc., is easy through plugins and macros. Supports features like shared styles, automatic prefixing, etc. Supports major browsers and older browsers can be supported using Babel.	Uses the extractCss function to extract static CSS at build time and injects it into the tag. Mainly used during server-side rendering.	Information about explicit TypeScript support is limited.	Supports SSR, provides extractCss function.	3k	2019/1/27 (Latest: 2023/4/19)
Astroturf	Astroturf on GitHub	Write CSS inside JavaScript files, but operates without adding a runtime layer and works alongside the existing CSS processing pipeline. Avoids the loss of flexibility requiring framework-specific CSS handling and keeps CSS fully static without parsing runtime styles. Can write style definitions inside JavaScript files while using Sass, PostCSS, Less, etc. Enjoys the benefits of styling within JavaScript without runtime overhead while maintaining compatibility with existing CSS tools. Compatible with frameworks and supports React's props feature.	Generates static CSS without adding a runtime layer and works with the existing CSS processing pipeline.	Provides TypeScript support, but might require third-party libraries.	None	2.2k	2016/10/16 (Latest: 2023/5/17)
Treat	Treat on GitHub	A framework-agnostic library. Optimizes bundle size with theme support and lightweight runtime style definition via static extraction. Supports webpack, React, and TypeScript. Supports legacy browsers.	Generates all CSS rules at build time and bundles only the generated CSS styles.	Provides type-safe styling with TypeScript.	None	1.2k	2019/5/12 (Latest: 2021/4/28)

I am planning to select the best CSS in JS based on the following perspectives:

Library Maintenance
Treat hasn't been updated since 2021, suggesting there might be potential issues in its ongoing maintenance.

Static CSS Generation
While there are differences in the process of static CSS generation, every library produces static CSS at build time, reducing runtime overhead.

TypeScript Support
vanilla-extract, Panda CSS, and Treat all offer problem-free type-safe styling. For other libraries, there might be a need for additional libraries or more complicated configurations.

SSR Support
Panda CSS and Goober support SSR. For the other libraries, there's insufficient information to confirm if they definitely support SSR.

Performance
Based on various articles, there doesn't seem to be any difference in performance, like rendering time, among the libraries. As they're converted into static CSS, there doesn't seem to be much variance.

Style Writing

Linaria

import { css } from '@linaria/core';
import { modularScale, hiDPI } from 'polished';
import fonts from './fonts';

// Write your styles in `css` tag
const header = css`
  text-transform: uppercase;
  font-family: ${fonts.heading};
  font-size: ${modularScale(2)};

  ${hiDPI(1.5)} {
    font-size: ${modularScale(2.5)};
  }
`;

// Then use it as a class name
<h1 className={header}>Hello world</h1>;

import { styled } from '@linaria/react';
import { families, sizes } from './fonts';

// Write your styles in `styled` tag
const Title = styled.h1`
  font-family: ${families.serif};
`;

const Container = styled.div`
  font-size: ${sizes.medium}px;
  color: ${props => props.color};
  border: 1px solid red;

  &:hover {
    border-color: blue;
  }

  ${Title} {
    margin-bottom: 24px;
  }
`;

// Then use the resulting component
<Container color="#333">
  <Title>Hello world</Title>
</Container>;

vanilla-extract

// styles.css.ts

import { createTheme, style } from '@vanilla-extract/css';

export const [themeClass, vars] = createTheme({
  color: {
    brand: 'blue'
  },
  font: {
    body: 'arial'
  }
});

export const exampleStyle = style({
  backgroundColor: vars.color.brand,
  fontFamily: vars.font.body,
  color: 'white',
  padding: 10
});

// app.ts

import { themeClass, exampleStyle } from './styles.css.ts';

document.write(`
  <section class="${themeClass}">
    <h1 class="${exampleStyle}">Hello world!</h1>
  </section>
`);

Panda CSS

import { css } from '../styled-system/css'
import { stack, vstack, hstack } from '../styled-system/patterns'

function Example() {
  return (
    <div>
      <div className={hstack({ gap: '30px', color: 'pink.300' })}>Box 1</div>
      <div className={css({ fontSize: 'lg', color: 'red.400' })}>Box 2</div>
    </div>
  )
}

import { css } from '../styled-system/css'
import { styled } from '../styled-system/jsx'

// The className approach
const Button = ({ children }) => (
  <button
    className={css({
      bg: 'blue.500',
      color: 'white',
      py: '2',
      px: '4',
      rounded: 'md'
    })}
  >
    {children}
  </button>
)

// The style props approach
const Button = ({ children }) => (
  <styled.button bg="blue.500" color="white" py="2" px="4" rounded="md">
    {children}
  </styled.button>
)

Goober

import { h } from 'preact';
import { styled, setup } from 'goober';

// Should be called here, and just once
setup(h);

const Icon = styled('span')`
    display: flex;
    flex: 1;
    color: red;
`;

const Button = styled('button')`
    background: dodgerblue;
    color: white;
    border: ${Math.random()}px solid white;

    &:focus,
    &:hover {
        padding: 1em;
    }

    .otherClass {
        margin: 0;
    }

    ${Icon} {
        color: black;
    }
`;

interface Props {
    size: number;
}

styled('div')<Props>`
    border-radius: ${(props) => props.size}px;
`;

// This also works!

styled<Props>('div')`
    border-radius: ${(props) => props.size}px;
`;

Astroturf

import * as React from 'react';
import { css } from 'astroturf';

function Button({ children, ...props }) {
  return (
    <button
      {...props}
      css={css`
        color: blue;
        border: 1px solid blue;
        padding: 0 1rem;
      `}
    >
      {children}
    </button>
  );
}

Treat

// Button.treat.js
// ** THIS CODE WON'T END UP IN YOUR BUNDLE EITHER! **
import { style } from 'treat';

export const button = style((theme) => ({
  backgroundColor: theme.brandColor,
  height: theme.grid * 11
}));

// Button.js
import React from 'react';
import { useStyles } from 'react-treat';
import * as styleRefs from './Button.treat.js';

export const Button = (props) => {
  const styles = useStyles(styleRefs);

  return <button {...props} className={styles.button} />;
};

Selection: Panda CSS

After considering various perspectives, I believe that Panda CSS is the overall best choice. However, its style of writing is unique, so if you prefer the writing style of libraries like styled-components or emotion, then Goober might be more to your liking. Additionally, Panda CSS has been developed drawing inspiration from projects like Chakra UI, Vanilla Extract, Stitches, Tailwind CSS, and Styled System. Given that it's a relatively new library, it seems to have effectively incorporated the best features from established libraries.

(Supplementary Information) Zero-runtime for Headless Components is Emerging

The following Kuma UI provides a hybrid approach with headless components where styles can be described in props and className, making it easy to implement.

Library	Key Features	GitHub Stars	Link
Kuma UI	Achieves a seamless development experience with automatic style completion. All components within the library are style-free, offering the utmost flexibility for users to apply their own styles. Supports any description style with a hybrid approach. Constantly up-to-date with cutting-edge Next.js technology through RSC support. Familiar API design. Extracts styles that can be determined at build time statically, and adopts a method to inject them at runtime by performing a static "dirty check" for styles that might change dynamically. Incorporates the best features inspired by libraries such as Styled System, Chakra UI, Native Base, Panda CSS, Linaria, Vanilla Extract, and more.	1.3k	Kuma UI GitHub

Style Writing

Kuma UI

function App() {
  return (
    <Box as="main" display="flex" flexDir={["column", "row"]}>
      <Heading
        as="h3"
        className={css`
          color: red;
          @media (max-width: sm) {
            color: blue;
          }
        `}
      >
        Kuma UI
      </Heading>
      <Spacer size={4} />
      <Flex flexDir={`column`}>
        <Text as="p" fontSize={24}>
          Headless UI Component Library
        </Text>
        <Button variant='primary'>Getting Started</Button>
      </Flex>
    </Box>
  );
}

Conclusion

In this article, we explored various zero-runtime CSS in JS libraries and tried to determine the best one. Depending on your priorities, such as emphasizing lightweight performance with Goober, your library choice may differ. It's essential to choose a library that suits your project based on each library's unique features. Thank you for reading this far.

Chrome Extension with React + CRXJS + Vite + Docker

mk668a — Tue, 09 May 2023 12:42:36 +0000

Introduction

If you are trying to develop a chrome extension in react, CRXJ is very very useful.

CRXJS provides speedy extension development experience with vite.

You can write the file name in manifest.json, and each file update is reflected instantly because the build directory directly references the file you are editing.

Let's take an example of the actual development process.

GitHub Repository

mk668a/react-vite-crxjs-chrome-boilerplate

Directory structure

.
├── Dockerfile
├── docker-compose.yml
├── index.html
├── manifest.config.ts
├── manifest.json
├── options.html
├── package.json
├── public
│   └── vite.svg
├── src
│   ├── assets
│   │   ├── favicon.svg
│   │   └── logo.svg
│   ├── background.ts
│   ├── components
│   │   └── Button.tsx
│   ├── content_scripts
│   │   └── content_script.tsx
│   ├── options.tsx
│   ├── popup.tsx
│   └── vite-env.d.ts
├── tsconfig.json
└── vite.config.ts

Create a project with React + CRXJS + Vite

Proceed by referring to the CRXJS documentation.

I have rewritten the steps in this document, modified to fit my environment.
Create a project | CRXJS Vite Plugin

Create a project

npm init vite@latest

$ npm init vite@latest
Need to install the following packages:
  create-vite@4.3.1
Ok to proceed? (y) y
✔ Project name: … vite-project
✔ Select a framework: › React
✔ Select a variant: › TypeScript

Install CRXJS Vite plugin

npm i @crxjs/vite-plugin@beta -D

Install SVGR Vite plugin (Option)

If you want to use svg with React components, install vite-plugin-svgr.

npm i vite-plugin-svgr

Change vite-env.d.ts

/// <reference types="vite/client" />
/// <reference types="vite-plugin-svgr/client" />

Update the Vite config

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { crx, ManifestV3Export } from "@crxjs/vite-plugin";
import manifest from "./manifest.json";
import svgr from "vite-plugin-svgr";

export default defineConfig({
    plugins: [
        svgr(),
        react(),
        crx({ manifest: manifest as unknown as ManifestV3Export }),
    ],
});

Create manifest.json in the root directory.

{
    "name": "Extension App",
    "description": "",
    "version": "0.0.1",
    "manifest_version": 3,
        "action": {
        "default_popup": "index.html",
        "default_title": "Open Extension App"
    }
}

Merge tsconfig(Option)

For simplicity, I merged tsconfig.node.json into tsconfig.json.

{
    "compilerOptions": {
        "composite": true,
        "module": "ESNext",
        "moduleResolution": "Node",
        "allowSyntheticDefaultImports": true,
        "target": "ESNext",
        "useDefineForClassFields": true,
        "lib": ["DOM", "DOM.Iterable", "ESNext"],
        "allowJs": false,
        "skipLibCheck": true,
        "esModuleInterop": true,
        "strict": true,
        "forceConsistentCasingInFileNames": true,
        "resolveJsonModule": true,
        "isolatedModules": true,
        "noEmit": true,
        "jsx": "react-jsx"
    },
    "include": ["src", "vite.config.ts", "*.json"]
}

Start project

npm run dev

Open Manage Extensions page in your browser.
chrome://extensions/

Turn on dveloper mode switch in the upper right corner.

Click the Load unpacked button in the upper left corner and select the dist directory in your project root directory.

Build project

This project must be built if it is to be actually used and uploaded.

npm run build

Create Dockerfile

Build Docker to quickly create an environment ready to start development.

Dockerfile

FROM node:18.15.0-alpine3.16

WORKDIR /usr/src/app

COPY package*.json ./

RUN yarn install

COPY . .

docker-compose.yml

version: '3'

services:
  extension:
    container_name: extension
    hostname: extension
    restart: always
    tty: true
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - 5173:5173
    volumes:
      - .:/usr/src/app
    command: yarn dev --host
    networks:
      - default
    platform: linux/amd64

networks:
  default:

I am using an M1 MacBook, so I have written platform: linux/amd64 in the docker-compose.yml file and turned on Use Rosetta for x86/amd64 emulation of Apple Silicon of Docker setting is turned on.

Run Docker

docker compose up -d --build

Fixed Popup

This is a bit confusing because the file name and function do not match, so we will modify it a bit.

Delete App.tx and rename main.tx to popup.tx.

Modify popup.tsx.

import React, { useState } from "react";
import ReactDOM from "react-dom/client";
import logo from "./assets/logo.svg";

function Popup() {
    const [count, setCount] = useState(0);

    return (
        <div className="App" style={{ height: 300, width: 300 }}>
            <header className="App-header">
                <img
                    src={chrome.runtime.getURL(logo)}
                    className="App-logo"
                    alt="logo"
                />
                <p>Hello Vite + React!</p>
                <p>
                    <button type="button" onClick={() => setCount((count) => count + 1)}>
                        count is: {count}
                    </button>
                </p>
                <p>
                    Edit <code>App.tsx</code> and save to test HMR updates.
                </p>
                <p>
                    <a
                        className="App-link"
                        href="https://reactjs.org"
                        target="_blank"
                        rel="noopener noreferrer"
                    >
                        Learn React
                    </a>
                    {" | "}
                    <a
                        className="App-link"
                        href="https://vitejs.dev/guide/features.html"
                        target="_blank"
                        rel="noopener noreferrer"
                    >
                        Vite Docs
                    </a>
                </p>
            </header>
        </div>
    );
}

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
    <React.StrictMode>
        <Popup />
    </React.StrictMode>
);

Fix src attribute of script tag in index.html.

<script type="module" src="/src/popup.tsx"></script>

Create Content Scripts

Add content_scripts section in manifest.json.

{
    "name": "Extension App",
    "description": "",
    "version": "0.0.1",
    "manifest_version": 3,
    "action": {
        "default_popup": "index.html",
        "default_title": "Open Extension App"
    },
    "content_scripts": [
        {
            "matches": ["<all_urls>"],
            "js": ["src/content_scripts/content_script.tsx"]
        }
    ]
}

Make content_scripts directory in src directory.

Create sample content_script component in src/content_scripts/content_script.tsx.

import React from "react";
import ReactDOM from "react-dom/client";
import Button from "../components/Button";

function ContentScript() {
    return (
        <div className="App">
            <header className="App-header">
                <h1>ContentScript</h1>
                <Button>button</Button>
            </header>
        </div>
    );
}

const index = document.createElement("div");
index.id = "content-script";
document.body.appendChild(index);

ReactDOM.createRoot(index).render(
    <React.StrictMode>
        <ContentScript />
    </React.StrictMode>
);

At the same time, create a component directory and Button.tsx file.

import React from "react";

const Button = (props: any) => <button {...props} />;

export default Button;

Create Background

Add a definition of background to manifest.json.

Note that if you want to use certain features of the chrome API, it is necessary to add some permissions to permissions.

Chrome Extensions Declare permissions

{
    "name": "Extension App",
    "description": "",
    "version": "0.0.1",
    "manifest_version": 3,
    "action": {
        "default_popup": "index.html",
        "default_title": "Open Extension App"
    },
    "content_scripts": [
        {
            "matches": ["<all_urls>"],
            "js": ["src/content_scripts/content_script.tsx"]
        }
    ],
    "background": {
        "service_worker": "src/background.ts",
        "type": "module"
    },
    "permissions": [
        "background",
        "contextMenus",
        "bookmarks",
        "tabs",
        "storage",
        "history"
    ]
}

Make background.ts file in src directory.

This is the sapmle code to add event listener of changing tab and to get the bookmarks.

chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {
    console.log(`Change URL: ${tab.url}`);
});

chrome.bookmarks.getRecent(10, (results) => {
    console.log(`bookmarks:`, results);
});

console.log(`this is background service worker`);

export {};

Create Options

This is an options page which can be accessed by right-clicking the extension icon on the toolbar and selecting Options.

Add options_page section to manifest.json.

{
    "name": "Extension App",
    "description": "",
    "version": "0.0.1",
    "manifest_version": 3,
    "action": {
        "default_popup": "index.html",
        "default_title": "Open Extension App"
    },
    "content_scripts": [
        {
            "matches": ["<all_urls>"],
            "js": ["src/content_scripts/content_script.tsx"]
        }
    ],
    "background": {
        "service_worker": "src/background.ts",
        "type": "module"
    },
    "options_page": "options.html",
    "permissions": [
        "background",
        "contextMenus",
        "bookmarks",
        "tabs",
        "storage",
        "history"
    ]
}

Create options.html.

It is almost the same as index.html, but the src attribute of the script tag must be changed.

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <link rel="icon" type="image/svg+xml" href="/vite.svg" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Extension App</title>
    </head>
    <body>
        <script type="module" src="/src/options.tsx"></script>
    </body>
</html>

Make options.tsx file in src directory.

import React from "react";
import ReactDOM from "react-dom/client";
import Button from "./components/Button";

function Options() {
    console.log(`this is options page`);

    return (
        <div className="App">
            <header className="App-header">
                <h1>Title</h1>
                <Button>button</Button>
            </header>
        </div>
    );
}

const index = document.createElement("div");
index.id = "options";
document.body.appendChild(index);

ReactDOM.createRoot(index).render(
    <React.StrictMode>
        <Options />
    </React.StrictMode>
);

Conclusion

CRXJS improves the experience of developing extensions with React.
Also, you can easily set it up using Docker.

I am now trying to create a new panel in the Developer tool. If it works, I will update this post.

Thank you for reading.

Reference

GitHub Repository

mk668a/react-vite-crxjs-chrome-boilerplate

DEV Community: mk668a

Run Claude across all your repos from one session — without merging anyone's .claude/

Run Claude across all your repos from one session

The gap it fills

Teach your root Claude to do it on its own

One repo, or fan out to all

How it works

Why it's safe to rely on

What it doesn't do yet

Install

Grammarly costs $12/mo — a local LLM does it for free (Chrome + Ollama)

The missing ingredient was never the AI

Design decision #1: the LLM never produces the diff

Design decision #2: silencing Ollama's 403 with declarativeNetRequest

MV3 architecture: do the fetch in the service worker

Wrapping up

Position tooltips and popovers with native CSS — zero runtime JS

The gap it fills

The API is the one you already know

You don't have to migrate by hand

Honest limitations

Install

Which package is bloating your Docker image?

The gap it fills

Where do Python's 137 MB actually go?

Using it

How it works

Known boundaries

Install

Your polyfills are dead. Here's a robot that buries them.

The problem: polyfills never leave

The signal: Web Platform Baseline

The tool: baseline-polyfill-pruner

How it decides

How it maps polyfills to features

Using it

As a CLI

As a GitHub Action (the point)

Why this didn't already exist

One design note worth stealing

I built GhostType: inline AI text completion for every app on macOS

What it is

Why local-only

How it works under the hood

Try it

What's next

Code Map: Visualize Code Dependencies with LLM

🚀 What is LLM Code Map?

Key Features

🤖 The "Killer Feature": AI Integration

🛠️ How to Try It Out

Quick Start (Development Mode)

1. Clone the Repository

2. Install Dependencies

3. Compile

4. Launch in VSCode

📖 How to Use

1. Manual Usage (Sidebar)

2. Usage via AI Agent

🏗️ Under the Hood

🤝 Contributing

What is Zero-Runtime CSS in JS? Which Library Should You Pick?

Introduction: The End of CSS in JS and the Transition to Zero-Runtime

Why We're Breaking Up with CSS-in-JS

Sam Magura ・ Oct 16 '22

Why We're Breaking Up with CSS-in-JS

Drawbacks of CSS in JS

The Future of CSS Libraries

Transition to Zero-Runtime CSS in JS

What is Zero-Runtime CSS in JS?

Benefits of Zero-Runtime CSS in JS

Using CSS in JS with Next.js

List of Zero-Runtime CSS-in-JS Libraries

So, Which CSS-in-JS Library Should You Use?

Selection: Panda CSS

(Supplementary Information) Zero-runtime for Headless Components is Emerging

Conclusion

Chrome Extension with React + CRXJS + Vite + Docker

Introduction

GitHub Repository

The tool: `baseline-polyfill-pruner`