DEV Community: ke jia

I Ran 4 Secret Scanners on the Same File. The Smallest One Found the Least — and I Still Use It Daily

ke jia — Mon, 31 Aug 2026 00:46:22 +0000

Last month I was about to push a branch when a coworker asked a two-word question: "Secrets in there?"

I had added environment files for a local dev database, and I knew the answer was probably "yes" — but I didn't know which keys, on which lines, or whether anything had already made it into git history. I wanted an answer in seconds, not after a ten-minute install.

So I built a small test: one file, secrets.env, with seven planted secrets — all fake, using AWS's own documentation example values and test-format placeholders. Then I ran four tools on the exact same file:

dotguard — a zero-dependency Node CLI I maintain
gitleaks — the de-facto open-source standard
TruffleHog — the "verified secrets" scanner
GitHub's built-in secret scanning — the platform-level safety net

Here's what happened. Including one dotguard gotcha I didn't expect and now want you to know about before you rely on it.

The test file

# secrets.env — every value below is fake or a published example
NODE_ENV=development

# Cloud
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# LLM
OPENAI_API_KEY=sk-proj-abc123def456ghi789jkl012

# Payments
STRIPE_SECRET_KEY=sk_test_4eC39HqLyjWDarjtT1zdp7dc

# Database
DB_PASSWORD=Sup3rS3cret!2026
DATABASE_URL=postgres://admin:hunter2@db.internal:5432/app

# Misc
SESSION_TOKEN=abcdef1234567890abcdef1234567890

Seven distinct secret types: an AWS key pair, an OpenAI API key, a Stripe secret key, a hardcoded password, a credential-bearing database URL, and a long session token. A good scanner should find most of them. Let's see how each one did.

Contender 1: dotguard (zero dependencies, ~1 second)

dotguard is a single-file Node script. No Go binary, no Docker image, no config file to learn. If you have Node, you can run it:

npx @wuchunjie/dotguard .

I ran it on the test directory. Here is the real, unedited output from my machine:

🔍  Scanning: C:\tmp\dgtest

  📄  secrets.env (5 issues)
    ⚠️  L 15 | Hardcoded password
       DB_PASSWORD=Sup3rS3cret!2026
    ⚠️  L  9 | API key
       OPENAI_API_KEY=sk-proj-***
    ⚠️  L 19 | Access token
       SESSION_TOKEN=abcdef...7890
    ⚠️  L 16 | Database URL
       DATABASE_URL=postgres://admin:***@db.internal:5432/app
    ℹ️  L  0 | Missing PORT
       Consider adding: PORT=3000

  ─────────────────────────────
  ⚠️   4 potential secrets exposed!
  💡  Add .env to .gitignore & use .env.example instead.

Score: 4 of 7. It caught the password, the OpenAI key, the session token, and the database URL. It exited with code 1, which is exactly what you want in CI — a failing pipeline beats a committed secret.

What did it miss? The AWS key pair and the Stripe key. The reason is instructive: dotguard's seven patterns are name-based. It looks for things like api_key=, token=, password=, private key headers, and database URL schemes. The AWS and Stripe values in my test file live under variable names (AWS_ACCESS_KEY_ID, STRIPE_SECRET_KEY) that none of the patterns match, so the values — even though they're textbook key formats — sail through.

That's a real limitation, and I'd rather state it plainly than pretend otherwise. dotguard's rule set is tuned for "classic env-file mistakes," not for the full zoo of provider key formats.

It also printed something none of the other three tools do: a hint that PORT is missing from the file. That's opinionated. On a new project it's genuinely helpful; on a mature one it's noise you can ignore.

The gotcha I want you to know about

While writing this I noticed something in the source that my first test run confirmed: dotguard v1.0.2 skips dotfiles entirely. My test directory also contained a file named .env with a planted secret, and it was not scanned at all. The scanner walks directories and skips any entry starting with ., which means:

secrets.env, prod.env, env.staging, env.local → scanned ✅
.env, .env.local, .env.production → skipped ⚠️

If your project's environment file is literally named .env (which is the convention, and what I use myself), dotguard will report "No .env files found. Clean!" and exit 0 — a false all-clear. The fix for now is to make sure the files you want checked use the *.env or env.* naming, or to treat dotguard as a scanner for your committed environment templates rather than your local .env. I've filed this as a fix for the next release, but until then: don't let a green dotguard run make you feel safe about a file named .env.

Contender 2: gitleaks (the deep scan)

gitleaks is the tool I'd point most teams to, and it shows why. It's a Go binary (or a Homebrew/Chocolatey install), and it brings something dotguard structurally can't: it scans git history by default.

That matters more than people expect. The most dangerous secret in a repo is usually not the one you're about to commit — it's the one someone committed fourteen months ago, rotated in their head, and forgot about. gitleaks walks every commit looking for them.

Its default rule set is two orders of magnitude larger than dotguard's, with dedicated rules for AWS access tokens, Stripe keys, OpenAI keys, generic passwords, and credential-bearing connection strings. On the same test file, gitleaks flags all seven lines — the AWS pair, the OpenAI key, and the Stripe key that dotguard missed — and does it in a couple of seconds.

You can point it at a report format for CI dashboards:

gitleaks detect --no-git -r gitleaks-report.json

