DEV Community: benjamin

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?

Putting a file in .gitignore does nothing if git already tracks it. I built a CLI to find the leftovers.

benjamin — Fri, 19 Jun 2026 03:46:33 +0000

You added .env to .gitignore. You felt responsible. But three weeks later it's still in the repo, still pushed to GitHub, still in every clone — because adding a path to .gitignore does nothing to a file git already tracks.

That's not a bug. It's documented behavior: .gitignore only stops untracked files from being added. Anything already committed keeps getting tracked, ignore rule or not. So the secrets, build artifacts, and 40 MB log files that were committed before someone wrote the rule just... stay.

The fix is one command — git rm --cached — but only once someone notices. And nobody notices, because git status is clean and the file looks ignored.

So I built gitslip: a zero-dependency CLI that finds every tracked file your own ignore rules say should be gone, and hands you the exact fix.

$ npx gitslip

2 tracked files are ignored by your rules but still committed:

  config/secrets.env
      ↳ .gitignore:7  *.env
  logs/app.log
      ↳ .gitignore:2  *.log

Fix — stop tracking them (keeps your local copy):
  git rm --cached -- config/secrets.env
  git rm --cached -- logs/app.log

  or let gitslip do it:  gitslip --apply

It tells you which rule caught each file (.gitignore:7 *.env), so there's no guessing. And --apply runs the git rm --cached for you — it only un-tracks, it never deletes your working copy.

Why not just grep?

You can grep your .gitignore patterns against git ls-files. But:

A raw grep '\.env' can't tell a still-tracked leftover from a file that's correctly excluded, and it has no idea about !negation rules, build/ directory rules, nested .gitignore files, .git/info/exclude, or your global core.excludesFile.
Reimplementing gitignore's matching semantics to get this right is exactly the kind of subtly-wrong code you don't want guarding your secrets.

gitslip doesn't reimplement anything. It asks git.

How it works (the fun part)

Detection is a single git incantation:

git ls-files -i -c --exclude-standard

-c = tracked (cached), -i = ignored, --exclude-standard = use all the standard ignore sources. That's the authoritative "tracked and ignored" set, and git handles every negation/directory/nested rule correctly. No matching logic of our own = no disagreements with git.

The interesting part is naming the rule that caught each file. The obvious tool is git check-ignore -v... except it short-circuits: for a file git is already tracking, check-ignore reports "not ignored" and refuses to name a pattern. (And --no-index didn't reliably fix it on the git I tested.)

The trick: run check-ignore against an empty index.

GIT_INDEX_FILE=/tmp/empty git check-ignore -v -z --stdin

Point GIT_INDEX_FILE at a path that doesn't exist — git treats it as an empty index, so nothing is tracked, so check-ignore stops short-circuiting and happily names the matching .gitignore:line:pattern for every path. It's read-only, so the file is never even created.

Install

npx gitslip          # Node, zero deps
pip install gitslip  # Python, zero deps — byte-for-byte identical output

Both builds are pure standard library. There's a Node version and a Python version because half of you live in one ecosystem and half in the other, and they produce identical output down to the byte (I diff them in CI).

It's also a clean CI gate — exits 1 if anything slipped, so you can fail a build that's about to commit an ignored file:

- run: npx gitslip

Try it on your repo

Seriously, run npx gitslip in your current project right now. If you've ever git add -A'd before writing a .gitignore, there's a decent chance something's in there.

What's the worst thing you've found still tracked in a repo — a secret, a 100 MB binary, someone's .DS_Store from 2019? Tell me below.

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

MIT licensed. Issues and PRs welcome.

Most JSON-to-Schema tools over-fit one example. mkschema merges many samples.

benjamin — Fri, 19 Jun 2026 02:51:41 +0000

You need a JSON Schema for an API response, a config file, a stream of log records — for validation, docs, or contract tests. Hand-writing it is tedious and you'll get it subtly wrong. So you reach for a "JSON to JSON Schema" generator… and it hands you a schema built from one example: every field marked required, every type pinned to whatever that single record happened to contain. The first real payload that omits an optional field fails validation against a schema you just generated.

The problem isn't generating a schema. It's that one example isn't your data. So I built mkschema to merge many samples. Zero dependencies, no network.

$ printf '{"id":1,"name":"Ada","age":30}\n{"id":2,"age":30.5}\n' | npx mkschema --ndjson -

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "age":  { "type": "number" },     // 30 (int) and 30.5 (float) unioned
    "id":   { "type": "integer" },
    "name": { "type": "string" }
  },
  "required": ["age", "id"]           // name was missing from sample 2 → optional
}

