pnpm 11.23.0

I upgraded pnpm to 11.23.0 so you don't have to — verdict: worth the five minutes.

The headline: pnpm config actually makes sense now

The most visible change in 11.23.0 is how pnpm reports configuration. Before this release, pnpm config get registries just printed undefined — nobody was quite sure what it meant. That is fixed. The command now shows the registries pnpm actually resolves from, merged across every source (.npmrc, pnpm-workspace.yaml, the global config, and CLI flags), keyed by registry URL with the default registry declared as the bare @ scope. Built-in routes like the @jsr scope and the npmjs/gh prefixes show up too.

The same cleanup lands for update, audit, and catalogs. pnpm now shows the effective sections regardless of which spelling set them. The deprecated internal names — updateConfig, auditConfig, auditLevel — stop cluttering the output.

Smaller fixes that matter

• pnpm config get <key> and pnpm get <key> no longer print config-load warnings, so scripts that capture the value get the value alone.
• Unrecognized and non-camelCase settings in a project's pnpm-workspace.yaml, previously ignored silently, are now reported the same way unknown global settings are.
• The importPackage pnpmfile hook is deprecated. pnpm prints a warning when a pnpmfile defines it, opts that install out of the parallel package importer (slower), and the hook is removed in the next major version.
• node_modules/.modules.yaml no longer records the registries an install resolved from — a leftover from an old lockfile format that outlived its purpose.

The one that caught my eye: virtual store plus ESM

When enableGlobalVirtualStore is on, every process pnpm spawns (pnpm run, pnpm exec, lifecycle scripts) now receives a NODE_PATH pointing at the project’s hoisted node_modules plus a NODE_OPTIONS --import flag that registers a resolve hook. Phantom (undeclared) dependencies keep resolving under the global virtual store for both CommonJS and ESM — without the @pnpm/plugin-esm-node-path helper.

Registries that carry timestamps

There is a nuanced performance win too: a registry can now declare that its abbreviated metadata carries the time field. With resolutionMode: time-based, only registries that need it fall back to the full metadata document — so private registries with supportsTimeField: true skip the big download entirely.

Worth it? The config-output cleanup alone is worth the upgrade, and nothing here is a hard break. Update when you are ready.