DEV Community: benjamin

GitHub Actions won't tell you your CI is getting worse. I built a zero-dep CLI that does.

benjamin — Fri, 03 Jul 2026 06:43:16 +0000

GitHub Actions shows you one run at a time. Green check, red X, green check, green check, red X. You scroll the list, you re-run the flaky one, you move on. Nobody's asking the question that actually matters: is this getting better or worse?

"I calculated how much my CI failures actually cost. Curious what your pipeline success rate looks like — has anyone else tracked the actual wasted compute time over time?"

That's a real question from someone who did the math by hand and found their failures were burning a real chunk of their compute budget. The replies were the same story you'd expect: heavyweight CI platforms have their own dashboards for this, but nobody had a lightweight, local way to just... track it.

So I built citrend: pull your GitHub Actions run history into a local file, get a trend.

npx citrend sync --repo owner/name
npx citrend report --repo owner/name

What it actually shows you

$ citrend report --repo acme/widgets

acme/widgets — 812 run(s) (2 in progress)

  success rate:    87.4%  (699/800 settled, 12 skipped)
  wasted runs:     101 (12.6%)
  total compute:   118h 42m
  wasted compute:  14h 6m

  weekly trend (oldest → newest):
    2026-06-05  91.2% success, 8 wasted (58m)
    2026-06-12  88.0% success, 11 wasted (1h 22m)
    2026-06-19  79.4% success, 22 wasted (3h 8m)
    2026-06-26  84.1% success, 15 wasted (2h 1m)

That weekly column is the entire point. A single gh run list will never show you that week 3 was a cliff — you'd have to notice it got annoying to work in, which is a much slower and much less precise signal than a number going from 91% to 79%.

How it works

sync pulls your workflow run history from the GitHub REST API and caches it locally (deduped by run id, so you can run it on a schedule without piling up duplicates). report reads that cache — no network call — and computes:

Success rate, over settled runs only (still-running runs don't count either way until they conclude, and skipped runs are excluded from the denominator since they're not a pass/fail outcome).
"Wasted" runs and compute — anything that settled and wasn't a success or a skip: failures, cancellations, timeouts. "Compute" here is wall-clock run duration from the Actions API, a solid proxy for burned runner time, not an exact billed-minutes figure.
A weekly trend, so a slow decline (or a sudden cliff) is visible instead of buried in a scrolling run list.

Install

npx citrend sync --repo owner/name --token $GITHUB_TOKEN   # token optional for public repos, raises the 60/hr rate limit
npx citrend report --repo owner/name --weeks 8

pip install citrend   # Python build, same commands, shares the same local cache format

Zero dependencies in either language — just the standard library talking to api.github.com. History lives at ~/.citrend/<owner>__<repo>/, not committed to the repo it's tracking (it's a cache of data GitHub already has, not something worth diffing in git).

npm: https://www.npmjs.com/package/citrend
PyPI: https://pypi.org/project/citrend/
GitHub (Node): https://github.com/jjdoor/citrend
GitHub (Python): https://github.com/jjdoor/citrend-py

Does your team track this anywhere already — a scheduled job dumping stats into a spreadsheet, a Grafana panel someone built once and nobody looks at? Curious what's actually surviving in practice versus what gets built and abandoned.

The same root cause keeps coming back because nobody tracks it. I built a zero-dep CLI that does.

benjamin — Fri, 03 Jul 2026 03:38:57 +0000

You write the postmortem. You file the action items. Everyone nods, the doc gets archived, and life moves on.

Six months later, the exact same root cause takes down the exact same service — and nobody in the room remembers the first incident, let alone that its fix never actually shipped.

"We use rootly to track this automatically. It flags when incidents have the same root cause as previous ones."

That's a real answer from an SRE thread about this exact problem — and it's a paid, hosted feature of a full incident-management platform. Most teams don't have rootly or incident.io. What they have is a folder of markdown postmortems that nobody diffs against each other.

So I built rootecho: a zero-dependency CLI that does the one useful thing those platforms do for this — flag when a new incident's root cause echoes a past one, and show you whether that past incident's action items ever actually got finished.

How it works

Each postmortem is one JSON record — free-text root_cause and/or curated root_cause_tags, plus action_items with a status:

{
  "id": "INC-2026-014",
  "title": "Payment webhook retries exhausted",
  "root_cause": "webhook retry queue misconfigured to drop after 3 attempts, no dead-letter fallback",
  "root_cause_tags": ["webhook", "retry-queue", "dead-letter", "config"],
  "action_items": [
    { "id": "AI-1", "description": "Add dead-letter queue for webhook retries", "owner": "alice", "status": "open" }
  ]
}

rootecho add records it and compares against your history:

$ rootecho add inc-2026-014.json
⚠ root cause echo detected for "INC-2026-014":

  INC-2026-003 (2026-03-15) — 100% similar root cause
  Payment webhook retries exhausted
    ✓ Add retry backoff [done]
    ✗ Add monitoring alert for queue depth [open] — 93d overdue
  → 1 action item(s) from this past incident were never finished.

recorded to .rootecho/history.jsonl

That's the whole point of the tool in one output: not just "you've seen this before," but "and here's the fix that never happened."

