Unlocking the Power of the Dependency Graph

Welcome, everyone. In this talk, we'll go over some ideas on how to unlock the power of the dependency graph, along with some examples of how to leverage it using the Vault client. I'm Rui Adorno, I'm a founder engineer at Vault, where we're building the future of JavaScript packages. Before that, I worked at NPM Inc. and eventually moved to the NPM CLI team at GitHub. Before joining Vault, I spent two years at Google working with the JavaScript SDK, which gave me another round of experience as an end user before jumping back again to the JavaScript supply chain world. I've been working in the Node.js package management space for years, and what I want to share today comes from that experience.

Well, dependencies are the building blocks of JavaScript projects, but the resulting data structure, a graph they form, has been historically underutilized by the tooling ecosystem. Understanding how these dependencies relate and why they even exist remains surprisingly difficult. Every project has dependencies. Anytime you run an install, the package manager will resolve the dependency, creating a graph data structure that has to be resolved, deduplicated, before eventually writing all the files to disk. But after all, the graph data structure is ignored for almost all other commands. And this graph data structure should be treated as a first-class citizen.

What tooling that treats the graph data structure as a first-class citizen looks like? Well, you should expose that graph structure, then make use of a syntax to allow querying the contents of the structure, and finally, use the understanding of the graph structure across all sorts of project operations. This is what the dependency graph actually looks like. Not a flat list of folders in Node modules, but likely a cyclical graph. In this case, my app depends on Express, React, and TypeScript. Express depends on BodyParser, XSAP, and so on and so on. And when we zoom in, we realize that every node carries its full metadata, security, relationships, everything should be queryable. And here's what lives inside each node. Not just the name of the version, but also integrity hashes, published dates, author information, security details. When you keep the graph, all of this metadata is queryable. You can ask, show me all packages published before a certain date or show me everything by a specific author, because it's all right there in the graph. Here, I wanted to introduce this concept of the dependency selector syntax, which is something that we've been using for a long time. Here, I wanted to introduce this concept of the dependency selector syntax. We call it DSS for short. It's based on CSS selectors, and it helps us answer complex questions about dependencies, their relationship, and metadata. You can see how it fits very well with the CSS model. Let's start with some concrete examples. It's easier to visualize. Starting here with the star operator is just selecting all the nodes in the graph.

In this case, they're all selected, so everything is yellow here. You can see how this graph is the connections between each node, which is the dependency declaration from each one of these packages, and the realization of that package, which is each node that we are seeing colored yellow here. To show a little bit more what this dependency selector syntax looks like, let me start with some examples of some other useful selectors. In this example here, we're looking at common root. It's basically the selector that allows you to select the root of the project. Moving on to this one here, we're starting to combine different parts of the syntax together to form a more complex selector to query the graph. In this case, we're using common workspace and then little arrow and star, which basically what we're doing here is that we're selecting the direct dependencies of workspaces. This syntax should feel very natural for folks used with CSS syntax, so this is basically what's going on here. Starting from workspace, give me the direct dependencies. It can be anything. It's just a star, right? We can see that, in this diagram here, we have only the items at the bottom colored yellow because they have been selected, and we can see their parents. We can see how they connect all the way to the root of the project.

Here, in this example, we're going to select a specific dependency by name, so we're using pound and the name of the dependency. In this case, we're using pound is exe, and we can see the node at the bottom and all its ancestors until the root of the project. In this case, exe is a direct dependency of which, which is a dependency of my server workspace. Select direct dependencies of workspace and root. In this example, we're going to combine these two previous examples we've seen before, but we're using a comma to separate and basically get the results of both selectors at the same time. In this example here, you can see we see all the direct dependencies of the workspaces are highlighted, and we're also including exe at the bottom there as a dependency of which because it has been selected directly by its name. In this case, we're seeing here the workspace client and the workspace server. They're being combined using the is selector, and we're getting the direct dependencies of these workspaces. So, you can see here in the resulting diagram, we end up just with just server and client workspaces, and at the bottom we can see their dependencies. And there are also security insights-based selectors that allows us to filter based on security metadata provided by Socket. And in this case here, we're using the score, the score selector, that scores basically metadata and aggregate of different data points that Socket collects. And in my example here, I want to put the bar high in my project, I want to know what package inside my project has a score under 80. And in this case here, I got this English Days package that is being highlighted as a direct dependency of the client workspace. So, this way I can filter based on all this security metadata that is provided by Socket. And here at the side, we can see a little bit of what that data looks like. In this example, I'm using the not selector to kind of just deny the selector that is inside of it. So, in this example, I want to get all the packets in my project that are not licensed MIT. So, it's returning to me my root, node, and all the workspaces because those don't have any license at all, but it's also picking up anything that's using a license other than MIT.

Like, I know, for example, Prev, Wedge, all of these are using the ISC default license from NPM. In this example, I'm selecting packets by the author name. So, in this example, I would select all packets that depend on Ruiz packages. It's combining a few more selectors at the same place. You can see I'm using this name, start with Ruiz, that's an attribute selector. This allows me to select on properties of the package JSON file of each dependency. Basically selecting on the author name starting with Ruiz to get any package containing the author name Ruiz. The result is that the workspace server contains a dependency published by an author named Ruiz.

