[daniel-freiermuth]

deps: upgrade pnpm from 11.3.0 to 12.9.1

What improved

pnpm moves from 11.3.0 to 12.9.1, the current latest dist-tag, in CI, deploy, and the packageManager pin.

Why it's worth doing

• 11.3.0 is 50+ releases behind the v11 line (latest-11 is 11.28.2), and v12 is now latest.
• pnpm 12 builds the lockfile the same way every time (canonical peer-cycle breaking) and stops writing machine-specific SSH URLs for git dependencies.
• pnpm 12 also fails on unrecognized pnpm-workspace.yaml settings when the pinned version matches, so a misspelled setting can't be dropped silently. Release notes: https://github.com/pnpm/pnpm/releases/tag/v12.0.0

What changed

• .github/workflows/ci.yml (lint + test jobs) and .github/workflows/deploy.yml:
  • pnpm/action-setup@v4 → pnpm/action-setup@v6.1.0
  • version: '11.3.0' → '12.9.1'
  • Why this exact tag: pnpm 12 ships as a native binary through @pnpm/exe.* optional dependencies, and action-setup only gained pnpm v12 support in v6.1.0 (feat: support pnpm v12 pnpm/action-setup#288). The floating v6 tag still points at v6.0.10 (git ls-remote: v6 → annotated tag object for commit 0977fd9, which is the v6.0.10 commit; v6.1.0 → ea17c68). A comment in the workflows records this.
• app/package.json: "packageManager": "pnpm@12.9.1".
• app/pnpm-lock.yaml: pnpm 12 adds a leading YAML document that records the pinned package manager (packageManagerDependencies: pnpm 12.9.1 plus the integrity hashes of the @pnpm/exe.* platform binaries). The main lockfile document, starting at lockfileVersion: '9.0', is byte-for-byte unchanged, so no dependency was re-resolved.
• Local patches: app/patches/@deck.gl__core.patch (via patchedDependencies) still applies unchanged under pnpm 12.

Verification (run locally with pnpm 12.9.1 from npm, Node 24.21.0)

• cd app && rm -rf node_modules && pnpm install --frozen-lockfile: succeeded ("Done in 4.3s using pnpm v12.9.1"). The only lockfile change was the env document above. A second frozen install left the lockfile byte-identical (checked with cmp).
• The patch was applied: the installed path is node_modules/.pnpm/@deck.gl+core@9.4.0_patch_hash=8a96…/, and its dist/dist.dev.js contains the patched float opacity; line.
• No ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS: allowBuilds and patchedDependencies are both accepted. The only warning was local (the store is on a different filesystem from this checkout); no deprecation warnings.
• wasm-pack build crates/core --target web --dev, then:
  • pnpm exec svelte-check --tsconfig tsconfig.json: 0 errors, 0 warnings
  • pnpm exec eslint src: clean
  • pnpm test: 21 files / 207 tests passed
  • pnpm run build: succeeded (PWA service worker generated)
• cd e2e && pnpm install --frozen-lockfile: succeeded with e2e/pnpm-lock.yaml unchanged (no packageManager pin there).
• pnpm store path --silent, which actions/setup-node's cache: pnpm uses, works under pnpm 12.
• Both workflow files parse as YAML.
• Not verified locally: running the GitHub Actions workflows with pnpm/action-setup@v6.1.0. The first CI run of this PR is the check for that.

What I deliberately did NOT change

• I pinned pnpm/action-setup to the exact v6.1.0 tag. Once the floating v6 tag is moved to v6.1.0 or later, the three pnpm/action-setup@v6.1.0 references (ci.yml lint and test jobs, deploy.yml) can go back to @v6 if floating tags are preferred.
• I did not migrate packageManager to devEngines.packageManager, and I did not adopt pnpm 12 opt-in features (globalShims, remoteSideEffectsCache).
• The other actions in the workflows (actions/checkout@v4, actions/setup-node@v4, Node 22) are out of scope and unchanged.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: c65720bb-608a-43c7-ba86-3ec55609c951

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[daniel-freiermuth]

The red Lint check is not caused by this PR. main fails the same way, and I made no commits for it.

• The failing step is cargo clippy (run 37348496007). Under the stable toolchain from dtolnay/rust-toolchain@stable, which is now Rust 1.99 (clippy's help links point at rust-1.99.0), the clippy::assert_is_empty lint flags 6 assert!(x.is_empty()) calls in crates/core/src/geo.rs (lines 1318, 1319, 1322, 1329, 1429, 1430). -D warnings turns those into errors.
• main at ee0f199 fails the same Lint job with the same 6 errors at the same lines (run 37106431132, 2026-10-03). The run before it on main (35744668158) passed. This PR changes only .github/workflows/{ci,deploy}.yml, app/package.json and app/pnpm-lock.yaml, and no Rust code.
• The pnpm 12 changes worked in CI. In both jobs, Set up pnpm (pnpm/action-setup@v6.1.0), Set up Node.js (cache: pnpm) and Install frontend dependencies (pnpm install --frozen-lockfile) passed. The Test job passed in full, including vitest. Because the Lint job stopped at clippy, svelte-check and ESLint were skipped. Both are clean locally under pnpm 12.9.1 (see the PR description).

I'm keeping the clippy fix out of this pnpm bump. It's a Rust test-code change that main needs either way, and if it also landed here, this PR and the fix on main would conflict. Once main has that fix, rebasing this PR onto it should turn Lint green, with svelte-check and ESLint running under pnpm 12 in CI.