HalfStack Phoenix Recap

Last week vlt sponsored HalfStack Phoenix, a community conference with events in the United States and Europe.

Darcy and I were in attendance to show off some of the latest features we've been working on for the vlt client and to present a talk titled "Performing Laparoscopic Lockfile Surgery" about how vlt gui can help teams introspect their dependency graphs in complex monorepos.

The Booth

The Talk

Slides

My talk was centered around the idea that our lockfiles (and therefore our node_modules) contain a lot of dependencies on average. This is a great and powerful thing as it allows us to "stand on the shoulders of giants" when developing our applications. Add monorepos into the mix and the number of dependencies can grow exponentially.

But our lockfiles are generally designed to be machine readable and if us humans attempt to make sense of them, we're going to have a difficult time. And this is exacerbated as you run into conflicts with peer dependency resolution or constraints like packages that expect to be singletons. How many times has the solution been to just rm -rf node_modules and start over? Without tools to help us understand our dependency graph, we're left with few options.

vlt gui

The second half of my talk was running vlt gui on several example JavaScript/TypeScript projects to visualize their dependency graphs as I ran different queries on them. Here's one of the examples from the talk:

Multiple next Projects in a Monorepo

It's a common case for teams to use different versions of the same framework across projects in a monorepo. A new project might use the latest version before an older project can be updated. But it can be difficult to see what transient dependencies are shared between those projects.

Using queries in the vlt gui we can see the different versions of next and react that are in use across the monorepo.

#next

If we start with the #next query we can see the 6 different versions of next that are in use across the monorepo:

#next > #react

Drilling down into the #next > #react query we can see that the 6 different versions of next depend on only 3 different versions of react:

#next > #react[version="17.0.2"]

If we then look at a single version of react with the query #next > #react[version="17.0.2"] we can see that our apps running next@10 and next@11 but use react@17.0.2 although react@16 would work with next@10 but not next@11:

vlt-lock.json

When you do need to look at a lockfile with your human eyeballs, we've made vlt-lock.json easier to read. It is JSON that is designed to be read by the vlt client but also structured in a way that is more human-readable.

Here's an example snippet of a vlt-lock.json file that shows how vlt stores both the versions of dependencies installed (aka nodes) as well as their relationships (aka edges):

Try it Out

Try running vlt gui in your project today to see what your dependency graph looks like. It's a non-destructive command that will only read from your current node_modules directory. If you want to see the full vlt experience, you can run rm -rf node_modules && vlt install first.

If you run into any issues, you can:

• Report a bug
• Pop into our Discord
• Let us know on Bluesky or X