There are more selectors to work with, and this Dependency Selector Syntax (DSS) is how we interact with the graph. Around 60 pseudo selectors cover dependency type, security, and more, along with attribute selectors for infinite combinations. It enables filtering by name, version, publish date, author, license, and more. The query language integrates with VLT client commands. For instance, querying star in the terminal provides results similar to diagrams and allows for package.json file property updates using the Pkg command to add new dependencies like VTest to workspaces.

Running commands across workspaces with VLT client tools such as VLX and VLR enables tasks like listing files, adding test files, and running tests in each workspace. The command scope workspace is used to target specific workspaces for actions like adding test files or running specific tests. Query language basics are showcased in practical commands like version patching for all workspaces using the workspace selector. These examples illustrate how the query language seamlessly integrates with various VLT client commands and operations.

Yes, and you can see that the scripts now for every one of the workspaces have tests pointing to VTest index test. So, running a VLT install here and now I can actually query for that new edit dependency. So, you can see that VTest has been highlighted here in the results for every single one of the workspaces to which it got added to.

In this other example, we'll start with listing files in my workspaces. So, you can see that the client server and the tools workspace have only a package.json file inside it. And I'm going to use VLX to just run a command across all the workspaces again. So, I'm using scope workspace, and I'm going to just touch that test file to add that test to each one of the workspaces. So, now I can run again the same command, and I can list and see that those files have been added. The workspaces now have the index test JS file in them.

Next example here, I'm going to run VLR, which is a shortcut for VLT run, and I'm going to use scope workspace again and run tests. And you can see that I successfully ran VTest in every one of the workspaces. And this final example here, to just highlight the usage of the query in this sort of basic commands, I'm going to use like version. And I'm going to basically patch version for all my workspaces using again the column workspace selector. So, you can see that every one of my workspaces now has bumped their version to 1.0.1 and has a new commit and tag, same as you would expect from the version command.

From the version command. So, now let's move on to showcase just a little bit some of the more advanced features of the VLT client. And let's start with face package installs. So, every time you run an install, you're executing arbitrary code from potentially thousands of packets and package authors. So, when you install scripts that were running automatically with full access to your system, before you have even a chance to review what's been installed, it can be risky, right? So, this trust by default model has been a security blind spot for years. And we kind of trying to rethink that here.

So, VLT introduced two distinct phases. Phase one, VLT install downloads and extracts packages into node modules, but no lifecycle scripts execute. And in phase two, VLT builds selected run scripts using the dependency selector syntax for targeting. This means you can inspect your dependency graph, check for security issues, and decide what to build before any code runs. By default, all install scripts are blocked. Here are some examples for what you can do. And here's where DSS really shines in the build phase. You can target exactly which dependencies are allowed to run scripts, by name, by scope, or using any DSS selector.

Let's run another example here. This time, we're going to query and let's see what packages have not been built in this project. And I can see, oh, I can see ES build and FS events have not. FS event is showing twice, but it's just a single package. So, you can see that when I run vote build here, two packages have been successfully built. And now when I run script not build, I get nothing. And when I run vote query scripts build, once again, I'll see the same packages in the beginning, but now they're built. Querying multiple projects. To expand more the capacity of the DSS query language, there is also the possibility of filtering packages across multiple projects by using the host local selector.

Querying multiple projects. To expand more the capacity of the DSS query language, there is also the possibility of filtering packages across multiple projects by using the host local selector. Let's take a look at it. So, the host local, when you prefix your query with that, it allows you to change the context from that query to not only target the current project, but all configured projects in your system. You can configure all the projects, what folders you want to recognize, nested folders as projects that can be managed like that. So, the host local selector basically expands the query language to more than a single project. And we have some examples here, like, what if you want to make yourself the question, do I have any malware? Do I have packages that have been later on documented as malware installed on my machine? It's possible to know by running vote query using host local malware. What if I just want to change the author in multiple local projects? It's possible to do that running vote scope using the host local. And I'm pointing to the root project because I just want to change the package json of my root to set my name on them using pkg set author name.

Here another demo on using host local. So, let's vote query host local here and find all packages that I have that have scripts defined on them. So, you can see I have a lot. I have many projects configured in this environment. So, I'm going to go ahead. And out of curiosity, I want to take a look. I want to inspect what these scripts look like. So, I'm going to use that same query as a scope here and I'm going to use pkg pick. And I'm going to pick the name so that I can know what package I'm looking at. And I'm going to select install, post install, prepare. So, I can see what's actually in these packages, what's actually in these scripts for each one of these packages.

To sum up, one last thing. And this is increasingly relevant. AI agents will benefit enormously from this approach. When the dependency graph is a consolidated queryable artifact, agents get structured data instead of crawling thousands of files in your node modules folder. They get machine-readable output from every query. And they get rich security, the data, relationship, everything in a single source. So, it's going to be less data to fetch, less searching, and faster results. I want to remind you all that the graph is there. VLT is just helping you work with that. And if you're interested, please follow these links to learn more about the project and give it a try. Thank you very much. See you.