NewsJavaScriptDeveloper Tools

pnpm 12.12 + vlt 1.4: Faster JavaScript Installs Now

Abstract visualization of fast JavaScript package installation with blue data streams and distributed server nodes
pnpm 12.12 adds remote build cache

Two JavaScript package managers shipped meaningful upgrades this week. pnpm 12.12 can now share compiled build artifacts — native addons, postinstall results, pipeline task outputs — across every CI runner in your organization using the Turborepo Remote Cache API. vlt 1.4 drops warm macOS reinstalls from 9.6 seconds to 3.1 seconds using APFS copy-on-write. Neither release is noise. If you run a monorepo of any size, at least one of these is worth upgrading for today.

pnpm 12.12: Your CI Runners Can Now Share Build Results

The headline feature is a new remoteCache setting in pnpm-workspace.yaml. It covers two distinct caches that both plague CI:

  • Pipeline task results via pnpm pipeline — build output shared across runners
  • Dependency side-effect builds via sideEffectsCache — native addons and packages with postinstall scripts, pre-built once and reused everywhere

If you have a native addon that takes 30 seconds to compile — esbuild, sharp, canvas, sqlite3 — every CI runner currently builds it from scratch on a cold install. With sideEffectsCache.remote, one runner builds it, uploads a signed artifact, and every other runner restores it. The protocol is the Turborepo Remote Cache API, which means Vercel Remote Cache and self-hosted implementations already work without any new infrastructure.

A minimal configuration looks like this:

# pnpm-workspace.yaml
remoteCache:
  org: acme
sideEffectsCache:
  remote:
    packages:
      - native-addon
      - sharp

Signing keys — the private key, trusted keys, key ID — must live in your global pnpm config or CI environment variables. pnpm deliberately refuses them in pnpm-workspace.yaml. This is the right call. A workspace file gets checked in; your signing keys should not.

How does the cache layer work in practice? The remote tier only ever adds to your local cache. Restores still check local entries first. Uploads happen in the background and the pipeline waits for them at the end of a run, not during. You do not take an upload tax on your critical path.

This builds on top of pnpm 12’s Rust rewrite, which already cut installs 64 to 90 percent versus pnpm 10 on Vercel’s 21-project, 1,670-package monorepo. The remote cache is the layer that multiplies those gains across machines.

pnpm 12.13 and 12.14: Two Fixes Worth Knowing

Alongside 12.12, the team shipped 12.13 and 12.14 in quick succession. The two to flag:

storeIndexFormat: files (12.13) — if your team shares a pnpm store over NFS or a network filesystem, set this now. SQLite locking does not work across machines; concurrent installs were silently corrupting index.db. The file-per-package format avoids the lock entirely.

sideEffectsCache.exclude (12.14) — a necessary escape hatch. If a native addon links against host system libraries (a specific version of libssl, for example), a cached artifact from your Ubuntu CI runner will silently break on an Alpine container. List those packages in exclude and pnpm always rebuilds them locally, never touches the remote cache.

vlt 1.4: macOS Gets APFS Copy-on-Write

vlt — the package manager from npm’s original creator — shipped 1.4 on October 13 with the global store enabled by default on macOS. The mechanism is clonefile via node:ffi, which means instead of copying file bytes from the global store to your project’s node_modules, vlt creates an APFS clone: an instant copy-on-write reference that shares blocks with the source until something modifies a file.

For warm reinstalls — which is every install after the first one — this is effectively zero IO. The result: 9.6 seconds drops to 3.1 seconds. A 68 percent improvement on a warm reinstall is not a micro-optimization.

The catch: clonefile requires Node 26.1 or later for the node:ffi bridge. If you are on Node 22 or 24 LTS, vlt 1.4 installs fine but falls back to regular copies. Node 26 goes LTS on October 28 — nine days from now. The upgrade path is clear.

Two smaller additions in 1.4 are worth using immediately regardless of Node version:

  • vlt add react --save-types — automatically adds @types/react to devDependencies. TypeScript developers have been doing this manually for a decade.
  • vlt outdated --json — output now includes the install command per package, making it trivial to pipe into update scripts or Renovate configurations.

What To Do This Week

If you are on pnpm and run a monorepo:

  1. Upgrade to pnpm 12.14: corepack use pnpm@latest
  2. Add remoteCache.org to your pnpm-workspace.yaml
  3. Point it at Vercel Remote Cache or spin up pnpr
  4. Add native addons to sideEffectsCache.remote.packages
  5. If sharing a pnpm store over NFS, add storeIndexFormat: files

If you are on vlt: upgrade to 1.4 now (npm i -g vlt@latest). Plan your Node 26 move around the October 28 LTS date to unlock the clonefile optimization.

The Bottom Line

pnpm’s remote cache is not a convenience feature. On a monorepo with native addons, it removes a recurring CI tax that every developer on the team pays, invisibly, on every PR. If you are still rebuilding esbuild or sharp from source on cold CI starts, that stops with a six-line config change. For vlt, the clonefile optimization is legitimately impressive — but it is gated on Node 26. If you are already on the upgrade path, now is the right time to move to vlt 1.4 and capture the gain when LTS lands.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *

    More in:News