rootecho check does the same comparison without recording — exit code 1 on an echo, so you can wire it into CI as a gate on the PR that closes out a postmortem.

Why not just grep the old postmortems?

Because "webhook retry queue misconfigured" and "retry queue drops webhooks after repeated failures" are the same root cause in different words, and grep doesn't know that. rootecho scores similarity with Jaccard overlap — tags first (curated, low-noise, weighted 70%), free text as a fallback/secondary signal (30%) — no ML dependency, no network call, runs in milliseconds on a folder of JSON files.

Design notes for the technical reader

Storage is project-local, not ~/.rootecho. History lives in .rootecho/history.jsonl in your repo, one JSON object per line, meant to be committed — so git blame/git log on that file doubles as an incident timeline the whole team shares, and git diff on it during a PR review shows exactly what changed.
Zero dependencies, dual-language. A Node build (npx rootecho) and a Python build (pip install rootecho) exist because teams aren't single-language, and they read/write the exact same history file — down to byte-identical --json output, which took more care than I expected (Python's json.dumps escapes non-ASCII by default and prints whole floats as 1.0; JS's Date.parse and Python's datetime.fromisoformat accept different date grammars depending on Python version. All ironed out — timestamps are epoch milliseconds on both sides, dates are a hand-rolled strict ISO 8601 parser shared in spirit between both implementations instead of trusting either language's built-in leniency).
Corrupt data degrades, it doesn't crash. A JSONL file meant to be hand-edited and merged by a team will occasionally get a stray null line from a bad merge. Both CLIs skip malformed entries instead of taking down add/check/list for the whole team.

Install

npx rootecho init incident.json      # scaffold a postmortem
npx rootecho add incident.json       # record it, flag any echo

pip install rootecho                 # or the Python build

MIT licensed, ~500 lines total, no dependencies in either language.

npm: https://www.npmjs.com/package/rootecho
PyPI: https://pypi.org/project/rootecho/
GitHub (Node): https://github.com/jjdoor/rootecho
GitHub (Python): https://github.com/jjdoor/rootecho-py

Does your team already have a home-grown way of catching repeat root causes — a spreadsheet, a Slack bot, a wiki convention? I'd like to hear what's actually working (or not) before I add anything past this MVP.

branchreap: safely reap merged & gone-upstream git branches (zero-dep, npx or pip)

benjamin — Wed, 01 Jul 2026 07:59:53 +0000

I ran git branch on a repo I'd been on for a year and counted forty-seven local branches. Maybe six were alive. The rest were feature/* that shipped months ago, fix/* whose PRs merged and whose remotes were deleted the same minute, and a couple of experiments I'd genuinely forgotten writing.

The usual advice is:

git branch --merged | grep -v '\*' | xargs git branch -d

I've pasted that snippet into a dozen shells. It has three problems: it misses branches whose upstream is gone (deleted remote, but the local sticks around forever), it cheerfully includes main if you forget the grep, and it makes you the safety check.

So I built branchreap — it finds the branches that are actually safe to reap, and only those.

npx branchreap          # scan, read-only
# or
pip install branchreap

What it reaps — and what it refuses to

Reaps:

merged branches (fully merged into your default branch)
gone branches (upstream deleted), as long as they carry no unmerged commits

Never touches:

the current branch
the default branch (main / master / whatever origin/HEAD says)
anything unmerged / unpushed, unless you explicitly pass --include-unmerged (and even then it still won't delete current or default)

That safety floor is the whole design. Run it without reading a word of docs and the worst case is it deletes a branch git itself already considers merged.

What it looks like

$ branchreap

default branch: main

  ✗ feature/old-login          merged         merged into main
  ✗ fix/typo                    gone           upstream gone · merged into main
  ────────────────────────────────────────────────────────
  2 reapable  (1 merged · 1 gone)  ·  4 kept

  1 gone branch(es) held back (unmerged commits). Use --include-unmerged to reap.

$ branchreap clean            # asks first
$ branchreap clean --yes      # for a shell alias

--dry-run previews, --json pipes, --fetch runs a git fetch --prune first so the gone status is fresh (git only marks upstreams gone after a prune).

Why another branch cleaner?

There are a few good ones (git-sweep, git-trim), but most are single-purpose — merged-only or remote-only — and several are unmaintained. branchreap does merged and gone in one pass, leads with safety, and is genuinely zero-dependency: it just shells out to git and parses the output. Same logic ships as a Node package and a Python package (byte-for-byte aligned), so npx branchreap and pipx run branchreap both work with nothing to install.

Try it

npx branchreap          # Node
pipx run branchreap     # Python

npm: https://www.npmjs.com/package/branchreap
PyPI: https://pypi.org/project/branchreap/
GitHub: https://github.com/jjdoor/branchreap

How many local branches are in your busiest repo right now? Run git branch | wc -l and tell me — I bet it's higher than you'd guess. 👇

diskreap: reclaim disk from build artifacts & dep caches, across every language

benjamin — Mon, 29 Jun 2026 08:18:04 +0000

My disk filled up last week. Not from anything I was actively working on — from the graveyard of projects in ~/code. Forty-odd repos, each carrying a node_modules I haven't touched in months, a target/ from that Rust experiment, a .venv here, a .next there. Tens of gigabytes of stuff that a single command would regenerate, just… sitting there.

The annoying part isn't deleting it. It's finding it. du -sh */node_modules only catches Node. Then you do it again for .venv, again for target, again for __pycache__. Different command, different ecosystem, every time.

So I built diskreap — one zero-dependency command that finds reclaimable build artifacts and dependency caches across every language at once, shows you what's eating your disk, and deletes only what's safely regenerable.

npx diskreap            # scan the current directory
# or
pip install diskreap

Why not just `npkill` / `kondo`?

They're good — I used both. But each covers one corner:

npkill is node_modules-only.
kondo is great and multi-language, but it's a Rust binary you have to install first.

diskreap runs instantly with npx (or pipx run diskreap), needs nothing installed, and reaches every ecosystem in a single scan: node_modules, .venv/venv, __pycache__, .pytest_cache, .mypy_cache, .ruff_cache, .next, .nuxt, .svelte-kit, .turbo, .parcel-cache, target, .gradle, vendor, dist/build, .terraform, Pods.

Using it

Scan first — it never deletes without being asked:

$ diskreap scan ~/code

  /Users/you/code

     1.2 GB  Rust/Maven build scanner/target         · 5d ago
     412 MB  Node deps        webapp/node_modules     · 3w ago
      88 MB  Python venv      ml-notes/.venv          · 2mo ago
     ────────────────────────────────────────────────
     total reclaimable: 1.7 GB across 12 dir(s)

Then reclaim, with filters to scope the sweep:

diskreap clean ~/code --dry-run        # preview exactly what would go
diskreap clean ~/code --older 60d      # only long-idle projects
diskreap clean ~/code --min 100MB      # skip the small fry
diskreap clean ~/code --yes            # no prompt (CI / scripts)

--json is there too, if you want to pipe the scan somewhere.

The one design decision that mattered: safety

The scary names are the generic ones. node_modules is unambiguous — but target, dist, build, vendor could just as easily be your folders.

So diskreap only treats a generic name as reclaimable when a sibling project file proves its origin: target/ counts next to a Cargo.toml or pom.xml; dist/ and build/ count next to a package.json/pyproject.toml/setup.py; vendor/ next to a composer.json/go.mod. A bare build/ of your own files is never touched. Symlinks are never followed, and clean always confirms unless you pass --yes.

It's also genuinely zero-dependency — pure Node stdlib and pure Python stdlib, same logic in both, byte-for-byte aligned output. No supply chain, nothing to audit.

Try it

npx diskreap          # Node
pipx run diskreap     # Python

npm: https://www.npmjs.com/package/diskreap
PyPI: https://pypi.org/project/diskreap/
GitHub: https://github.com/jjdoor/diskreap

What's the most disk you've ever clawed back from a single ~/code sweep? And which artifact dir surprised you the most — for me it's always .gradle. 👇

My code reviewer kept asking for JSDoc — so I built a zero-dep CLI that catches it first

benjamin — Tue, 23 Jun 2026 03:36:54 +0000

I kept running eslint and thinking my codebase was fine — then someone opened a PR and the first comment was "this function needs JSDoc."

The problem: linters check your syntax. Nobody checks whether your exported API is actually documented. Those are two very different things.

So I built jsdocscan — a zero-dependency CLI that walks your JS/TS files and flags every exported function or class that is missing JSDoc, or has undocumented parameters.

What it catches

Errors — exported function or class with no /** … */ block at all:

✗ src/api.js:12 fetchUser  missing JSDoc
✗ src/utils.js:34 formatDate  missing JSDoc

Warnings — JSDoc exists but a parameter has no @param tag:

! src/render.js:7 renderCard  undocumented params: opts

Exit codes are 0 (all clean), 1 (issues found), 2 (usage error) — pipe-friendly.

How to use it

# scan a directory
npx jsdocscan src/

# Python version
pip install jsdocscan
jsdocscan src/

# skip @param checks — just verify JSDoc exists
npx jsdocscan --no-params src/

# machine-readable output
npx jsdocscan --json src/ | jq '.[].findings'

# summary line only
npx jsdocscan --quiet src/

# custom extensions
npx jsdocscan --ext .js,.ts src/

What it skips (intentionally)

Non-exported functions and internal helpers — these are implementation details
Destructured params ({ a, b }) — too many valid @param opts patterns
TypeScript type annotations on params — name: string is stripped, @param name is still required

Zero dependencies

No parsers, no AST, no require("typescript"). It uses a line-by-line scanner that:

Detects export function/const/class patterns via regexes
Walks backwards to find a preceding /** */ block
Compares @param names in the JSDoc against the actual parameter list

npx jsdocscan works with zero install time. pip install jsdocscan brings in nothing extra.

Links

Both versions pass the same 38-test suite. Same exit codes, same output format.

I kept finding gaps in my repos after open-sourcing — so I built a zero-dep CLI to catch them first

benjamin — Mon, 22 Jun 2026 13:15:31 +0000

You've just bootstrapped a new project. You have the code, the tests, the CI. Then a week later someone opens an issue asking for a license. Another asks why there's no CHANGELOG. Your package.json has been missing a description field since day one — you just never noticed.

This isn't a bug. It's a repo hygiene gap. And it's easy to miss when you're moving fast.

So I built repogap — a zero-dependency CLI that catches these gaps before they become problems.

What it checks

Run it in any repo:

$ repogap

  ✓ README.md
  ✗ LICENSE         missing
  ✓ .gitignore
  ! CHANGELOG       missing (recommended)

  package.json
    ✓ name          my-tool
    ✓ version       1.0.0
    ✗ description   missing or empty
    ✓ license       MIT
    ! repository    missing

repogap: drift detected — 2 errors, 2 warnings

File checks (auto-detected, all variants):

README — accepts .md, .rst, .txt, bare
LICENSE — accepts LICENCE, COPYING, .txt, .md
.gitignore
CHANGELOG — warn by default, accepts .md, .rst, HISTORY.md, etc.

Manifest field checks (auto-detects package.json or pyproject.toml):

name, version, description, license — required
repository — warn

Install (zero dependencies)

# Node — no install needed
npx repogap

# Python
pip install repogap
repogap

Both versions produce identical output. Drop either one into CI and it behaves the same way.

Flags

repogap --strict         # warnings become errors (exit 1)
repogap --no-changelog   # skip CHANGELOG check
repogap --no-fields      # skip manifest field checks
repogap --json           # machine-readable output
repogap ./packages/ui    # check a sub-package

Add to CI

- name: Check repo hygiene
  run: npx repogap

Or run it once before open-sourcing a private repo:

npx repogap

Design note: warnings vs errors

The distinction is intentional. Missing README, LICENSE, .gitignore, or a blank description are errors — they're either legally important (LICENSE), functionally broken (description shows up in npm search), or universally expected. A missing CHANGELOG and repository field are warnings — common gaps, but not blocking.

--strict collapses the distinction if you want zero tolerance.

I kept shipping version mismatches — so I built a zero-dep CLI that checks all three sources at once

benjamin — Mon, 22 Jun 2026 07:59:33 +0000

You know the drill. You bump package.json, update the CHANGELOG, run the tests, push the tag — and then someone opens a bug report six hours later because the latest entry in CHANGELOG.md still says 1.3.1.

It's not a bug in your code. It's a release metadata mismatch. And it happens way more often than it should.

Why existing tools don't fully cover this

semantic-release is great if you let a bot own your entire release workflow. For solo projects or teams who prefer manual control, it's overkill — and it owns your tag format too.
standard-version is deprecated.
There's no lightweight way to just check that three things agree: your manifest version, your changelog's latest entry, and your latest git tag.

So after the third time I shipped a mismatch, I built verscan.

What it does

Run it before every release (or add it to CI):

$ verscan

  ✓ package.json   1.4.0  (reference)
  ✓ CHANGELOG.md   1.4.0
  ✓ git tag        1.4.0

verscan: all sources match → 1.4.0

It checks three sources in one shot:

package.json version (or pyproject.toml — auto-detected)
Latest ## [x.y.z] heading in your CHANGELOG.md
Latest git tag via git describe --tags --abbrev=0

When something disagrees, it tells you exactly what:

$ verscan

  ✓ package.json   1.4.0  (reference)
  ! CHANGELOG.md   [no version heading found in CHANGELOG.md]
  ✓ git tag        1.4.0

verscan: 1 source(s) could not be read

Exit codes: 0 all match · 1 mismatch · 2 parse/read error — CI-friendly by design.

Install (zero dependencies, dual Node + Python)

# Node — no install needed
npx verscan

# Python
pip install verscan
verscan

Both versions produce identical output. I wrote them that way intentionally — if your team spans both toolchains, either version drops into CI without behavioral differences.

Flags

verscan --no-git          # skip git tag check (useful before you've tagged)
verscan --no-changelog    # skip CHANGELOG (for projects without one)
verscan --json            # machine-readable output
verscan ./packages/ui     # check a sub-package

Drop it in CI or a pre-push hook

# GitHub Actions
- name: Verify versions aligned
  run: npx verscan

# pre-push hook
echo 'verscan' >> .git/hooks/pre-push
chmod +x .git/hooks/pre-push

Two design decisions worth noting

Why regex instead of a TOML parser for pyproject.toml?
tomllib is only available in Python 3.11+. To support Python >= 3.8 with zero dependencies, I use a targeted regex: r'^\[project\][^[]*?\bversion\s*=\s*["\']([^"\']+)["\']' with MULTILINE|DOTALL. It's deliberately conservative — it only matches version inside [project], not [tool.poetry] or anywhere else.

Why three sources instead of two?
The most common mismatch I've seen isn't the manifest vs. the tag — it's the CHANGELOG vs. everything else. Bumping package.json is often automated; updating the changelog is manual. Three-way verification catches both the "forgot to tag" and "forgot to update CHANGELOG" cases in one pass.

A reformatted PR shows 80 changed lines but changed nothing — I built a zero-dep diff that sees through it

benjamin — Mon, 22 Jun 2026 02:17:45 +0000

Someone runs the formatter, the line width changes, and suddenly the pull request touches 80 lines. You scroll through all of it looking for the actual change — and there isn't one. Or there's exactly one, buried in 79 lines of re-wrapping. We've all reviewed that PR.

git diff -w is supposed to save you here, and it half does: it ignores spacing changes. But it's still line-anchored, so it cannot fold reflow — re-wrap a function signature across three lines and git diff -w still shows 1 removed + 3 added, even though not a single token changed. (This is GitHub discussion #20610, "Ignore Format Changes in Diff" — open and unanswered for years.)

So I built logicdiff: a diff that folds away whitespace and reflow, and tells you whether a change is real or just formatting.

$ logicdiff old.js new.js
only formatting differs - no logical change (a line diff would show 80 changed lines)

$ logicdiff a.js b.js
--- a.js
+++ b.js
-42:   const total = price * qty;
+51:   const total = price + qty;

1 token removed, 1 added across 2 logical lines (78 lines folded as reflow/whitespace)

It exits 0 when the change is formatting-only and 1 when it's logical — so CI can flag "this PR is more than a reformat, review carefully." Zero dependencies, and pip install logicdiff gets the same tool in Python with byte-for-byte identical output.

How it folds reflow

The trick is to stop diffing lines and diff tokens. logicdiff tokenizes each file into a stream where a token is a run of [A-Za-z0-9_] or a single punctuation character, and whitespace is dropped entirely. So all of these collapse to the same stream [a, +, b]:

a+b        a + b        a +
                          b

Respacing and line breaks become invisible. Then it runs a plain Myers diff on the token streams. Equal streams ⇒ formatting-only. Different ⇒ the changed tokens get mapped back to their line numbers and shown. Crucially, tokens are compared by text only — their line numbers are metadata — which is exactly why a token that moved to a different line still matches.

It's language-agnostic on purpose: no parser, no grammar, works on any text (code, YAML, logs, DSLs). The trade-off, which I document rather than hide: like git diff -w, whitespace inside string literals is also ignored — "a b" and "a b" read as formatting-only. (difftastic gets this right with per-language tree-sitter parsing, but it's a multi-megabyte binary that needs a grammar per language and has no "is this formatting-only?" exit code. logicdiff is the zero-config, language-agnostic middle ground.)