Feed it one sample and everything is required (same as the others). Feed it your actual data — a --ndjson log file, a folder of fixtures, a paged API dump — and it figures out what's really there:

A key in every sample is required; a key in only some is optional.
An integer here and a float there union to number; genuinely different types become a type array.
String formats are inferred (date-time, date, email, uuid, ipv4, uri) — but only kept when every sample of that field agrees.

Usage

mkschema response.json                 # one file
mkschema a.json b.json c.json          # merge several files
mkschema --ndjson events.ndjson        # one sample per line
curl -s https://api/users | mkschema -  # straight from an API
mkschema users.json --title User > user.schema.json

It writes the schema to stdout (draft 2020-12), with properties and required
sorted, so it diffs cleanly in version control.

A few honest notes

Zero dependencies, both builds — a Node build and a Python build that produce identical output. npx mkschema or pip install mkschema.
Numbers are classified by value, so 5.0 is an integer — and the two builds agree (a subtlety that took an adversarial pass to get right, along with rejecting NaN/Infinity identically and not mistaking a user@host URL for an email).
It infers structure, not constraints. You get the scaffold from real data; add your own enum, minLength, pattern on top.

dotenv loads your .env — it doesn't check it. So I built a typed validator.

benjamin — Fri, 19 Jun 2026 01:58:29 +0000

A PORT=8O80 typo (that's a letter O), a DATABASE_URL you forgot to set, a NODE_ENV=prodd — none of these fail when your app starts. They fail later: a cryptic stack trace three layers into startup, a service that boots but talks to the wrong database, a feature flag that's silently off in production. The error is never "your env is wrong"; it's whatever broke downstream.

dotenv loads your .env. It doesn't check it. So I built envward: validate the whole environment against a small typed schema up front, and fail loudly — with the actual problem — before a single line of app code runs. Zero dependencies, no network.

$ envward

.env — checked against env.schema.json

  ✗ API_KEY   missing — required string
  ✗ NODE_ENV  "prodd" is not one of: development, production, test
  ✗ PORT      70000 is above max 65535

3 problem(s), 3 key(s) valid

It exits non-zero on any problem, so it drops straight into a prestart hook or a CI step.

Get a schema in one command

No hand-writing JSON from scratch:

envward --init > env.schema.json

--init reads your existing .env and guesses a type for each key (8080 → int, https://… → url, true → bool, …), marking them required. Then you tighten it:

{
  "PORT":         { "type": "int", "required": true, "min": 1, "max": 65535 },
  "DATABASE_URL": { "type": "url", "required": true },
  "NODE_ENV":     { "type": "enum", "values": ["development", "production", "test"] },
  "API_KEY":      { "type": "string", "required": true, "minLength": 16 }
}

Types: string (with minLength/maxLength/pattern), int / number (with min/max), bool, url, email, enum. An empty value (KEY=) counts as missing.

How it's different from a drift checker

A .env drift tool tells you which keys are missing versus .env.example. envward validates the values: is PORT actually an integer in range, is DATABASE_URL actually a URL, is NODE_ENV one of the allowed set. Different failure mode, caught at a different time.

Install

npx envward          # Node
pip install envward  # Python — same behavior

Two builds (Node + Python) that validate identically, so it fits whatever your stack already runs.

Use it as a gate

# package.json: "prestart": "envward"   — refuse to boot with a broken .env
# CI:           envward --env .env.ci --strict

--strict also flags keys present in .env but missing from the schema.

A couple of honest notes

Zero dependencies, both builds — stdlib only.
A malformed schema is an error, not a guess. A non-numeric min, a bad regex pattern, an unknown type — envward exits 2 with a clear message in both builds, rather than crashing or silently passing. (Getting Node and Python to agree on every edge here took a real adversarial pass.)
pattern is matched in ASCII mode and as an unanchored search — wrap it in ^…$; keep to a portable regex subset for identical behavior across both builds.

DEV Community: benjamin

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

Putting a file in .gitignore does nothing if git already tracks it. I built a CLI to find the leftovers.

Why not just grep?

How it works (the fun part)

Install

Try it on your repo

Most JSON-to-Schema tools over-fit one example. mkschema merges many samples.

Usage

A few honest notes

Links

dotenv loads your .env — it doesn't check it. So I built a typed validator.

Get a schema in one command

How it's different from a drift checker

Install

Use it as a gate

A couple of honest notes

Links

Why not just `npkill` / `kondo`?