Last month I was debugging a Prisma issue for like two hours.
Everything was fine the day before. Same code. Same machine. I hadn't touched the project in a few days, came back, ran it boom, crash. PrismaClientInitializationError. I checked the schema. I checked the database. I regenerated the client. Nothing.
Turns out I had updated some global packages a couple days earlier and Prisma's CLI version had drifted out of sync with what the project expected. Two hours of my life. Gone. For a version number.
And the worst part? I couldn't even be sure that was the actual cause. I was just guessing.
That's the thing nobody talks about. Your environment is silently mutating all the time. You npm install -g something here, your Node version bumps there via nvm, a port that used to be free is now occupied — and you have zero record of any of it. When something breaks, you're doing archaeology with no tools.
So I spent a day and built snapcd.
What it does
Every time you cd into a project directory, it silently takes a snapshot of your environment in the background. We're talking:
- Node + npm versions
- All globally installed packages and their versions
- Environment variables (sensitive ones like
SECRET,TOKEN,KEYget auto-redacted) - PATH entries
- Open ports
- Hostname, platform, CWD
Under 100ms. You won't even notice it's running. Same trick nvm and direnv use.
Then when something breaks, you just run:
snapback diff
And you get a clean diff of exactly what changed between your last two snapshots.
Snapback diff: "before-upgrade" → "after-upgrade"
Core
✅ Node.js : v20.11.0
⚠️ npm : 9.8.1 → 10.2.4
Global npm Packages
typescript ⚠️ changed 4.9.5 → 5.3.2
vercel ✚ added 33.0.0
netlify-cli ✗ removed 17.0.0
Open Ports
✚ 3000
✗ 8080
If I'd had this during the Prisma incident, I would've seen prisma sitting right there with a version change and fixed it in five minutes.
How to use it
npm install -g snapcd
Add the shell hook to your .zshrc or .bashrc:
eval "$(snapback hook)"
That's it. From now on every cd auto-snapshots silently. You can also save manual named snapshots before doing something risky:
snapback save before-that-upgrade
# do the thing
snapback save after-that-upgrade
snapback diff before-that-upgrade after-that-upgrade
Everything is stored locally in ~/.snapback/<project-name>/snapshots.json. No account, no cloud, no telemetry.
Why I built it in a day
Honestly I didn't want to over-engineer it. The whole point is that it should be invisible until you need it. I wrote it in Node.js, kept the output readable, and shipped it.
There's a certain class of bugs that aren't really bugs — they're just your environment silently changing underneath you. snapcd doesn't fix those bugs. It just makes sure you're never blind when they happen.
If you've ever said "it worked yesterday" and meant it, give it a try.
GitHub: github.com/achugh787/snapcd
Docs: achugh787.github.io/snapcd
Curious what you think. Would love feedback on what else it should track.

Top comments (0)