Skip to content

Upgrade pnpm from 11.5.2 to 12.x (in step with OHIF) #2897

Description

@wayfarer3130

Context

OHIF is upgrading from pnpm@11.5.2 to pnpm 12.x. cornerstone3D pins the same version, and the two repos' pnpm setups are intentionally coupled:

  • package.json:192"packageManager": "pnpm@11.5.2", engines: { node: ">=24", pnpm: ">=11.5.2" }
  • OHIF's own pnpm-workspace.yaml carries the comment "Mirror the cornerstone3D pnpm setup (libs/@cornerstonejs) which is known-good" — the two files share nodeLinker: hoisted, strictPeerDependencies: false, linkWorkspacePackages, preferWorkspacePackages, minimumReleaseAge: 2880, frozenLockfile: true, allowBuilds, and a large overrides block.
  • OHIF developers check cornerstone3D out into libs/@cornerstonejs and run it through OHIF scripts (cs3d:install, cs3d:build, cs3d:link, cs3d:watch), which link cornerstone3D's node_modules into the OHIF workspace. A pnpm major mismatch across that boundary is exactly where the hoisted-layout linking breaks.

So cornerstone3D should move to pnpm 12 in step, not after.

pnpm 12 changes that touch this repo

From the v12.0.0 release notes:

  1. pnpm-workspace.yaml may no longer carry an unrecognized setting. It now fails with ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS when the project pins a pnpm version the running pnpm satisfies — which this repo does via packageManager. Every non-packages key needs validating: nodeLinker, strictPeerDependencies, linkWorkspacePackages, preferWorkspacePackages, minimumReleaseAge, frozenLockfile, allowBuilds, overrides. pnpm config list / pnpm config get <key> never fail on a broken file, so a pnpm@12 binary can audit the file before anything is switched over.
  2. Canonical cycle breaking during peer resolution. The lockfile becomes a pure function of the dependency graph. Frozen installs consume the existing lockfile unchanged, but the first install that re-resolves re-keys walk-order-dependent peer variants once — so the lockfile regen should be a deliberate, separately-reviewed commit rather than surprise churn in an unrelated PR. The notes report 2–3× faster peer resolution and ~25% less memory on cycle-heavy workspaces, plus a smaller lockfile; worth measuring here given the package count.
  3. packageImportMethod: auto now tries hardlinks before cloning on Linux, and the default store falls back to <project>/node_modules/.pnpm-store when no directory above the project accepts a hard link. Relevant to CI runners and to the OHIF libs/@cornerstonejs layout, where cornerstone3D's store and the OHIF workspace may sit on different filesystems.
  4. Git dependencies on known hosts resolve through the canonical HTTPS URL and the lockfile never records an SSH URL for them.
  5. sudo now fails for pnpm's own global-modifying commands (ERR_PNPM_SUDO_NOT_SUPPORTED).

Work

  • Bump packageManager to the same exact 12.x version OHIF picks, and engines.pnpm to >=12
  • Validate pnpm-workspace.yaml against pnpm 12's recognized settings (see 1 above)
  • Bump pnpm/action-setup@v6.0.8 where it appears — .github/workflows/build-docs.yml:31, docusaurus-build.yml:26, format-check.yml:23, test.yml:16, validate-codemod-registry.yml:27, validate-packaging.yml:26,66 — and confirm v6.0.8 handles pnpm 12 before assuming a version bump is unnecessary
  • The Corepack-based workflows (playwright.yml:42, ohif-downstream.yml:79) follow the pin automatically, but need a green run to confirm
  • Regenerate pnpm-lock.yaml as its own commit; verify a second regen is a no-op diff
  • Verify pnpm install --frozen-lockfile, the build, and the Playwright suite
  • Coordinate with OHIF so cs3d:install / cs3d:link are exercised with both repos on pnpm 12

Sequencing

ohif-downstream.yml already runs OHIF against this repo, so whichever repo bumps first will exercise the mismatch. Preferably: validate the workspace settings in both repos, then bump both pins close together, then regenerate both lockfiles.

This lands as a single PR, paired with the OHIF one: OHIF/Viewers#6247

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions