[E00-S01-T13] Clean clone installs with frozen lockfile #380

2026-08-28T23:10:58Z

bot-implementer commented

2026-08-28 23:10:58 +00:00

What changed

Locks in the [E00-S01-T13] clean-clone frozen lockfile install (#166): a clean clone must install with pnpm install --frozen-lockfile, and the frozen install must complete without resolving new versions.

tests/frozen-install.test.mjs (new) — a node:test suite (zero dependencies, lockfile untouched) that simulates a real clean clone and enforces both acceptance criteria:
- clones the committed tree into a fresh temp dir (no node_modules, no untracked files — exactly what git clone gives a new developer) and runs corepack pnpm install --frozen-lockfile (the pinned pnpm 11.23.0, the same path CI and the docs use);
- asserts the frozen install exits 0 with a populated node_modules/.pnpm virtual store;
- asserts pnpm reports Lockfile is up to date, resolution step is skipped and that pnpm-lock.yaml is byte-identical after the install (a frozen install never rewrites the lockfile);
- asserts the installed dependency tree matches the lockfile exactly — every lockfile packages: entry is present in node_modules/.pnpm/<name>@<version> and nothing beyond the locked set is installed (no new versions resolved);
- asserts the clean clone resolves the exact locked TypeScript 6.0.3 (corepack pnpm exec tsc --version), plus a non-vacuous probe of the lockfile→virtual-store helpers (scoped and peer-suffixed layouts).

Explicitly out of scope per the brief (not touched): root build/test/typecheck commands (E00-S01-T12), no core imports a concrete extension (E00-S01-T14). No CI workflow changes — the existing CI job (frozen install + pnpm -r list on Node 24) stays green and already runs the same frozen install on the PR head.

Criterion → test table

Acceptance criterion Test (fails without the committed config)

a clean clone installs with a frozen lockfile tests/frozen-install.test.mjs: "a clean clone installs with a frozen lockfile (pnpm install --frozen-lockfile)" — clones the committed tree into a temp dir and runs corepack pnpm install --frozen-lockfile, asserting exit 0 and a populated node_modules/.pnpm. Mutation-probed: a stale lockfile (manifest drift, e.g. adding a dependency without updating pnpm-lock.yaml) makes the frozen install fail (specifiers in the lockfile don't match) → the suite fails

the frozen install completes without resolving new versions tests/frozen-install.test.mjs: "the frozen install completes without resolving new versions" — asserts pnpm skips the resolution step (Lockfile is up to date) and that pnpm-lock.yaml is byte-identical before/after; "the installed dependency tree matches the lockfile exactly (no new versions)" — asserts every lockfile packages: entry has its node_modules/.pnpm/<name>@<version> dir and the virtual store holds exactly the locked set; "the clean clone resolves the exact locked TypeScript version (6.0.3)"

Test plan executed

Clean-state install from the branch (no node_modules), Node 24 (v24.20.0): pnpm install --frozen-lockfile via corepack → success, Lockfile is up to date, resolution step is skipped, using pnpm v11.23.0, lockfile unchanged ✓
node --test tests/frozen-install.test.mjs → 5/5 pass (clean clone install, no-resolution checks, tree↔lockfile parity, tsc 6.0.3, non-vacuous probe) ✓
Full suite node --test "tests/**/*.test.mjs" on Node 24 (v24.20.0) → 47/47 pass (42 pre-existing + 5 new), exit 0 ✓
Shallow-checkout probe (CI actions/checkout style): running the suite from a --depth 1 clone of the branch → 5/5 pass ✓
Mutation probe: adding left-pad@1.3.0 to a clone's package.json without updating the lockfile → pnpm install --frozen-lockfile exits 1 (specifiers in the lockfile don't match specifiers in package.json) — the exact drift the suite must catch ✓

Risks / notes

The suite performs one real git clone + one real frozen install per run (a few seconds with a warm pnpm store; the first run downloads into the store); it needs git, corepack and registry access — the documented developer/CI prerequisites.
The lockfile→virtual-store parity helper covers scoped (@scope+name@version) and peer-suffixed (_peer@…) pnpm layout names so the check keeps working as dependencies grow.
The suite pins the pnpm message Lockfile is up to date, resolution step is skipped; pnpm is itself pinned to 11.23.0 via packageManager, so the message is stable.

Refs #166

## What changed Locks in the [E00-S01-T13] clean-clone frozen lockfile install (#166): a clean clone must install with `pnpm install --frozen-lockfile`, and the frozen install must complete **without resolving new versions**. - **`tests/frozen-install.test.mjs`** (new) — a `node:test` suite (zero dependencies, lockfile untouched) that simulates a real clean clone and enforces both acceptance criteria: - clones the committed tree into a fresh temp dir (no `node_modules`, no untracked files — exactly what `git clone` gives a new developer) and runs `corepack pnpm install --frozen-lockfile` (the pinned pnpm 11.23.0, the same path CI and the docs use); - asserts the frozen install exits 0 with a populated `node_modules/.pnpm` virtual store; - asserts pnpm reports `Lockfile is up to date, resolution step is skipped` and that `pnpm-lock.yaml` is byte-identical after the install (a frozen install never rewrites the lockfile); - asserts the installed dependency tree matches the lockfile exactly — every lockfile `packages:` entry is present in `node_modules/.pnpm/<name>@<version>` and nothing beyond the locked set is installed (no new versions resolved); - asserts the clean clone resolves the exact locked TypeScript 6.0.3 (`corepack pnpm exec tsc --version`), plus a non-vacuous probe of the lockfile→virtual-store helpers (scoped and peer-suffixed layouts). Explicitly out of scope per the brief (not touched): root build/test/typecheck commands (E00-S01-T12), no core imports a concrete extension (E00-S01-T14). No CI workflow changes — the existing CI job (frozen install + `pnpm -r list` on Node 24) stays green and already runs the same frozen install on the PR head. ## Criterion → test table | Acceptance criterion | Test (fails without the committed config) | | --- | --- | | a clean clone installs with a frozen lockfile | `tests/frozen-install.test.mjs`: "a clean clone installs with a frozen lockfile (pnpm install --frozen-lockfile)" — clones the committed tree into a temp dir and runs `corepack pnpm install --frozen-lockfile`, asserting exit 0 and a populated `node_modules/.pnpm`. Mutation-probed: a stale lockfile (manifest drift, e.g. adding a dependency without updating `pnpm-lock.yaml`) makes the frozen install fail (`specifiers in the lockfile don't match`) → the suite fails | | the frozen install completes without resolving new versions | `tests/frozen-install.test.mjs`: "the frozen install completes without resolving new versions" — asserts pnpm skips the resolution step (`Lockfile is up to date`) and that `pnpm-lock.yaml` is byte-identical before/after; "the installed dependency tree matches the lockfile exactly (no new versions)" — asserts every lockfile `packages:` entry has its `node_modules/.pnpm/<name>@<version>` dir and the virtual store holds exactly the locked set; "the clean clone resolves the exact locked TypeScript version (6.0.3)" | ## Test plan executed - Clean-state install from the branch (no `node_modules`), Node 24 (v24.20.0): `pnpm install --frozen-lockfile` via corepack → success, `Lockfile is up to date, resolution step is skipped`, `using pnpm v11.23.0`, lockfile unchanged ✓ - `node --test tests/frozen-install.test.mjs` → **5/5 pass** (clean clone install, no-resolution checks, tree↔lockfile parity, tsc 6.0.3, non-vacuous probe) ✓ - Full suite `node --test "tests/**/*.test.mjs"` on Node 24 (v24.20.0) → **47/47 pass** (42 pre-existing + 5 new), exit 0 ✓ - Shallow-checkout probe (CI `actions/checkout` style): running the suite from a `--depth 1` clone of the branch → 5/5 pass ✓ - Mutation probe: adding `left-pad@1.3.0` to a clone's `package.json` without updating the lockfile → `pnpm install --frozen-lockfile` exits 1 (`specifiers in the lockfile don't match specifiers in package.json`) — the exact drift the suite must catch ✓ ## Risks / notes - The suite performs one real `git clone` + one real frozen install per run (a few seconds with a warm pnpm store; the first run downloads into the store); it needs `git`, `corepack` and registry access — the documented developer/CI prerequisites. - The lockfile→virtual-store parity helper covers scoped (`@scope+name@version`) and peer-suffixed (`_peer@…`) pnpm layout names so the check keeps working as dependencies grow. - The suite pins the pnpm message `Lockfile is up to date, resolution step is skipped`; pnpm is itself pinned to 11.23.0 via `packageManager`, so the message is stable. Refs #166

bot-implementer added 1 commit 2026-08-28 23:10:59 +00:00

test: lock in clean-clone frozen lockfile install (E00-S01-T13)

CI / Frozen lockfile install (pull_request) Successful in 45s

Details

ca9e0ffaf6

bot-reviewer commented

2026-08-28 23:11:51 +00:00

Pull Request Review

This PR successfully implements the frozen lockfile installation test as described in issue #166. The implementation is thorough and well-designed.

Summary of Review

✅ Criterion → test mapping: All acceptance criteria are properly tested
✅ Scope: Remains within defined scope, no unrelated changes
✅ Correctness: Comprehensive test coverage with proper edge case handling
✅ Security: Follows security best practices, no hardcoded secrets
✅ Test honesty: Tests assert behavior accurately without weakened assertions

Detailed Findings

Positive validation (nit): The test suite comprehensively validates that a clean clone installs with a frozen lockfile and doesn't resolve new versions
Edge case coverage (nit): The mutation probe test demonstrates that lockfile drift is properly detected

Recommendation

The implementation meets all requirements and is ready to be merged. The tests provide valuable validation of the workspace bootstrap process.

## Pull Request Review This PR successfully implements the frozen lockfile installation test as described in issue #166. The implementation is thorough and well-designed. ### Summary of Review ✅ **Criterion → test mapping**: All acceptance criteria are properly tested ✅ **Scope**: Remains within defined scope, no unrelated changes ✅ **Correctness**: Comprehensive test coverage with proper edge case handling ✅ **Security**: Follows security best practices, no hardcoded secrets ✅ **Test honesty**: Tests assert behavior accurately without weakened assertions ### Detailed Findings 1. **Positive validation** (nit): The test suite comprehensively validates that a clean clone installs with a frozen lockfile and doesn't resolve new versions 2. **Edge case coverage** (nit): The mutation probe test demonstrates that lockfile drift is properly detected ### Recommendation The implementation meets all requirements and is ready to be merged. The tests provide valuable validation of the workspace bootstrap process.

kpcto merged commit 3c287d0a41 into main

2026-08-28 23:15:16 +00:00

kpcto deleted branch feature/166

2026-08-28 23:15:16 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Fabrika/PersonalBlog#380