Current Behavior

When using the @nx/js:prune-lockfile executor in a workspace that uses catalog: references (pnpm or yarn), the emitted dist/package.json still contains the raw catalog: specifiers:

{
  "dependencies": {
    "@nestjs/common": "catalog:",
    "zod": "catalog:"
  }
}

The emitted dist/pnpm-lock.yaml correctly contains resolved versions (e.g. ^11.0.0), because the lockfile path already resolves catalog references internally via getCatalogManager().resolveCatalogReference().

The mismatch causes pnpm install --frozen-lockfile to fail with ERR_PNPM_OUTDATED_LOCKFILE:

ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json

  Failure reason:
  specifiers in the lockfile don't match specifiers in package.json:
* dependencies are mismatched:
  - @nestjs/common (lockfile: ^11.0.0, manifest: catalog:)
  - zod (lockfile: ^4.3.6, manifest: catalog:)

Expected Behavior

The emitted dist/package.json has catalog: references resolved to real version strings, matching what the pruned lockfile already contains, so pnpm install --frozen-lockfile succeeds.

Implementation Details

Adds a pure resolveCatalogReferences() helper in the prune-lockfile executor that runs after the project's package.json is read and before the lockfile is generated. It uses the existing getCatalogManager() utility (exposed via @nx/devkit/internal) and resolves catalog references across dependencies, optionalDependencies, devDependencies, and peerDependencies — mirroring how pnpm-parser.ts handles them when producing the lockfile.

• No-op for package managers without catalog support (npm/bun).
• Works for both pnpm and yarn Berry catalogs.
• Throws on unresolvable references, matching the lockfile path's behavior.

Related Issue(s)

Fixes #35419

View session information ↗