[entelecheia]

Closes #185.

What changed

File	Change
package.json	packageManager is now pnpm@12.18.0+sha512.9d7882d...63beb3; engines.pnpm is >=12 rather than >=10
pnpm-workspace.yaml	onlyBuiltDependencies: [esbuild] becomes allowBuilds: {esbuild: true}; minimumReleaseAge: 1440 is set explicitly
pnpm-lock.yaml	158 added lines: pnpm 12's own env document (see below). No existing entry changed
README.md	"Requires Node >= 22 and pnpm 12."
scripts/smoke-consumer.mjs	the --filter comment re-tested and rewritten (see below)

Version and source. pnpm 12.18.0, from the registry's latest dist-tag (curl https://registry.npmjs.org/pnpm: latest = latest-12 = 12.18.0, published 2026-11-05T00:56Z; next-12 = 12.21.0, so 12.19.0 to 12.21.0 exist only on the next channel). The digest is the tarball's dist.integrity base64 decoded to hex, the form corepack and packageManager use.

pnpm/action-setup needs no bump. The five steps stay pinned to 73e46992 (v6.1.1); v6.1.0's release note is feat: support pnpm v12 (pnpm/action-setup#288), and none of the steps carries a version: input, so they follow packageManager.

engines.pnpm moved to >=12 as a policy floor rather than a compatibility one. pnpm 10.26.0 already added allowBuilds (its release note: "Added support for allowBuilds, which is a new field that can be used instead of onlyBuiltDependencies and ignoredBuiltDependencies"), so 10.34.5 understands this map; what differs is the default on an unlisted script, which 10 skips with a warning and 12 fails (ERR_PNPM_IGNORED_BUILDS), as the issue's own Context section states. The floor names the major whose defaults the workspace is now written and tested against, and the one pnpm major this family is moving to. (This paragraph said earlier that pnpm 10 could not read the field; the reviewer caught it.)

allowBuilds, entry by entry (AC2)

Entry	Value	Why
esbuild	true	The one package pnpm 12 reported as ignored (ERR_PNPM_IGNORED_BUILDS: Ignored build scripts: esbuild@0.28.2). tsup builds every package through it and vitest transforms through it, so its postinstall has to run. Verified: node_modules/.pnpm/esbuild@0.28.2/node_modules/esbuild/bin/esbuild --version prints 0.28.2.

No false entries. sharp@0.35.5 is installed (an optional dependency of next) and appears in no ignored-builds report, because 0.35 ships its binaries as optional dependencies and declares no install script, so it gets no entry at all. The evidence is node_modules/.modules.yaml after a clean install: ignoredBuilds is absent entirely.

strictDepBuilds keeps its default (true), so the next dependency that arrives with an unreviewed build script fails the install rather than being skipped silently.

AC6, stated plainly: the lockfile diff is not format-only

pnpm 12 records the version it ran as packageManagerDependencies in a second YAML document at the top of pnpm-lock.yaml (pnpm 11.0.0 release notes, pnpm/pnpm#10912: "the env lockfile section also stores packageManagerDependencies resolved during version switching and self-update"). A frozen install of a lockfile without that document fails:

ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE
  resolve package manager dependencies
  Cannot update packageManagerDependencies with "frozen-lockfile" because the lockfile is not up to date

So AC1 and a literally format-only lockfile cannot both hold, and AC1 wins. What the diff actually is:

• 169 insertions, 7 deletions across five files; in pnpm-lock.yaml alone 158 insertions, 0 deletions.
• The previous lockfile is contained in the new one byte for byte: old in new is true, at offset 4604, with 0 trailing bytes, so every existing entry (including every resolved version) is untouched. The added document holds the pnpm CLI and its @pnpm/exe.* platform builds, not a dependency.
• No dependency version changed: git diff touches no resolution: or version: line of the original document.

If the owner would rather not carry the second document, the lever is to drop the packageManager pin and let CI install pnpm itself, which trades away the single-source decision in the issue. managePackageManagerVersions: false is not an option: pnpm 12 removed that setting (pnpm 11.0.0 notes) and refuses it as unrecognized.

The --filter comment in scripts/smoke-consumer.mjs

The old comment said pnpm 10 rejects pack through a recursive --filter selector. That no longer holds on the new major: pnpm --filter @hwp-editor/core pack --pack-destination <dir> on 12.18.0 ran prepack and wrote hwp-editor-core-1.4.2.tgz. The code is unchanged (packing each package from its own directory still does the same thing and keeps the load-bearing order explicit), and the comment now says so instead of naming a behavior that is gone.

Local configuration

pnpm 12 reads a user-level .npmrc only for auth, registry, TLS and proxy settings, so this machine's user-level virtual-store-dir no longer applies. The install fell back on its own to node_modules/.pnpm and ~/Library/pnpm/store/v11; no per-command override was needed, and no global or user pnpm config was edited.

Checks

• AC1: rm -rf node_modules apps/*/node_modules packages/*/node_modules && pnpm install --frozen-lockfile exits 0 and prints no ignored-builds output (Done in 495ms using pnpm v12.18.0).
• pnpm --version reports 12.18.0 from the pin, and pnpm config list shows allowBuilds and minimumReleaseAge: 1440 read out of pnpm-workspace.yaml.
• pnpm -r build: all five projects, playground next build included.
• pnpm -r typecheck: clean.
• pnpm -r test: core 791 tests in 22 files, react 719 in 26, server 550 in 27 (2,060 tests, 75 files), all passing.
• AC5: git grep -e "pnpm 10" -e "pnpm@10" -e "10\.34\.5" finds nothing outside history.
• AC3: this PR's ci.yml and e2e.yml runs are the report.
• AC4: not checkable here. release.yml needs no change because it reads packageManager like CI does; the first release after this merges is the check, and this PR does not tag or release.

Heavy commands ran through dot admit (one heavy job per repo).

[chatgpt-codex-connector]

Codex Review Summary: ❌ Failed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	❌ Failed 2026-11-14T07:53:17.688865Z We couldn’t complete this review. Comment @codex review to try again.	fcb488c	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[entelecheia]

Owner confirmed allowBuilds esbuild: true (its install script fetches the platform binary that the build and test tools use) and accepted the lockfile deviation (pnpm 12's packageManagerDependencies document; no resolved versions changed). AC4 will be checked in the next release's log.