The trade-offs: you install a second runtime (Go binary), you'll eventually want to maintain a .gitleaks.toml with allowlists to tame false positives, and its default config will flag your own test fixtures, which is annoying in a repo that contains examples. None of that is fatal — teams run gitleaks in CI daily — but it is a heavier commitment than npx-ing a script.

Score on the test file: 7 of 7, plus the unique ability to find secrets in history.

Contender 3: TruffleHog (the verifier)

TruffleHog takes a different philosophical position: a pattern match is not proof. A 40-character string that looks like an AWS secret access key might be a placeholder from a tutorial. TruffleHog tries to verify candidates by actually calling the provider's APIs and checking whether the credential works.

That's the killer feature in a specific scenario: you find 30 candidate secrets in a leaked repo and need to know which five are live. TruffleHog is the only one of the four that will tell you "this one is real."

It's also the heaviest option here. It's a Go tool (or Docker image), verification means network calls with all the rate-limit and etiquette implications that carries, and a full scan with verification takes a long time. On my test file it would have detected all seven candidates, then tried to verify them — and, because every value is fake, the verification step would have failed, correctly telling me "detected but not valid." That's actually a lovely teaching moment: verification is how you separate noise from a real incident.

For a pre-commit check, though, TruffleHog is a sledgehammer. I use it for incident response, not for daily development.

Score: 7 of 7 detected (verification correctly rejects all fakes).

Contender 4: GitHub secret scanning (the safety net)

If your code lives on GitHub, you already have a secret scanner. Built-in patterns for AWS, OpenAI, Stripe, and dozens of other providers run automatically on pushes to public repositories at no cost; for private repositories it's included with GitHub Pro and above, and push protection can block the push that contains the secret.

Its strengths are obvious: zero CLI, zero config, and it runs whether or not your developer remembers to run anything. Its weaknesses are equally obvious: it only sees what reaches GitHub (your local working tree is invisible to it), it's platform-locked, and its built-in patterns won't catch a generic DB_PASSWORD=... line unless you add a custom pattern.

GitLab and Bitbucket ship comparable features, so the "platform safety net" idea applies beyond GitHub — it just has a different name.

Score: 7 of 7 for the provider keys (the generic password line needs a custom pattern).

The scoreboard

	dotguard	gitleaks	TruffleHog	GitHub scanner
Install	`npx`, zero deps	Go binary / package mgr	Go / Docker	None
Scans git history	❌	✅	✅	✅ (pushed only)
Rule coverage (test file)	4/7	7/7	7/7	7/7*
Typical time on test file	~1 s	~2–5 s	minutes (verify)	async
Works fully offline	✅	✅	partial	❌
Extra signal	missing-key hints	SARIF/JSON reports	live-secret verification	push blocking

* with built-in patterns; generic lines need custom patterns.

So what do I actually use?

The honest answer is: all of them, at different layers. This is the setup I run:

Layer 1 — pre-push, seconds. dotguard as a git hook or a quick manual check. Its job is the question "is this file I'm touching right now clean?" It's fast enough that I actually run it, which is more than I can say for tools I have to think about. It's the bouncer at the door, not the security team.

#!/bin/sh
# .git/hooks/pre-push
npx @wuchunjie/dotguard .

Layer 2 — CI, every push. gitleaks with history scanning, failing the pipeline on a new finding. This is the layer that catches the fourteen-months-ago secret.

- name: Deep secret scan
  uses: gitleaks/gitleaks-action@v2

Layer 3 — platform. GitHub's secret scanning as the backstop for anything that slips past both, plus push protection on private repos.

Layer 4 — incident response. TruffleHog, only when something has actually leaked and I need to know which of the exposed candidates are live.

dotguard sits at layer 1 and does exactly one job well: instant, zero-setup triage of environment files on any machine that can run Node. It will never replace gitleaks — its rule set is small and it doesn't see history — and the .env-skipping quirk means you should know exactly what it's checking. But for the question my coworker asked me — "secrets in there?" — it's the fastest "here's the line number" I have, and the line numbers are what let you fix things before the push instead of after the incident.

dotguard is free and open source: npm package, npx @wuchunjie/dotguard. If the .env naming behavior bit you too, or you want a provider-key-format rule (AWS/Stripe detection by value instead of variable name), the issue tracker is open — those are exactly the two gaps this comparison exposed.

My Git CLI Was Silently Broken on Windows for 3 Months — A 2>/dev/null Bug That Taught Me the Hard Way

ke jia — Sat, 29 Aug 2026 16:17:55 +0000

In May I shipped gitpulse — a tiny CLI that shows your git repo's analytics right in the terminal: commit stats, contributor graphs, file breakdowns, recent activity.

One command. Zero config. No dashboard. No login.

npx @wuchunjie/gitpulse

Three months later, I ran it on my own Windows machine and got:

  ❌  Not a git repository.

...inside a perfectly valid git repository. And the worst part: it had been failing on every Windows machine since day one. It just never told me.

The Bug

Here's the line that checked whether we're inside a git repo:

function run(cmd) {
  try {
    return execSync(cmd, { encoding: "utf-8", stdio: ["pipe", "pipe", "pipe"] }).trim();
  } catch {
    return "";
  }
}

const isRepo = run(`cd "${dir}" && git rev-parse --git-dir 2>/dev/null`);
if (!isRepo) {
  console.log("  ❌  Not a git repository.");
  process.exit(1);
}

