You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
build(deps): standardize on pnpm 11 and build Docker image from repo root (#376)
* build(deps): standardize on pnpm 11 with config in pnpm-workspace.yaml
Nothing pinned the pnpm version, so local/Docker ran pnpm 11 while CI pinned pnpm 9. pnpm 11 no longer reads the 'pnpm' field in package.json, so every local install silently stripped the overrides block from the lockfile and mismatched CI's pnpm 9 — forcing a manual re-gen that must not be committed.
Pin packageManager to pnpm@11.5.0 (corepack/CI/Docker now agree) and move overrides, onlyBuiltDependencies, and minimumReleaseAge out of package.json#pnpm into pnpm-workspace.yaml — overrides: stays a map, onlyBuiltDependencies becomes the allowBuilds map, minimumReleaseAge: 0 replaces the env workaround. CI workflows drop the hardcoded 'version: 9' so pnpm/action-setup follows packageManager.
The lockfile is byte-identical after the move, confirming the churn was purely the misplaced config; a frozen install is now stable and the full suite passes under pnpm 11.
* build(docker): build testplanit image from repo root, drop duplicate lockfile
The testplanit image now builds from the repository root so it uses the single
root pnpm-lock.yaml + pnpm-workspace.yaml directly, eliminating the committed
testplanit/pnpm-lock.yaml duplicate that had to be hand-mirrored on every
install. Combined with the pnpm 11 packageManager pin, this ends the recurring
re-gen/don't-commit churn.
- docker-bake.hcl: context "..", dockerfile "testplanit/Dockerfile"
- Dockerfile: pnpm workspace install at /app with the app at /app/testplanit;
pnpm provisioned via corepack; production deps via `pnpm deploy --prod
--legacy` for a self-contained node_modules; the generated Prisma client and
ZenStack files are copied into the deploy tree by locating them there, since
the prod peer-hash dir name differs from the build tree
- .dockerignore (new): keeps the root context small; artifact patterns are
anchored to real locations so a floating glob can't strip a source route such
as app/api/test-results (only reached via dynamic fetch, so the build would
not have failed -- it would just 404 at runtime)
- docker-compose{,.dev,.prod}.yml: context "..", working_dir/volumes shifted to
/app/testplanit
- release.yml: drop the 4 `cp pnpm-lock.yaml testplanit/...` steps; add
--allow=fs.read=.. to the bake calls (buildx parent-context entitlement)
- ci.yml: drop the obsolete lockfile-mirror diff; the install gate now uses
--frozen-lockfile to fail fast on root-lockfile drift
- docs: manual-setup notes pnpm 11 via corepack/packageManager
Validated locally on Colima (linux/arm64): `docker buildx bake production
workers` builds both images; the production image boots and serves; the workers
smoke test loads all 16 entrypoints; the test-results route compiles into the
standalone; and the security overrides are present in the built tree.
-[pnpm](https://pnpm.io/)v11 — the repository pins the exact version via the `packageManager` field in the root `package.json`, so the simplest setup is to run `corepack enable` (Corepack ships with Node.js) and let it provision the matching pnpm automatically
0 commit comments