The fun part: two languages, one diff, to the byte

I wanted a Node build and a Python build that emit identical output — and a diff is a brutal place to attempt that, because Myers has many equal-cost edit scripts and the one you emit depends entirely on tie-breaking. Pick < vs <= in one line and the two languages silently diverge (both "correct", different output).

So the whole thing is pinned:

One canonical Myers variant, ported literally to both languages: V seeded V[1]=0, k from -d to d step 2, the down-vs-right choice is exactly k == -d || (k != d && V[k-1] < V[k+1]) (strict <), and V is snapshotted before each round so backtracking reads the right one. No difflib.SequenceMatcher (its heuristics wouldn't match).
Files are read as latin-1 — the one encoding where byte ↔ codepoint is a total bijection — so any input (UTF-8, binary, broken) decodes deterministically, token equality is byte equality, and Node's UTF-16 string indexing vs Python's codepoint indexing stops mattering.
The tokenizer uses explicit ASCII classes, never \w/\s (those are Unicode-aware in Python but ASCII in JS).

A differential fuzz test runs both builds over 500 random file pairs and gets zero byte differences.

Install

npx logicdiff old new       # Node, zero deps
pip install logicdiff       # Python, zero deps, identical output

MIT licensed, both builds open source:

npm: https://www.npmjs.com/package/logicdiff
PyPI: https://pypi.org/project/logicdiff/
GitHub: https://github.com/jjdoor/logicdiff (Node) · https://github.com/jjdoor/logicdiff-py (Python)

What's your worst "the diff is all noise" story — a formatter run, a line-ending flip, a mass re-indent? And would a formatting-only CI signal have helped?

Your repo has whitespace problems you can't see — I built a zero-dep CLI that finds and fixes them all

benjamin — Sat, 20 Jun 2026 15:46:05 +0000

Whitespace problems are the ones you can't see until they bite. A pull request where half the "changes" are trailing-space diffs. A shell script that breaks in CI because someone's editor saved it CRLF. A .env with a UTF-8 BOM that makes the first variable name mysteriously not match. A file with no final newline that turns one-line changes into two-line diffs forever.

None of it shows up on screen. All of it shows up in git blame.

Today, catching this takes three or four tools stitched together — and I got tired of that, so I built wssweep: one zero-config command that finds all the common whitespace smells and, with --fix, cleans them in place.

$ npx wssweep

  src/app.js  (2)
      14: trailing-whitespace  trailing whitespace
       -  missing-final-newline  no newline at end of file
  config.yml  (1)
       -  mixed-eol  mixed line endings (CRLF×3, LF×1)

  ✖ 3 whitespace issues in 2 files  (mixed-eol=1, missing-final-newline=1, trailing-whitespace=1)

$ npx wssweep --fix     # clean them

It checks seven things: trailing whitespace, mixed CRLF/LF line endings, lone CRs, a missing final newline, extra trailing blank lines, a UTF-8 BOM, and tabs mixed with spaces in one indent. Non-zero exit on findings, so it's a CI gate. pip install wssweep gets the same tool in Python — byte-for-byte identical output and fixes.

Why not editorconfig-checker / pre-commit / prettier?

Because each does part of it:

editorconfig-checker reports — but you have to author an .editorconfig first, and it can't fix anything.
pre-commit's trailing-whitespace / end-of-file-fixer / mixed-line-ending hooks do fix, but only inside the pre-commit framework, and they're three separate hooks. Nobody runs them ad-hoc on a fresh checkout.
prettier fixes whitespace only as a side effect of reformatting all your code, and won't touch files it can't parse.
dos2unix does line endings and nothing else.

wssweep is the one npx/pip command, no config and no framework, that does the whole set at once and drops into any CI regardless of toolchain.

The opinions that make it zero-config

A whitespace tool with no config has to make the right calls by default, or it's noise:

A consistently-CRLF file is fine — only a file mixing CRLF and LF is flagged. .bat/.cmd even keep CRLF when fixed, so it never breaks a Windows script.
In Markdown, a line ending in exactly two spaces is a hard line break — semantically meaningful — so the trailing-whitespace check is skipped in .md. (BOM, final-newline, and EOL checks still apply.)
mixed-indentation is report-only. Auto-converting tabs↔spaces needs a tab-width guess that can silently wreck alignment, so wssweep tells you and leaves it.

The fun part: --fix that two languages agree on, to the byte

I wanted a Node build and a Python build that produce identical reports and write identical bytes on --fix. Whitespace is the worst possible domain for that, because every shortcut leaks platform behavior:

str.splitlines() in Python splits on VT, FF, NEL, U+2028, U+2029 too — it would invent phantom lines a split(/\r\n|\r|\n/) never sees. Forbidden.
\s matches different things in JS and Python (NBSP, the BOM char, …). So "whitespace" here means exactly [ \t] — explicit, never \s.
Python's text-mode file IO silently translates \r\n→\n on read and \n→os.linesep on write — it would rewrite the very bytes the tool inspects. So everything is raw bytes, and the scan runs on a latin-1 (byte-faithful) view where every byte maps 1:1 to a code point.
--fix builds the corrected bytes, compares to the original, and writes only if they differ — atomically (temp file + rename), preserving the file mode, never touching a binary or skipped file. And it's idempotent: run it twice, the second run does nothing.

A differential test fixes two identical trees with the two builds and cmps every file — zero differing bytes.

Install

npx wssweep --fix      # Node, zero deps
pip install wssweep    # Python, zero deps, identical fixes

MIT licensed, both builds open source:

npm: https://www.npmjs.com/package/wssweep
PyPI: https://pypi.org/project/wssweep/
GitHub: https://github.com/jjdoor/wssweep (Node) · https://github.com/jjdoor/wssweep-py (Python)

Run npx wssweep on your current project. How many trailing-whitespace lines and missing newlines is it hiding? (Mine's never zero.)

Your design-token migration isn't done — here's a zero-dep CLI that finds the colors that escaped

benjamin — Sat, 20 Jun 2026 14:21:04 +0000

You did the design-token migration. You celebrated. Then three months later someone changed the brand color, dark mode shipped, and a dozen buttons stayed stubbornly the old blue — because they still had background: #3f82f0 hardcoded instead of var(--primary), and nobody noticed.

This is the boring, recurring way token systems rot: the migration is "done," but raw colors are still buried in components, and you don't find out until the day they break.

So I built hexsweep — a zero-dependency CLI that scans your source and flags the raw color literals that escaped:

$ npx hexsweep src/

  src/components/Button.tsx  (2)
    14:18  #3f82f0  [hex6]  background
    27:10  rgb(255, 0, 0)  [rgb]  color

  ✖ 2 hardcoded colors in 1 file (23 files clean)

It exits non-zero when it finds something, so it drops straight into CI as a gate. pip install hexsweep gets you the same tool in Python — the two builds print byte-for-byte identical output.

"Just grep for it" — no

The reflex is grep '#[0-9a-f]{6}'. It's noisy enough that nobody keeps it in CI:

it flags #header id-selectors and url(#gradient) references (not colors);
it flags colors sitting in comments;
it misses rgb()/hsl(), 3/4/8-digit hex, and CSS-in-JS;
and it has no idea that --primary: #3f82f0 is correct and color: #3f82f0 is the bug.

"Use stylelint" — closer, but it yells at the wrong file

stylelint's color-no-hex can do this for plain CSS, but it needs a config + postcss/custom-syntax, it can't see hex inside TSX/CSS-in-JS string literals, and — the part that makes people turn it off — it flags your tokens.css exactly as loudly as a stray hex in a component. The request to exempt token definitions has sat open and unimplemented for years. So the one file that's supposed to contain raw colors is the loudest thing in your report.

hexsweep's whole point is that distinction:

--primary: #3f82f0 (a definition — custom property, $scss, or @less var) → allowed by default. That's where colors are supposed to live.
color: #3f82f0 (a usage) → flagged.

Run --strict if you want zero raw hex anywhere, tokens included.

The fun part: a linter with no parser, that two languages agree on byte-for-byte

I wanted a Node build and a Python build with identical output, and I wanted zero dependencies — which rules out a real CSS/JS parser. So hexsweep is a line scanner with a few careful tricks:

It blanks comment spans (//, /* */, ) to spaces with a small state machine — but keeps string contents, because CSS-in-JS colors live in strings (styled.div`color:#3f82f0` should be caught).
An id-selector / url() gate disambiguates #fff { (a selector) from color: #fff (a value) by position.
The hex regex enumerates only legal lengths (3/4/6/8) so #1234567 isn't half-matched.

Getting Node and Python to agree to the byte was the real work — and the bugs are exactly the cross-language ones you'd expect: Python's \d/\w match Unicode digits while JS's don't (so every regex uses explicit [0-9A-Fa-f]); os.path.join('.', x) keeps a ./ that Node's path.join strips; an emoji inside a comment blanks to a different number of spaces if you iterate UTF-16 units vs code points (so the comment stripper iterates code points); and columns are counted in UTF-8 bytes to dodge the UTF-16-vs-code-point off-by-one. A differential test runs both builds over the same trees and gets zero diffs.

What it deliberately doesn't do

No named colors (red, tan) by default — too noisy, they collide with identifiers and class names. The validated pain is raw hex.
No autofix — it has no #3f82f0 → --primary map, and a report that rewrites your files is a report you can't trust in CI.
No config file, no oklch()/lab() — the goal is a high-signal, zero-config gate, not a parser.

Install

npx hexsweep src/      # Node, zero deps
pip install hexsweep   # Python, zero deps, identical output

MIT licensed, both builds open source:

npm: https://www.npmjs.com/package/hexsweep
PyPI: https://pypi.org/project/hexsweep/
GitHub: https://github.com/jjdoor/hexsweep (Node) · https://github.com/jjdoor/hexsweep-py (Python)

Run npx hexsweep on a project you migrated to tokens a while ago. I'd bet there's at least one #hex still hiding in there — what did you find?

The most-installed XML viewers are 2★ and abandoned. So I hand-wrote one.

benjamin — Sat, 20 Jun 2026 14:18:41 +0000

Open a .xml file in your browser and you usually get one of three things: a wall of unindented text, a viewer that freezes the tab on anything big, or — when the XML is actually broken — a blank page that won't tell you why.

So I went looking for a good XML viewer extension. The most-installed ones on the stores are stuck around 2 stars and haven't been updated since 2023. The reviews rhyme: "doesn't work", "freezes", "just shows plain text". I built Xwift to do the three things those don't.

What it does

Tree view — collapsible, syntax-highlighted elements, attributes, text, CDATA, comments and processing instructions. Expand/collapse all.
Source view — pretty-print (2 / 4 / tab) or minify, with line numbers and one-click copy.
Tells you where it's broken — a tolerant parser that keeps going on malformed input and lists every well-formedness problem with its line:column: mismatched and unclosed tags, duplicate attributes, unbound namespace prefixes, an unescaped &, a stray ]]>… click an error to jump to it.
Doesn't choke on big files — parsing runs in a Web Worker, so the tab stays responsive where "load it all into the DOM" viewers stall.

The interesting part (for fellow devs)

The whole thing is hand-written with zero dependencies — no DOMParser, no library. That was the point. The parser is a tolerant single-pass scanner that builds a best-effort tree and collects precise errors, and the formatter re-emits significant whitespace verbatim, so mixed content and xml:space="preserve" survive a round-trip.

Before shipping I ran an adversarial audit over the core, and it surfaced 15 real bugs I would never have caught by eye. A few favorites:

Namespace scopes were plain objects, so an unbound prefix literally named toString or __proto__ resolved up the prototype chain and got treated as bound. Fixed with Map-based scopes.
The serializer was recursive, so a deeply-nested-but-valid document overflowed the call stack even though the iterative parser handled it fine. Rewrote it as an explicit-stack walk.
A [hidden] attribute was silently overridden by a display:flex CSS rule — the empty drop-zone covered the whole viewer. My first E2E missed it because it asserted element content, not visibility.

Then it's verified in real Chrome and real Firefox — the parser produces byte-identical output under V8 and SpiderMonkey.

Respectful by default

Zero data collection. Everything runs locally — no network requests with your content, no account, no telemetry. Files you open never leave your browser.
Minimal permissions. No host permissions, no <all_urls>, no tab snooping. It reads a page only the moment you ask it to.

Get it

Source (MIT, audit the parser): https://github.com/jjdoor/xwift
Chrome / Edge / Firefox: rolling out as each store finishes review.

What's the worst XML-viewing moment you've had — the freeze, the blank page, or the "valid" XML that very much wasn't?

Is that timestamp in seconds or milliseconds? I built a zero-dep CLI that just tells you — both directions.

benjamin — Fri, 19 Jun 2026 05:29:05 +0000

You find a timestamp in a log line: 1718750000123. Is that seconds? Milliseconds? You reach for date... and on macOS it's date -r, on Linux it's date -d @, and neither of them will tell you that you grabbed milliseconds and your "date" is now in the year 56435. So you give up and paste the number into the third epoch-converter website that Google hands you.

I do this several times a week. So I built epochlens — one zero-dependency command that auto-detects the unit, works the same on every platform, and goes both directions:

$ npx epochlens 1718750000

  input     1718750000  (unix seconds)

  unix s    1718750000
  unix ms   1718750000000
  unix µs   1718750000000000
  unix ns   1718750000000000000
  iso utc   2024-06-18T22:33:20Z
  iso local 2024-06-19T06:33:20+08:00
  relative  2 minutes ago
  rfc 2822  Tue, 18 Jun 2024 22:33:20 +0000

It guesses seconds vs millis vs micros vs nanos by magnitude and echoes the guess so you can catch it (--unit ms to override). It goes the other way too:

epochlens 2024-06-18T22:33:20Z   # any ISO 8601 / RFC 2822 date → every epoch precision
epochlens now                    # the current moment, all forms
echo 1718750000 | epochlens      # reads stdin

pip install epochlens gets you the exact same tool in Python — the two builds print byte-for-byte identical output.

The fun part: making two languages agree to the byte

I wanted a Node build and a Python build that produce identical output, because half of us live in npx and half in pip. That turned out to be the hard part — date handling is a minefield of disagreements, and not just across languages but within them:

toISOString() vs isoformat(): Node gives ...20.000Z (always 3 fractional digits, literal Z); Python gives ...20+00:00 (no fraction when zero, 6 digits otherwise, +00:00 not Z). Three mismatches in one field.
Parsing: Date.parse("2024-06-18 12:00") is lenient and reads it as local time; Python's fromisoformat reads it as naive; "June 18 2024" parses in Node and throws in Python.
Rounding: Math.round(2.5) is 3; Python's round(2.5) is 2 (banker's rounding).
Negative floor division (pre-1970 timestamps): JS truncates toward zero, Python floors toward −∞, so -3 % 1000 disagrees.
Nanoseconds: a 19-digit ns value blows past Number.MAX_SAFE_INTEGER, so Node needs BigInt where Python's ints just work.
Sub-minute timezones: for pre-1900 dates, getTimezoneOffset() (minutes) and tm_gmtoff (seconds) literally disagree about the local offset.

The fix was to delegate nothing to the runtime's date library. Every conversion is plain integer math over a proleptic-Gregorian civil-day algorithm, and every output field is hand-formatted. No Date.parse, no toISOString, no fromisoformat, no strftime. The reward: a property test that diffs the two builds over thousands of inputs — from year 1 to year 9999, every precision, every offset — and gets zero differences.

What it deliberately doesn't do

No named --tz America/New_York yet. Python's zoneinfo reads an OS tz database that Windows doesn't ship, and pulling in tzdata would break the zero-dependency promise. You get UTC, your local time, and a fixed --offset ±HH:MM (pure arithmetic, portable everywhere).
No natural-language input ("3 days ago"). Relative time is output only.
Years are clamped to 0001–9999 (anything else is rejected rather than silently producing +275760 on one platform and crashing on the other).

Install

npx epochlens 1718750000     # Node, zero deps
pip install epochlens        # Python, zero deps, identical output

MIT licensed, both builds open source:

npm: https://www.npmjs.com/package/epochlens
PyPI: https://pypi.org/project/epochlens/
GitHub: https://github.com/jjdoor/epochlens (Node) · https://github.com/jjdoor/epochlens-py (Python)

What's your most-hated timestamp footgun — the seconds/millis mixup, timezone math, or something worse? And does anyone actually remember date -d @ vs date -r without looking it up?

DEV Community: benjamin

GitHub Actions won't tell you your CI is getting worse. I built a zero-dep CLI that does.

What it actually shows you

How it works

Install

The same root cause keeps coming back because nobody tracks it. I built a zero-dep CLI that does.

How it works

Why not just grep the old postmortems?

Design notes for the technical reader

Install

branchreap: safely reap merged & gone-upstream git branches (zero-dep, npx or pip)

What it reaps — and what it refuses to

What it looks like

Why another branch cleaner?

Try it

diskreap: reclaim disk from build artifacts & dep caches, across every language

Why not just npkill / kondo?

Using it

The one design decision that mattered: safety

Try it

My code reviewer kept asking for JSDoc — so I built a zero-dep CLI that catches it first

What it catches

How to use it

What it skips (intentionally)

Zero dependencies

Links

I kept finding gaps in my repos after open-sourcing — so I built a zero-dep CLI to catch them first

What it checks

Install (zero dependencies)

Flags

Add to CI

Design note: warnings vs errors

Links

I kept shipping version mismatches — so I built a zero-dep CLI that checks all three sources at once

Why existing tools don't fully cover this

What it does

Install (zero dependencies, dual Node + Python)

Flags

Drop it in CI or a pre-push hook

Two design decisions worth noting

Links

A reformatted PR shows 80 changed lines but changed nothing — I built a zero-dep diff that sees through it

How it folds reflow

The fun part: two languages, one diff, to the byte

Install

Your repo has whitespace problems you can't see — I built a zero-dep CLI that finds and fixes them all

Why not editorconfig-checker / pre-commit / prettier?

The opinions that make it zero-config

The fun part: --fix that two languages agree on, to the byte

Install

Your design-token migration isn't done — here's a zero-dep CLI that finds the colors that escaped

"Just grep for it" — no

"Use stylelint" — closer, but it yells at the wrong file

The fun part: a linter with no parser, that two languages agree on byte-for-byte

What it deliberately doesn't do

Install

The most-installed XML viewers are 2★ and abandoned. So I hand-wrote one.

What it does

The interesting part (for fellow devs)

Respectful by default

Get it

Is that timestamp in seconds or milliseconds? I built a zero-dep CLI that just tells you — both directions.

The fun part: making two languages agree to the byte

What it deliberately doesn't do

Install

Why not just `npkill` / `kondo`?