This is completely normal, boring code. git rev-parse --git-dir prints .git in a repo, nothing on stdout otherwise, and 2>/dev/null keeps the error message quiet. Works on Linux. Works on macOS. Works in my CI.

Then why did it die on Windows?

`2>/dev/null` Does Not Exist on Windows

On Linux and macOS, 2>/dev/null redirects stderr to the kernel's null device.

On Windows, Node's execSync doesn't run your command in bash — it runs it in cmd.exe. And cmd.exe interprets 2>/dev/null literally: "open the file at path /dev/null for writing."

That path doesn't exist. cmd.exe gives up with:

The system cannot find the path specified.

The command exits non-zero, my catch block swallows it, isRepo becomes an empty string, and gitpulse cheerfully announces "Not a git repository" in a repo that's very much a repo.

Silent failure. Wrong error message. Zero stack trace. For three months.

The Debug Journey

Because I develop in git-bash, the first clue was confusing: git rev-parse --git-dir worked fine in my shell, so of course I ran the same command through Node to compare:

node -e "console.log(require('child_process').execSync('git rev-parse --git-dir', {encoding:'utf-8'}).trim())"
# → .git  ✅

Works in Node. Fails in gitpulse. So I bisected the exact command string, adding pieces back one by one:

execSync('cd "." && git rev-parse --git-dir')          // ✅ works
execSync('cd "." && git rev-parse --git-dir 2>/dev/null')  // ❌ boom

There it was. The redirect — the most innocent-looking six characters in the file — was the entire bug.

The Fix

One line: delete the redirect.

const isRepo = run(`cd "${dir}" && git rev-parse --git-dir`);

Why is that safe? Because I'm already passing stdio: ["pipe", "pipe", "pipe"] — stderr is piped into Node's memory and never touches the terminal. There is nothing for 2>/dev/null to silence. The redirect wasn't protecting the user from noise; it was just a habit I'd copied from a shell script.

That's the whole fix. No platform detection. No 2>nul on Windows. Just: don't put POSIX shell syntax inside a string you hand to child_process on Windows.

Rules I'm Writing Down Now

execSync on Windows is cmd.exe, not bash. No 2>/dev/null, no && chains with POSIX paths, no $VAR expansion.
Prefer Node options over shell tricks. stdio: "ignore" or piped streams beat every shell redirect.
git commands print errors to stderr and exit codes — you usually don't need to suppress anything if you handle the exit code properly.
Test on the OS your users are on. I write "cross-platform" in my README and then test on the one machine in my head. gitpulse users on Windows were getting a fake error for 90 days and I never noticed.

What gitpulse Actually Shows

The apology tour is over — here's the tool. Run it in any repo:

  📊  GITPULSE

  📝  Total commits: 2
  👤  Contributors:  1
  📅  Active days:   1
  📂  Files touched:  2

  👥  Top Contributors
    T                         ███████████████ 2

  📂  File Type Breakdown
    .txt        ███████████████ 2

  🔥  Recent Activity
    2026-08-30  ██████████████████████████████ 2

Point it at a big team repo and you get your bus-factor graph, the file-type mix (how much of your history is .ts vs .md vs mystery binary files), and a per-day activity strip — all rendered with plain Unicode blocks, no dependencies, no server, nothing leaving your machine.

It's the "wait, who actually maintains this repo?" answer, without opening a browser.

npx @wuchunjie/gitpulse            # current repo
npx @wuchunjie/gitpulse /path/to/repo

If You're Shipping CLIs

Your users are on Windows. Not "some of your users." The ones who will install it, run it, get a confusing error, and quietly never come back.

Audit your execSync strings. If any of them contain 2>/dev/null, >/dev/null, or a bash-ism of any flavor, they are lying to your Windows users right now.

And if you ever build a tool that looks at your git history the way you'd wish GitHub Insights did — but faster, offline, and in your terminal — gitpulse is live on npm. npx @wuchunjie/gitpulse and tell me what your repo looks like. I read every comment.

3 Months of Shipping Tiny Tools: What Actually Drove Downloads

ke jia — Sat, 22 Aug 2026 10:00:57 +0000

I have spent the last few months shipping a string of small tools: a scaffolding CLI, a secret scanner, a git analytics tool, a snippet manager, and a set of 14 browser utilities. All free, all zero-dependency.

The interesting question was never "how do I build these?" (each takes an afternoon). The question was: what actually gets them used?

Honest retrospective, with the parts that worked and the parts that did not.

What Drove Downloads

1. Dev.to articles with real terminal output

Every article I published included actual command output — not "here is what it might look like", but the real thing, pasted. Those articles consistently outperformed the polished ones.

Why: developers sniff out marketing from a mile away. A terminal screenshot of the tool actually running reads as evidence.

2. The `npx`-first design

Zero install, zero config. The friction between "saw an article" and "ran the tool" was one line:

npx @wuchunjie/dotguard .

Every tool that required setup got fewer users than every tool that did not. No contest.

3. Cross-linking

Each article's footer listed all four CLI tools. A reader of the snippet article met the scaffolder. A reader of the security article met the analytics tool. The funnel is a web, not a line.

4. The npm page itself

A good one-line description, a README with copy-paste commands, and sensible keywords. npm search is a quiet, persistent channel — people find the tools months after the article traffic is gone.

What Did Not Work

1. Generic "top 10 tools" posts

The listicle format gets reads but barely converts when your tool is item #7 in a list of ten famous ones. Specificity beats breadth: "the tool for this exact job" wins.

