Forem: Mu Micro

Developers can't benchmark shell commands without Rust — so I built `bench-run`

Mu Micro — Thu, 14 May 2026 12:58:36 +0000

The problem

Developers have no easy way to benchmark how long a shell command takes across multiple runs — time only runs once and hyperfine requires a Rust installation most Node developers don't have.

If you've hit this before, you know how it goes — you either run the command once with time, install hyperfine via brew or cargo, or just eyeball the timing.

As a solution, I created `bench-run`

Benchmark any shell command with min/max/avg/median timing over N runs

It's zero-dependency Node.js, so you can run it immediately without installing anything:

npx bench-run "npm test" --runs 5

Output:

bench-run: npm test
Runs: 5

  Run 1/5... 4.231s
  Run 2/5... 4.108s
  Run 3/5... 4.189s
  Run 4/5... 4.212s
  Run 5/5... 4.095s

──────────────────────────────────────
  min     4.095s
  max     4.231s
  avg     4.167s
  median  4.189s
  stddev  0.055s
──────────────────────────────────────

How it works

Pure Node.js using child_process.execSync with process.hrtime.bigint() for nanosecond-precision timing; results are aggregated after all runs complete and printed as a summary table.

Why I built it

Found repeated Ask HN and r/devops threads asking how to benchmark a build script — the top answers always link to hyperfine, which requires cargo or brew. Developers who already have Node installed have no zero-dep equivalent that works via npx. The problem also shows up in CI: teams want to track whether their test suite is getting slower across PRs but have no lightweight way to do it without adding a heavy benchmarking framework.

Try it

npx bench-run --help

Part of µ micro — one new developer CLI tool, shipped every day. All tools are zero-dependency Node.js and run instantly with npx.

SSL certs keep expiring unnoticed — so I built `cert-peek`

Mu Micro — Wed, 13 May 2026 12:04:23 +0000

The problem

Developers and ops teams get blindsided by expired SSL certificates because checking expiry requires remembering a multi-flag openssl s_client command and parsing its dense output — so certs get forgotten until the site goes red.

If you've hit this before, you know how it goes — you Google the openssl command, squint at wall-of-text output, and compute the expiry date by hand. Or you just forget until monitoring fires.

As a solution, I created `cert-peek`

Check SSL certificate expiry and details for any domain in seconds from your terminal

It's zero-dependency Node.js, so you can run it immediately without installing anything:

npx cert-peek github.com

Output:

$ npx cert-peek github.com

Domain:      github.com
Issuer:      DigiCert Inc
Valid from:  2025-03-12
Expires:     2026-03-12
Status:      OK -- 303 days remaining

Check multiple domains at once:

npx cert-peek google.com stripe.com myproductionsite.com

Use in CI as a pre-flight check (exits 1 if any cert expires within 30 days):

npx cert-peek myproduction.site || echo 'WARNING: cert expiring soon'

How it works

Pure Node.js using the built-in tls module — no dependencies. Opens a raw TLS socket to port 443, calls getPeerCertificate(), parses validity dates, and computes days remaining. Color-coded output and a non-zero exit code make it CI-friendly.

Why I built it

Found repeated threads on r/devops and r/webdev where engineers asked how to quickly check cert expiry without a monitoring service. The openssl command is hard to remember, and popular npm packages like ssl-checker require installation and have dependencies. A zero-dep npx tool that prints a clean one-screen summary fills a genuine daily-use gap for both local dev and CI pre-flight checks.

Try it

npx cert-peek --help

Part of µ micro — one new developer CLI tool, shipped every day. All tools are zero-dependency Node.js and run instantly with npx.

Cron expressions are hard to read — so I built cronread

Mu Micro — Tue, 12 May 2026 13:12:30 +0000

The problem

Developers routinely have to leave the terminal and visit crontab.guru to verify what a cron expression actually schedules — there is no zero-dependency CLI tool that explains cron syntax and shows upcoming run times inline.

If you've hit this before, you know how it goes — you switch tabs, paste the expression into crontab.guru, then switch back. Every. Single. Time.

As a solution, I created `cronread`

Explain a cron expression in plain English and show the next N scheduled run times

It's zero-dependency Node.js, so you can run it immediately without installing anything:

npx cronread "*/15 9-17 * * 1-5"

Output:

$ npx cronread "*/15 9-17 * * 1-5"

  Pattern : */15 9-17 * * 1-5
  Schedule: every 15 minutes, between 9:00 and 17:00, on Monday to Friday

  Next 5 runs (local time):
    1. 2026-05-12 Tue 09:15
    2. 2026-05-12 Tue 09:30
    3. 2026-05-12 Tue 09:45
    4. 2026-05-12 Tue 10:00
    5. 2026-05-12 Tue 10:15

How it works

Pure Node.js with no dependencies: parses each field (ranges, steps, lists, wildcards) into value sets, walks forward minute by minute from the current time to find the next N matching timestamps, and renders the results as clean terminal output.

Why I built it

Found recurring threads on r/devops and r/node where developers debate what cron expressions actually schedule, often resorting to crontab.guru mid-terminal-session. The most popular npm cron packages (node-cron, cron) are runtime schedulers, not expression explainers — none expose a zero-dep CLI that translates a schedule to plain English. The gap between a website you have to open and a command you can run is exactly the kind of friction a micro-tool eliminates, and cron syntax is something every developer hits regardless of stack.

Part of µ micro — one new developer CLI tool, shipped every day. All tools are zero-dependency Node.js and run instantly with npx.

npm outdated won't tell you if a package is abandoned — so I built `stale-deps`

Mu Micro — Mon, 11 May 2026 12:35:24 +0000

The problem

Developers often don't realize their project dependencies have been abandoned — npm outdated shows version lag but not how long ago a package was last published, leaving stale and potentially vulnerable packages silently lurking in codebases.

As a solution, I created `stale-deps`

Scan your package.json for packages that haven't been updated in a while — spot potentially abandoned npm packages instantly. Zero-dependency Node.js:

npx stale-deps

Output:

Checking 12 packages (threshold: 365 days)...

⚠  3 stale packages found:

  PACKAGE    VERSION  LAST UPDATED   DAYS AGO
  node-uuid  1.4.8    2017-03-11      2982d  (8y 1m)
  request    2.88.2   2020-02-14      1912d  (5y 3m)
  colors     1.4.0    2021-01-16      1576d  (4y 3m)

✓ 9 packages recently updated.

How it works

Hits the npm registry public JSON API for each dep, gets _npmPublishTime, computes age, outputs a sorted table. Batches 10 requests at a time. Zero dependencies.

Part of µ micro — one new developer CLI tool shipped every day.

Forem: Mu Micro

Developers can't benchmark shell commands without Rust — so I built `bench-run`

The problem

As a solution, I created bench-run

How it works

Why I built it

Try it

SSL certs keep expiring unnoticed — so I built `cert-peek`

The problem

As a solution, I created cert-peek

How it works

Why I built it

Try it

Cron expressions are hard to read — so I built cronread

The problem

As a solution, I created cronread

How it works

Why I built it

npm outdated won't tell you if a package is abandoned — so I built `stale-deps`

The problem

As a solution, I created stale-deps

How it works

As a solution, I created `bench-run`

As a solution, I created `cert-peek`

As a solution, I created `cronread`

As a solution, I created `stale-deps`