SnapPoint: A Hard Reset for Your Dev Machine

Source: Dev.to

Most developer machines are not clean. They just look clean.

At some point, every dev laptop turns into a dumping ground. You install tools to follow a blog post. You try a framework for a weekend. You switch jobs and inherit a new stack. You uninstall things, but only halfway. Binaries stick around. Config files stay buried in your home directory. Caches grow quietly in the background.

Nothing is fully broken, but nothing feels right either.

Your terminal starts acting weird. A command points to a version you did not install. You run:

which python

and do not like the answer. Node exists in multiple places and you are not sure which one is winning today. You tell yourself you will clean it up later.

Later never comes.

SnapPoint is built for that exact moment – the moment when you realize your system is out of alignment, but you don’t trust yourself to fix it without breaking something.

What SnapPoint actually is

SnapPoint is not another package manager. It does not try to replace Homebrew, NPM, Pip, NVM, Cargo, or anything else you already use.

It sits above them.

SnapPoint is a system auditor and a package‑manager manager. Its job is to understand what is installed on your machine, where it came from, and whether it still belongs there.

• Instead of blindly uninstalling things, SnapPoint builds a mental model of your system first.
• It scans global binaries, traces their origins, checks your PATH, and looks for conflicts, orphans, broken links, and leftovers.
• Only after that does it let you take action.

That difference matters. You are no longer guessing; you are choosing.

The mess we all pretend is normal

Modern dev environments are layered:

1. OS‑level tools
2. Language‑level tools
3. Project‑level tools
4. Wrappers around those tools

Each layer does its own cleanup, but none of them coordinate.

Over time, this creates a few common problems:

• Ghost binaries sitting in /usr/local/bin or /opt/homebrew/bin that no manager claims anymore.
• Multiple versions of the same tool competing for priority in your PATH.
• Gigabytes of cache files for tools you haven’t used in months.
• Orphaned dependencies that were installed for something you already removed.

These are not edge cases. This is the default state of most dev machines after a year or two.

SnapPoint is designed to surface all of that.

The Hunt: understanding before deleting

The first phase of SnapPoint is called the Hunt.

• It scans your system and builds an inventory of every global binary, every PATH entry, and every manager it recognizes.
• For each tool, SnapPoint tries to answer a simple question: “Where did this come from?”
  • Was it installed by Homebrew, NVM, Pip, Cargo…?
  • Or was it dropped there manually with no record?

That origin story is the key. Once you know where a binary came from, you can decide what to do with it. Without that context, cleanup is just educated guessing. SnapPoint turns that guesswork into visibility.

Ghosts and orphans

Some of the most useful output from SnapPoint is what it calls ghosts.

• Ghosts – binaries that exist on your system but are not managed by anything anymore. No package manager claims them, no version manager tracks them. They are just there.

Ghosts are often harmless—until they’re not. They can:

• Override commands you expect to run.
• Confuse PATH resolution.
• Break scripts that expect a different version.

Because no tool owns them, nothing ever removes them. SnapPoint finds these ghosts, flags them clearly, and does not delete them automatically. It shows them to you and explains why they are suspicious.

The same goes for orphans:

• Packages installed as dependencies that were never cleaned up.
• Global tools that duplicate what a local project already manages.
• Broken symlinks pointing nowhere.

This is the stuff that slowly degrades a system. SnapPoint shines a light on it.

Aligning your PATH instead of fighting it

PATH issues are one of the most frustrating parts of local development.

1. You install a tool – it works.
2. Later you install another version elsewhere – the wrong one runs.
3. You add another export to your shell config and hope it sticks.

SnapPoint approaches this differently.

• When it detects multiple versions of the same tool, it shows all of them, where they live, who installed them, and which one is currently active.
• Then it lets you choose the source of truth.
• Instead of endlessly tweaking PATH by hand, you make an explicit decision: this version wins, the others get demoted or removed.

That alignment alone can save hours of debugging over the lifetime of a machine.

Cleanup that actually cleans

Uninstalling is easy. Cleaning up is not.

Most uninstall commands only remove the binary or package reference. They leave behind config folders, state files, and caches. Over time, these leftovers cause strange behavior when you reinstall something later.

SnapPoint includes the idea of cleanup recipes.

• A recipe describes how a tool should be fully removed – not just the executable, but also related folders in .config, .cache, and other known locations.
• This knowledge is shared and community‑driven. No single person knows where every tool hides its junk, which is why SnapPoint is open source.

If you have ever reinstalled a tool and wondered why it still remembered old settings, this is why. SnapPoint aims to fix that properly.

Doctor mode

Some problems are subtle:

• Broken symlinks that point to versions that no longer exist.
• Global packages that shadow project‑local ones.
• Tools that are technically installed but unusable.

SnapPoint includes a doctor mode that looks for these issues and reports them clearly—not as cryptic warnings, but as actionable insights.

System Profiles and Snapfiles

One of the longer‑term ideas behind SnapPoint is system profiles.

Instead of treating your machine setup as a one‑time thing, SnapPoint lets you export:

• Your tools
• Their versions
• Their sources
• Your alignment choices

These become a Snapfile (or snap.json).

You can use it to:

• Recreate your environment on a new machine
• Share it with teammates
• Publish it as a curated setup

Think less “dotfiles magic” and more explicit system DNA. This makes onboarding faster and personal setups portable.

Who SnapPoint Is For

SnapPoint is for developers who care about their tools but are tired of babysitting them.

It is for people who want to understand their machine, not fight it.

• If you’ve ever been afraid to clean your system because you weren’t sure what would break, SnapPoint is for you.
• If your laptop feels slower or stranger than it should, SnapPoint is for you.
• If you want confidence instead of superstition, SnapPoint is for you.

It’s still early. The roadmap includes:

• A full TUI dashboard built with Go and Bubble Tea
• Smarter purging
• Social system profiles

But the core idea is already solid.

SnapPoint does not promise a perfect machine.
It promises clarity.

And once you have that, fixing the rest becomes a lot easier.