2. Trying every platform at once

I tried to spread across several communities and burned out in a week. One platform (Dev.to), one rhythm (a few well-targeted articles), beat scattered presence everywhere.

3. Announcing "v1.0" like a product launch

Nobody cares about version numbers for a free utility. The tool either solves the moment it appears in the article or it does not.

The Pattern That Repeats

Every successful push followed the same shape:

One concrete pain ("your .env is in the repo")
One command that solves it (npx @wuchunjie/dotguard .)
Real output as proof
Cross-links to the other tools
A quiet Ko-fi line

The tools are small on purpose. The funnel is the product.

What Is Next

More templates in the scaffolder, more scan patterns in the scanner, and — if the feedback says yes — a small web dashboard that reads the same local JSON files the CLIs write. Same rules: free, local-first, zero bloat.

If any of these saved you time, the Ko-fi is how the next one gets built.

GitHub: wuchunjie00/devtools

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

The Exact Funnel I Use to Get Free CLI Tools Their First Users

ke jia — Sat, 22 Aug 2026 09:55:45 +0000

Every open-source tool has the same brutal first 90 days: zero users, zero signal, no idea whether anything works.

I have shipped several free CLI tools and browser tool sets. This is the exact funnel I use — no ads, no paid growth, no "build in public" theater. Just a repeating sequence of small, concrete actions.

Step 1: Make the Tool Trivial to Try

The first rule: npx must work. If a reader has to install, configure, and read a README before running the first command, the funnel is already broken.

npx @wuchunjie/dotguard .

That is the entire onboarding. Zero dependencies, no config, instant output. The first 10 seconds decide whether the reader comes back.

Step 2: Publish One Article Per Angle

Not one article. One per angle, spread over time:

Tutorial — "Scan your .env files in 1 command" (the how)
Comparison — "Why I stopped using X" (the why)
Listicle — "5 tools for Y" (the discovery)
Workflow — "My dev setup" (the context)
Security/devops — "Your CI is missing this" (the fear)

Each article targets a different search intent. A developer looking for "pre-commit secret scan" lands on article 4, not article 1. The funnel is wide because the angles are wide.

Step 3: Cross-Link Everything

Every article mentions every tool. The footer of a snippet article lists the scaffolder and the scanner. The GitHub repo links to the articles. The npm README links to the articles.

The effect is compounding: a reader of article 3 meets four tools, not one. Your content becomes a network instead of a pile.

Step 4: Make the GitHub Repo the Hub

The repo README is the landing page that never goes stale:

One-line description per tool
Install/run commands (copy-paste ready)
Links to every article
A donation link, present but quiet

GitHub is where developers actually trust. Stars and forks are the signal that converts "interesting article" into "let me try it".

Step 5: Add the Quiet CTA

One line at the end of every article:

If this saved you time, a Ko-fi keeps the next tool coming.

No guilt, no popup, no "SUPPORT US!!!". A single, plausible reason to donate. It converts a small percentage of genuinely grateful readers — and that percentage is the whole business model.

What Actually Works (Honest Version)

Articles with real output beat polished fiction. Paste the terminal output. It reads as true.
Specificity wins. "5 Lines for a Pre-Commit Hook" outperforms "Improve Your Security".
Consistency beats volume spikes. One good article a week for a month outperforms ten in a day.
The npm page matters. Good description, good keywords, README with screenshots. npm search is a silent acquisition channel.

No magic. Just the same five steps, repeated, until the compounding kicks in.

GitHub: wuchunjie00/devtools

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

npx Is Your New Install: A Field Guide to Zero-Install CLI Tools

ke jia — Sat, 22 Aug 2026 09:50:33 +0000

There is a habit I stopped a few years ago: installing CLI tools globally.

npm install -g used to be the default for everything — the linter, the formatter, the scaffolder, the "useful one-liner I will probably never run again". My global package list became a museum of abandoned tools, and every Node upgrade was a roll of the dice.

The replacement is one command: npx.

What npx Actually Does

npx <package> fetches the package, runs its binary, and leaves nothing behind. No global install, no version pinned in your package.json, no cleanup. The tool exists for the duration of the command.

For one-off and occasional tools, that is exactly the right lifecycle.

The Zero-Install Pattern, Applied

Here are four tools I run this way daily — none of them are installed anywhere:

Scaffold projects

npx scaffoldx-cli

Interactive list of nine templates (React, Next.js, Express, FastAPI, Chrome extension, CLI, landing page, Discord bot, Electron). Pick, name, done — git init included.

Manage snippets

pbpaste | npx @wuchunjie/snippetx add my-snippet js
npx @wuchunjie/snippetx search my

Everything lives in ~/.snippetx/snippets.json. The tool is ephemeral; the data is yours.

Scan for leaked secrets

npx @wuchunjie/dotguard .

Walks the directory, flags exposed keys and passwords in .env files, exits non-zero on findings (so it is a one-line CI gate).

Read a repo's pulse

npx @wuchunjie/gitpulse

Commits, contributors, file breakdown, activity — one screen.

When to Use npx vs. Install

Situation	Use
Run once or twice a year	`npx`
Tool with heavy dependencies, run occasionally	`npx`
Core daily driver (your editor, your test runner)	Install it properly
Team needs a pinned version	Pin in `devDependencies`
You are not sure you will keep using it	`npx` — try before you commit

