Rehearse dependency installation with a separate package store. A warm local store can hide downloads your teammate still needs before the demo starts.
A fresh checkout removes the project's installed files. It does not necessarily remove packages cached elsewhere on the machine. If you want to check whether the recorded dependencies can still be obtained, give this rehearsal its own store instead of clearing your everyday one.
This exercise focuses on dependency acquisition. It complements a clean-checkout demo rehearsal; it does not replace checking configuration, fixture preparation or the submitted application scenario.
Hold the project version constant
Use two fresh disposable checkouts of the same submitted commit. Record the operating system, runtime version and project-selected package-manager version. Use the manager and workspace configuration already recorded by the project. Do not change the lockfile just to make the experiment finish.
For a pnpm project, first run its ordinary documented install with the frozen lockfile. Then, in the second checkout, use a new task-specific store directory that does not already contain packages:
pnpm install --frozen-lockfile --store-dir ./rehearsal-store
pnpm documents frozen-lockfile as failing when the lockfile is absent or needs an update. Its storeDir setting selects where packages are stored. Choose a new directory for each cold-store run. Reusing this directory later makes it warm.
Keep the rehearsal store out of the submission. If you place it inside a disposable checkout, do not stage it. There is no reason to delete the global store or alter another person's setup to perform this comparison.
Record the first acquisition failure
If the ordinary install succeeds while the separate-store run fails, preserve the first error and its step. It may point to registry reachability, package availability, authentication or a platform-specific requirement. That difference is a diagnostic clue, not proof of one specific cause.
Do not publish registry credentials or copy credential values into your README. Document required access through the project's normal setup process. Repeat the same experiment after a permitted repair, keeping the submitted commit and environment record explicit.
Keep offline and online claims separate
pnpm's offline mode uses packages already in the store and fails when a needed package is unavailable there, according to the installation documentation. An offline success demonstrates local availability. It cannot show that another machine can download the dependencies.
Installation may also execute scripts under the project's package-manager policy. Preserve that policy during the rehearsal. Disabling protections or approving new build scripts changes the experiment; it should not become an automatic response to an error.
After a successful install, run the project's documented checks and one demo action. Keep "dependencies acquired" separate from "application scenario passed" in the record.
If you organize an event using the Stavleak toolkit, specify whether participants should submit hosted links, source code or both. Teams can then rehearse the setup judges are actually expected to perform.
Top comments (0)