How I built a self‑healing package manager

Nersissiian — Tue, 28 Apr 2026 02:45:30 +0000

How I Built a Self-Healing Package Manager from Scratch (Rust + AI)

The first tool that automatically resolves dependency conflicts by generating adapter code — and retries with AI until the build passes.

The Problem: Dependency Hell is Real

Every developer has been there. You're building a Rust project, and suddenly:

Crate A requires tokio 0.2
Crate B requires tokio 1.0

Cargo throws an error, and your build fails. The same happens in Python (click==7.0 vs click==8.0) and in npm (lodash version mismatches). The only "solutions" are to fork one of the libraries, pin an old version forever, or manually write glue code.

I wanted to see if this could be automated away completely.

The Idea: A Package Manager That Heals Itself

What if a tool could:

Detect the conflict automatically
Generate an adapter shim that bridges the two versions
Test the adapter in a sandbox
If it fails, retry with AI-powered code generation

That's how HealDep was born.

Architecture Overview

HealDep consists of several Rust crates and a Python web dashboard:

Component	Description
`healdep` (CLI)	Main binary – parses manifests, controls the healing pipeline
`healdep-synthesizer`	Generates shim crates/packages
`healdep-sandbox`	Builds and tests the generated adapter in isolation
`healdep-registry`	Caches and shares successfully generated shims
Python server	Web dashboard with healing history and REST API

How the Healing Works (Step-by-Step)

1. Parsing Manifests

HealDep reads Cargo.toml, requirements.txt, and package.json. For Rust, it uses the cargo_metadata crate to get the full resolved dependency graph. For Python and npm, it has custom parsers that extract version constraints with regular expressions.

2. Detecting the Conflict

The tool iterates over all packages. If the same crate appears with two different required versions, that's flagged as a conflict:

// Simplified detection logic
for (name, versions) in name_to_versions {
    let unique: HashSet<_> = versions.iter().collect();
    if unique.len() > 1 {
        conflicts.push(Conflict { crate_name: name, versions });
    }
}

## Docker & CI/CD

HealDep is available as a Docker image:

bash
docker pull ghcr.io/nersisiian/healdep:v0.1.0
docker run -p 5000:5000 ghcr.io/nersisiian/healdep:v0.1.0

It also includes GitHub Actions workflows:

ci.yml – lint, test, build, and publish the Docker image
healdep-action.yml – automatically heal dependencies on every push
dependabot-heal.yml – heal PRs opened by Dependabot

Lessons Learned

Dependency graphs are complex – optional features, platform-specific deps, and lock files make this harder than it looks.
AI is a powerful assistant, not a silver bullet – it works well for mechanical translations, but complex logic is still beyond reach.
Sandboxing is essential – never modify the user's project directly. Always test the shim in isolation first.
Multi-language support taught me a lot about the differences (and similarities) between Cargo, pip, and npm.

Try It Yourself

HealDep is 100% open-source (MIT licensed).


bash
git clone https://github.com/Nersisiian/HealDep.git
cd healdep
cargo build --release
./target/release/healdep heal examples/demo_app/Cargo.toml --ai

If you like it, give it a ⭐ on GitHub — it means the world to a solo developer.

- **GitHub**: [https://github.com/Nersisiian/HealDep](https://github.com/Nersisiian/HealDep)
- **Product Hunt**: [https://www.producthunt.com/posts/healdep](https://www.producthunt.com/posts/healdep)

---

## What's Next?

I'm planning to add support for Java (Maven/Gradle) and Go. If you have ideas or want to contribute, open an issue or join the discussion!

**Thank you for reading, and may your builds never fail again.** 🩺

DEV Community: Nersissiian