The rule of thumb: default to npx, install only when the tool earns a permanent slot.

Why This Matters More Than It Looks

A zero-install toolchain cannot rot. There is nothing to update, nothing to break on a Node upgrade, nothing to audit. The tools are as old as the last time you ran them — and as disposable.

My global npm ls -g output is now short enough to read. That is the real feature.

npm: scaffoldx-cli · @wuchunjie/snippetx · @wuchunjie/dotguard · @wuchunjie/gitpulse

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

Found a Secret in Git History? A Calm 3-Step Recovery Plan

ke jia — Sat, 22 Aug 2026 09:45:22 +0000

You just found it. That API_KEY=... has been in your repo's history for six months. Your heart rate goes up. Good — now do these three things in order, because the order is the whole game.

Step 1: Rotate the Secret First (Not Second, Not Later)

This is the step everyone skips, and skipping it makes everything else decorative.

A leaked secret is compromised the moment it is readable. Deleting it from the repo does not un-read it. Bots index public repos. Someone may have already cloned it.

Go to the provider's dashboard and rotate now:

API key → new key, old key revoked
Database password → new password, old one gone
JWT secret → new value (yes, your sessions die; that is cheaper than a breach)
Webhook token → regenerate

Do this before touching git at all. The clock starts at leak, not at cleanup.

Step 2: Scan for What Else Is Exposed

You found one. Assume there are more. Run a scan across the whole project:

npx @wuchunjie/dotguard .

  🔍  Scanning: /home/dev/my-app

  📄  .env (2 issues)
    ⚠️  L  3 | API key
    ⚠️  L  7 | Database URL

DotGuard walks every .env file and flags passwords, keys, tokens, private keys, and database URLs — with line numbers. Zero dependencies, one command.

Rotate everything it finds, not just the one that got you caught.

Step 3: Clean the History

The secret is in history, so history is the leak. Your options, in order of how much you care about the history:

Option A: Small repo, no precious history — delete and re-clone.

# from a clean checkout without the bad commits
git init
git add .
git commit -m "fresh start"
git push --force

Nuclear, but honest. For side projects this is the fastest correct answer.

