Building a Dependency Resolver ft. VibeCodeArena

There’s a moment every developer has had, even if they don’t say it out loud.

You run:

npm install

Thousands of packages get installed. A lockfile appears. Everything just… works.

And you move on.

But if you stop for a second and ask what actually just happened, things get uncomfortable fast.

How did it decide which version of a package to install?
What happens when two dependencies want different versions of the same thing?
Why do circular dependencies sometimes crash everything?

This challenge forces you to answer those questions the hard way.

By building your own mini dependency resolver.

It Starts Simple — Until It Really Doesn’t

At the beginning, it feels manageable.

You define a few packages:

addPackage("react", "18.2.0", ["scheduler@^0.23.0"]);
addPackage("scheduler", "0.23.0", []);
addPackage("lodash", "4.17.21", []);

Then you say:

resolve("react@18.2.0");

And expect something like:

react@18.2.0
└── scheduler@0.23.0

So far, so good.

But that’s not dependency resolution.

That’s just following pointers.

The First Real Problem: Versions Are Not Strings

The moment you introduce semantic versioning, everything changes.

"^1.2.3"
"~1.2.3"
"1.2.3"

These are not just versions.

They are constraints.

And your resolver has to interpret them.

Why ^ and ~ Are Trickier Than They Look

Take:

^1.2.3

This means:

>= 1.2.3 AND < 2.0.0

But:

~1.2.3

Means:

>= 1.2.3 AND < 1.3.0

So now your system needs to:

1. Parse version strings into structured data
2. Compare versions numerically
3. Filter all available versions
4. Pick the highest compatible one

Something like:

function isCompatible(version, range) {
  // parse major, minor, patch
  // apply rules for ^ or ~
}

This is the first moment where your “simple system” becomes an algorithmic problem.

The Registry Isn’t a List — It’s a Time Machine

You don’t just store one version per package.

You store many:

registry = {
  lodash: ["4.17.19", "4.17.20", "4.17.21"],
  axios: ["1.5.0", "1.6.0"]
};

So when someone asks for:

axios@^1.5.0

You don’t return "1.5.0".

You return:

"1.6.0"

Because it’s the highest compatible version.

This is where most naive implementations fail.

They match.

They don’t optimize.

Dependency Resolution Is Actually Graph Traversal

Once you move beyond one level, the structure reveals itself:

A
├── B
│   └── D
└── C
    └── D

This is not a tree.

This is a graph.

And resolving dependencies is not recursion.

It’s graph traversal with constraints.

The Hidden Complexity: Conflicting Requirements

Now consider:

A → B@^1.0.0
C → B@^2.0.0

You try to resolve:

root = [A, C]

What do you do?

There is no version of B that satisfies both.

This is not a bug.

This is a conflict.

And your resolver needs to detect it and explain it.

Something like:

Version conflict:
- A requires B@^1.0.0
- C requires B@^2.0.0

This is where your system stops being a tool…

…and starts behaving like a real package manager.

Cycle Detection: The Silent Killer

Then comes the nightmare scenario:

A → B → C → A

If you naively recurse, your program never stops.

So you introduce something like:

const visiting = new Set();

function resolve(pkg) {
  if (visiting.has(pkg)) {
    throw Error("Cycle detected");
  }
  visiting.add(pkg);
  ...
  visiting.delete(pkg);
}

But detecting a cycle is not enough.

You need to explain it:

Cycle detected:
A → B → C → A

Because debugging dependency graphs without visibility is a nightmare.

Topological Sorting: The “Install Order” Problem

Once everything is resolved, you still have one more step.

Installation order.

You can’t install a package before its dependencies.

So you compute something like:

D → B → C → A

This is a topological sort.

And it’s one of those concepts that feels academic…

until you realize it’s powering every build system you’ve ever used.

The Resolver Is Not One Function — It’s a System

At this point, your architecture starts to matter.

You naturally separate concerns:

• Registry Layer → stores packages and versions
• Version Engine → parses and compares semver
• Resolver → builds the dependency graph
• Validator → detects conflicts and cycles
• UI Layer → displays results

Because trying to do this in one file?

That’s how bugs multiply.

The UI Changes How You Think About the Problem

Once you visualize the tree:

react@18.2.0
├── scheduler@0.23.0
└── something-else@1.1.0

You start noticing things you didn’t before:

• Duplicate dependencies
• Deep nesting
• Unexpected versions

And when you add a “Visualize Tree” button, suddenly your resolver becomes explainable.

Which is what real tools struggle with.

The Lockfile: Freezing Time

One of the most underrated features is the lockfile.

After resolving:

{
  react: "18.2.0",
  scheduler: "0.23.0"
}

You save it.

Because next time, you don’t want “latest compatible”.

You want exactly this.

This is the difference between:

• Reproducible builds
• And chaos

Where Most Implementations Break

There’s a pattern you start noticing.

A lot of systems “work” for simple cases.

But fail when:

• Multiple versions exist
• Constraints overlap
• Graph depth increases
• Cycles appear

Because dependency resolution is not about happy paths.

It’s about edge cases interacting with each other.

The Subtle Beauty of This Problem

What makes this challenge special is that it quietly combines:

• String parsing
• Graph theory
• Constraint solving
• System design

And wraps it in something every developer uses daily.

You’re not learning an abstract algorithm.

You’re reverse-engineering reality.

The Moment Everything Clicks

There’s a point, somewhere in the middle of debugging, where things shift.

You stop thinking:

“Why is this not working?”

And start thinking:

“What is the system trying to guarantee?”

And the answer is:

• Consistency
• Determinism
• Compatibility

That’s what real package managers optimize for.

Not just installation.

Final Thought

Building a dependency resolver doesn’t just teach you how npm works.

It teaches you something deeper.

That most “simple tools” we rely on…

are actually layers of carefully designed systems solving hard problems quietly.

And once you’ve built even a tiny version of one,

you don’t take npm install for granted anymore.

You understand the chaos it’s preventing.

👉 Try it out here: https://vibecodearena.ai/share/1261e358-7da7-4b9d-ada3-ea495b132806