vlt v1.6.2 to v1.6.4: faster cold installs and clearer workspace runs

vlt v1.6.4 is out, the third small release in a row, so this post covers v1.6.2, v1.6.3 and v1.6.4 together. Let's start with the performance work that shipped in v1.6.2. Since that release, vlt install unpacks tarballs on a pool of worker threads: inflating, parsing the tar stream and writing the files all happen off the main thread, which stays free to read registry responses and build the dependency graph. A tarball that is already in the cache is read by the worker itself, so the main thread never copies it, and a warm install, where the global store already holds every package, starts no worker at all. The nightly package manager benchmarks picked it up the day v1.6.2 shipped. Cold installs, the scenarios that download and unpack every package, are where it shows:

The other highlight, from v1.6.3, is the output of workspace runs. vlt run and vlt exec across workspaces (-r, -w, --workspace-group or --scope) used to print a bare <workspace-path> ok per workspace, or a failure { status: 1 } block, with no timings and no total. They now print an aligned status line per workspace, with the script name and how long it took, and a summary at the end. A script's own output still goes above its status line on success and below it on failure. With --no-bail, the summary counts the failures, and the exit code is now set in every view: it used to be 0 under --view=json, the default when stdout is piped, so a failing vlt run test -r --no-bail could pass unnoticed. Here is an example of what this new output looks like:

$ vlt run build -r
packages/shared          ✓ build (443ms)
packages/config          ✓ build (1.1s)
packages/user-interface  ✓ build (236ms)

3 tasks · 1.8s total

$ vlt run test -r --no-bail
packages/shared          ✓ test (58ms)
packages/config          ✗ test (39ms)  exit code 3
Error: expected 2 to equal 3
packages/user-interface  ✓ test (538ms)

3 tasks · 1 failed · 637ms total

Other changes

• One round trip less on cold installs from vlt.io (v1.6.4). A registry that serves the vlt extensions, like the vlt.io registry, advertises them in a capabilities document, and the server-side resolve request used to wait for that document before it went out, a full round trip on every clean install. Both are now sent together, and a registry already known not to serve resolve is not asked at all. The ?stable packument filter is likewise only requested once the registry confirms it serves it, so a registry that doesn't know the filter keeps getting the plain packument URL its CDN already caches.
• vlt build saves allow-scripts. vlt build [<query>] now sets, saves and applies the project's allow-scripts query, the way vlt skills link handles allow-skills: the query is built and, once the build succeeds, saved to the project vlt.json, and in a terminal vlt build asks before it replaces or edits a stored query (-y skips the prompts). Since the saved query is the one vlt install and vlt ci read, a fresh clone runs the scripts you allowed without a separate vlt build step, and vlt install --allow-scripts=<query> and vlt update save it too. The default query is still :scripts:not(:built):not(:malware), a bare vlt build outside a terminal builds it without saving anything, and --target works as before and is never saved.
• Query views draw every path to a selection. The human, mermaid, SVG and PNG views of vlt query and vlt ls dropped some of the paths from the project to the selected packages when a dependency had more than one parent: vlt query '#ms' showed debug > ms but not agent-base > debug > ms. Every path is drawn now.
• A bare workspace add saves workspace:*. vlt install b, with b a workspace, wrote "b": "" to package.json while the lockfile edge got *, so --frozen-lockfile failed from then on. A range-less add that resolves to a workspace now saves workspace:* to package.json and the lockfile, the same as vlt install b@workspace:*. Explicit ranges are kept as given.
• vlt install keeps workspace: dependencies it can't resolve. A workspace: dependency that matched no workspace, because of a typo, a deleted folder or a workspaces glob that matched nothing, was silently removed from package.json by the next vlt install, which exited 0. It now fails with the usual no workspace found matching … error and leaves package.json alone, and an alias such as "f": "workspace:@x/foo@*" resolves against the workspace it names. vlt uninstall of a dependency whose workspace folder is gone still works. Thanks to @drawliin for the fix.

Try it

You can find every patch note in the GitHub releases. To install or update vlt, run:

curl -fsSL https://install.vlt.sh | bash

Already on vlt? Run vlt install -g vlt to update.