Option B: Shared repo, history matters — rewrite with git filter-repo, remove the file, force-push, and make every clone re-clone (a filtered repo's history is unrecoverable from stale clones — the old secret lives on in every machine that ever cloned it).

Option C: The secret was short-lived — if it was rotated within minutes of the push, document the incident and move on. Risk is time-exposed × value-of-secret.

Aftermath: Make It Not Happen Again

.env in .gitignore, .env.example committed with empty values
A pre-commit hook that runs the scanner (its non-zero exit blocks the commit)
The same scan as a CI step

Three gates, all free, all one-liners. The incident you are cleaning up right now is the cheapest lesson it will ever cost you.

npm: @wuchunjie/dotguard | GitHub: wuchunjie00/devtools

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

Your CI Pipeline Is Missing This One-Step Secret Scan

ke jia — Sat, 22 Aug 2026 09:40:10 +0000

Your CI pipeline probably runs tests, builds, and lints. It does not check whether a secret just got committed.

That gap is one line.

The Problem in One Sentence

Secrets do not get committed on purpose. They get committed in a hurry, in a "quick fix" branch, by an intern, by you at 6pm on a Friday — and CI, which saw every other line of the diff, saw the API_KEY=sk_live_... and said "build passed".

The One-Line Gate

DotGuard is a zero-dependency scanner for .env files. It walks a directory, finds every .env, and flags hardcoded passwords, API keys, access tokens, private keys, and database URLs.

The critical behavior for CI: it exits with code 1 when it finds potential secrets.

Add it to your pipeline:

# .github/workflows/ci.yml
steps:
  - uses: actions/checkout@v4
  - name: Scan for exposed secrets
    run: npx -y @wuchunjie/dotguard .
  - name: Tests
    run: npm test

That is the whole change. No service to sign up for, no API key for the scanner (ironic, I know), no SaaS bill. One npx, zero dependencies, runs in seconds.

What It Catches

Finding	Example
Hardcoded password	`PASSWORD=hunter2`
API key	`API_KEY=sk_live_...`
Access token	`TOKEN=ghp_...`
Private key block	`BEGIN OPENSSH PRIVATE KEY`
Database URL	`DATABASE_URL=postgres://user:pw@host/db`
Long secret string	any 20+ char quoted blob

It also notes missing basics like NODE_ENV — the kind of gap that turns into a 2am "why did it deploy to the wrong env" ticket.

The Right Order of Defense

CI scanning is the second gate, not the first:

Pre-commit hook (catches it before it is committed) — DotGuard's exit code makes this a 5-line hook
CI step (catches what the hook missed, or what came from a force-push)
Rotation runbook (when one already escaped: rotate first, then clean history)

A repo with all three has essentially no realistic path for a .env to reach production via git. The first two are free; the third is just discipline.

Why Not the SaaS Scanner

The big secret-scanning platforms are fine for enterprise, and they cost money per seat. For the 95% case — "does my repo have a leaked .env?" — a local, zero-dependency scanner with an exit code is the entire job.

Ship the one line. Your pipeline stops being a secret leak detector that never detects.

npm: @wuchunjie/dotguard | GitHub: wuchunjie00/devtools

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

Terminal-First Development: Why I Closed 30 Browser Tabs and Kept 4 Commands

ke jia — Sat, 22 Aug 2026 09:34:58 +0000

I used to develop with 30 tabs open. GitHub, docs, Stack Overflow, a snippet service, a JSON formatter, a Base64 encoder, three different "tool" sites, and somewhere in there — the code.

Last month I ran an experiment: close all of it, and do the same work from the terminal. Four npx commands later, I had everything those tabs did.

This is the argument for terminal-first, with receipts.

Tab 1: "New project setup" → `npx scaffoldx-cli`

The tab was 14 open "how do I set up X" articles and a 2019 starter repo.

The command:

npx scaffoldx-cli

Nine templates, one pick, one project name. The folder exists with working configs and git init already run. The 14 tabs are now a number on a menu.

Tab 2: "That snippet I saved" → `npx @wuchunjie/snippetx`

The tab was the "code stuff" bookmark folder — 40 entries, zero search by content.

npx @wuchunjie/snippetx search debounce
npx @wuchunjie/snippetx copy f3a1b2c4 | pbcopy

Snippets live in ~/.snippetx/snippets.json. Search matches content, not just titles. The bookmark folder is deleted.

Tab 3: "Repo overview" → `npx @wuchunjie/gitpulse`

The tab was the GitHub web UI: commits page, contributors page, graphs page. Three clicks, three loads, three tabs.

npx @wuchunjie/gitpulse

Commits, contributors with bar charts, file-type breakdown, activity heatmap — one screen, one command, no navigation.

Tab 4: "Is this .env safe?" → `npx @wuchunjie/dotguard`

The tab was a "secret scanner" website — which is itself a security problem, because scanning means pasting your secrets into someone else's server.

npx @wuchunjie/dotguard .

Local scan, local results, non-zero exit code for CI. Your secrets never leave the machine. That is not a small point.

What the Terminal Won

Speed. Four commands versus 30 tabs of clicking. The browser was never fast; it was just familiar.
Privacy. Nothing sensitive gets pasted into a third-party site.
Composability. pbpaste | snippetx add, dotguard . && git commit — the terminal chains, tabs do not.
Stability. A zero-dependency CLI does not get a redesign, a paywall, or a sunset. A website gets all three.

What I Kept Open

To be honest: docs sites, when I need them, and the browser for things that are genuinely visual. "Terminal-first" is not "browser-hating". It is: the browser is a destination, not a workspace.

The workspace is where the code is.

npm: scaffoldx-cli · @wuchunjie/snippetx · @wuchunjie/gitpulse · @wuchunjie/dotguard

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

A 2026 Starter Toolkit for New Developers: 5 Free Tools, Zero Dollars

ke jia — Sat, 22 Aug 2026 09:29:46 +0000

If you are starting to build things in 2026 — or you have been building for years but your toolchain is a pile of half-remembered Gists — here is the entire toolkit I would hand you.

Five tools. All free. All zero-install. Total cost: $0.

1. ScaffoldX — for starting any project

npx scaffoldx-cli

Stop googling "how to set up React in 2026". Pick a template (React, Next.js, Express, FastAPI, Chrome extension, CLI tool, landing page, Discord bot, Electron), name your project, and get a clean folder with working configs — git init included.

This is the tool that replaces the first hour of every project.

2. SnippetX — for never losing code again

pbpaste | npx @wuchunjie/snippetx add my-snippet js

A snippet manager that lives in your terminal. Save with a pipe, find with search, use with copy. Your snippets are a single local JSON file — no account, no service that can sunset.

New developers lose snippets constantly because they have nowhere to put them. This is that somewhere.

3. DotGuard — for not leaking your first secret

npx @wuchunjie/dotguard .

Your first .env file is also your first leaked secret, statistically. DotGuard scans a project for exposed keys, passwords, and database URLs before it is a problem. One command, no config.

Learn this one early: scanning your repo is a habit, not a one-time thing.

4. GitPulse — for understanding any repo in 10 seconds

npx @wuchunjie/gitpulse

Opening someone else's repo (or your own, three months later)? One command gives you commit counts, contributor breakdown, file-type mix, and recent activity. You stop guessing what a repo is about from its README alone.

5. 14 Browser Tools — for everything in between

Base64, JSON/CSV conversion, JWT decoding, hashing, QR codes, UUIDs, password generation, diff checking, and more — 14 static pages that run in your browser with no install, no account, no tracking:

wuchunjie00.github.io/devtools

The Common Thread

Every tool here follows the same rules:

Zero dependencies — nothing to break, nothing to update
npx or a URL — no install step, no global pollution
Local data — your code and secrets stay on your machine
Free, forever — and if you use them, a Ko-fi buys the next tool

Bookmark this list. You will need it the first time a new project starts.

GitHub: wuchunjie00/devtools

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

My Entire Dev Workflow Runs on 4 Tiny npm Packages

ke jia — Sat, 22 Aug 2026 09:24:34 +0000

I keep my toolchain deliberately small. No IDE extension suite, no "developer environment" with 40 moving parts. Just four zero-dependency npm packages, run with npx, covering the four moments where my old workflow leaked time.

Here is the map.

1. Starting a project → ScaffoldX

The moment: "new folder, sensible defaults, go."

npx scaffoldx-cli

Nine templates (React, Next.js, Express, FastAPI, Chrome extension, CLI, landing page, Discord bot, Electron), one interactive pick, project generated with git init already done.

What it killed: the 30-minute "copy an old project and delete half of it" ritual.

2. Saving code snippets → SnippetX

The moment: "I found the one-liner I needed, now where does it go?"

pbpaste | npx @wuchunjie/snippetx add debounce js

Everything lives in ~/.snippetx/snippets.json. Search by name or content, copy back to clipboard or append to a file:

npx @wuchunjie/snippetx search debounce
npx @wuchunjie/snippetx copy f3a1b2c4 | pbcopy

What it killed: the 40-tab "code stuff" bookmark folder.

3. Checking a repo's health → GitPulse

The moment: "what is actually going on in this repo before I touch it?"

npx @wuchunjie/gitpulse

Total commits, contributors with bar charts, file-type breakdown, recent activity heatmap — in the terminal, in one command.

What it killed: opening the GitHub web UI, clicking through three pages, mentally reconstructing the same data.

4. Shipping with a clean conscience → DotGuard

The moment: "one last check before this goes public."

npx @wuchunjie/dotguard .

Walks the directory, finds every .env file, flags hardcoded passwords, API keys, tokens, private keys, and database URLs. Exits non-zero on findings, so it is a one-line CI gate too.

What it killed: the "I probably did not commit the .env" hope.

Why Four, and Why These

Each package covers exactly one recurring pain, has zero dependencies, runs via npx (no install, no version drift in my global packages), and prints results I can read in 5 seconds.

The total maintenance cost of the whole workflow: zero. The total install cost: zero. That is the point of keeping it small — when every tool is one npx away, the workflow cannot rot.

The Full List

Package	Command	Job
`scaffoldx-cli`	`npx scaffoldx-cli`	Generate project templates
`@wuchunjie/snippetx`	`npx @wuchunjie/snippetx`	Terminal snippet manager
`@wuchunjie/gitpulse`	`npx @wuchunjie/gitpulse`	Git repo analytics
`@wuchunjie/dotguard`	`npx @wuchunjie/dotguard`	.env secret scanning

All free, all MIT, all zero-dependency.

npm: scaffoldx-cli · @wuchunjie/dotguard · @wuchunjie/gitpulse · @wuchunjie/snippetx

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

The 5 Browser Tools I Use Every Single Day (All Free, No Install)

ke jia — Sat, 22 Aug 2026 09:19:17 +0000

Fifteen browser tools live in my bookmark bar. Five of them get opened daily. Here they are, and why each one earned a permanent spot.

All five are from the same free, no-install, no-tracking set: wuchunjie00.github.io/devtools.

1. Base64 Tool — open it

Daily use: decoding the base64 blobs that show up in logs, headers, and "just paste this" support tickets.

Why it stays: paste → encode → decode → copy. No file upload, no "pro plan" wall. The data never leaves the tab.

2. JWT Decoder — open it

Daily use: reading a token's payload during debugging — exp, sub, role, whatever is in the claims.

Why it stays: local decode means I am not pasting a bearer credential into some third-party site. That one decision is why I use this over the paid "API toolkits".

3. Hash Generator — open it

Daily use: quick MD5/SHA-256 checks — file integrity, verifying a value a doc claims, comparing checksums.

Why it stays: it is three seconds from "I wonder what this hashes to" to the answer.

4. CSV to JSON — open it

Daily use: converting the CSV exports that every SaaS loves to send me into something my scripts can read.

Why it stays: paste in, copy out, paste into the script. No account, no 10-row free limit, no "upgrade to export".

5. Diff Checker — open it

Daily use: "are these two config blocks actually different?" — env files, API responses, copy-pasted configs.

Why it stays: side-by-side diff with the differences highlighted. It answers the question in 10 seconds that used to take 10 minutes of squinting.

The Pattern

Notice what none of these do: no login, no upload, no tracking, no trial. They are static pages of HTML/CSS/JS that run in your tab. That is the whole feature set, and it is why I trust them with data I would not paste anywhere else.

The Rest of the Set

The other nine — cron parser, YAML to JSON, HTML entities, HTML to text, lorem ipsum, password generator, QR code, slug generator, UUID generator — cover the weekly and monthly tasks. Same rules: free, local, no account.

Bookmark the index: wuchunjie00.github.io/devtools

GitHub: wuchunjie00/devtools

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

6 Web Tools You Are Paying For That I Run for Free in My Browser

ke jia — Sat, 22 Aug 2026 09:14:03 +0000

I went through my subscriptions last month and found six tools I was paying for that do exactly one thing: transform text. Base64 encode. JSON to CSV. Generate a UUID.

Each has a $5–10/month tag. Together they cost more than my domain registration.

Then I built the free version. Here is the comparison, tool by tool.

1. Base64 Encoder/Decoder

Paid tools: $5/mo, "unlimited encodes", ads.
Free version: wuchunjie00.github.io/devtools/base64-tool — paste, encode, decode, done.

2. JSON ⇄ CSV Converter

Paid tools: $8/mo, export limits, "team plan" upsell.
Free version: csv-to-json and yaml-to-json — paste in, copy out. Nothing leaves your browser.

3. Hash Generator

Paid tools: MD5/SHA "forensic tools" at $12/mo.
Free version: hash-generator — MD5, SHA-1, SHA-256, SHA-512 in your browser, no upload.

This is the one that matters: the paid tools upload your data to their server. The browser version computes locally. For anything sensitive, that is not a feature difference, it is the difference.

4. JWT Decoder

Paid tools: $6/mo "API security toolkit".
Free version: jwt-decoder — paste the token, read the payload. (Reminder: tokens are bearer credentials; decoding in a local tool is fine, pasting them into random sites is how they leak.)

5. QR Code Generator

Paid tools: $4/mo, "commercial license", watermark removal.
Free version: qr-code-generator — generate, download, no watermark, no license fee.

6. Password / UUID / Slug Generators

The "utility suites" at $7/mo.
Free versions: password-generator, uuid-generator, slug-generator, lorem-ipsum.

The Full Set

That is 14 tools in total, all at wuchunjie00.github.io/devtools:

Base64 · CSV to JSON · YAML to JSON · Cron parser · Diff checker · Hash generator · HTML entities · HTML to text · JWT decoder · Lorem ipsum · Password generator · QR code · Slug generator · UUID generator

Why They Are Free (Forever)

They run 100% in your browser. No backend, no server costs, no data collection — which is also why there is no business model to "sustain". The cost of running them is zero, so the price is zero. If you use them, a Ko-fi keeps the next batch coming.

The Math

Six subscriptions, ~$40–50/month. Fourteen browser tabs, $0/month.

Your call which side of that line you are on.

GitHub: wuchunjie00/devtools

From the same toolbox

ScaffoldX — generate production-ready project templates in seconds: npx scaffoldx-cli
DotGuard — scan .env files for exposed secrets: npx @wuchunjie/dotguard
GitPulse — git analytics (commits, contributors, activity) in your terminal: npx @wuchunjie/gitpulse
SnippetX — save, search, and copy code snippets from the terminal: npx @wuchunjie/snippetx

GitHub: wuchunjie00/devtools

☕ If This Saved You Time

All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:

Buy me a coffee on Ko-fi

Built with ❤️. Zero dependencies, zero tracking, zero bloat.

DEV Community: ke jia

I Ran 4 Secret Scanners on the Same File. The Smallest One Found the Least — and I Still Use It Daily

The test file

Contender 1: dotguard (zero dependencies, ~1 second)

The gotcha I want you to know about

Contender 2: gitleaks (the deep scan)

Contender 3: TruffleHog (the verifier)

Contender 4: GitHub secret scanning (the safety net)

The scoreboard

So what do I actually use?

My Git CLI Was Silently Broken on Windows for 3 Months — A 2>/dev/null Bug That Taught Me the Hard Way

The Bug

2>/dev/null Does Not Exist on Windows

The Debug Journey

The Fix

Rules I'm Writing Down Now

What gitpulse Actually Shows

If You're Shipping CLIs

3 Months of Shipping Tiny Tools: What Actually Drove Downloads

What Drove Downloads

1. Dev.to articles with real terminal output

2. The npx-first design

3. Cross-linking

4. The npm page itself

What Did Not Work

1. Generic "top 10 tools" posts

2. Trying every platform at once

3. Announcing "v1.0" like a product launch

The Pattern That Repeats

What Is Next

From the same toolbox

☕ If This Saved You Time

The Exact Funnel I Use to Get Free CLI Tools Their First Users

Step 1: Make the Tool Trivial to Try

Step 2: Publish One Article Per Angle

Step 3: Cross-Link Everything

Step 4: Make the GitHub Repo the Hub

Step 5: Add the Quiet CTA

What Actually Works (Honest Version)

From the same toolbox

☕ If This Saved You Time

npx Is Your New Install: A Field Guide to Zero-Install CLI Tools

What npx Actually Does

The Zero-Install Pattern, Applied

Scaffold projects

Manage snippets

Scan for leaked secrets

Read a repo's pulse

When to Use npx vs. Install

Why This Matters More Than It Looks

From the same toolbox

☕ If This Saved You Time

Found a Secret in Git History? A Calm 3-Step Recovery Plan

Step 1: Rotate the Secret First (Not Second, Not Later)

Step 2: Scan for What Else Is Exposed

Step 3: Clean the History

Aftermath: Make It Not Happen Again

From the same toolbox

☕ If This Saved You Time

Your CI Pipeline Is Missing This One-Step Secret Scan

The Problem in One Sentence

The One-Line Gate

What It Catches

The Right Order of Defense

Why Not the SaaS Scanner

From the same toolbox

☕ If This Saved You Time

Terminal-First Development: Why I Closed 30 Browser Tabs and Kept 4 Commands

Tab 1: "New project setup" → npx scaffoldx-cli

Tab 2: "That snippet I saved" → npx @wuchunjie/snippetx

Tab 3: "Repo overview" → npx @wuchunjie/gitpulse

Tab 4: "Is this .env safe?" → npx @wuchunjie/dotguard

What the Terminal Won

What I Kept Open

From the same toolbox

☕ If This Saved You Time

A 2026 Starter Toolkit for New Developers: 5 Free Tools, Zero Dollars

1. ScaffoldX — for starting any project

2. SnippetX — for never losing code again

3. DotGuard — for not leaking your first secret

`2>/dev/null` Does Not Exist on Windows

2. The `npx`-first design

Tab 1: "New project setup" → `npx scaffoldx-cli`

Tab 2: "That snippet I saved" → `npx @wuchunjie/snippetx`

Tab 3: "Repo overview" → `npx @wuchunjie/gitpulse`

Tab 4: "Is this .env safe?" → `npx @wuchunjie/dotguard`