Question
Stackblitz dependency recovery via package.json
Cig Lane
0 reputation · 21 Nov 2021, 22:30 UTC
111.7K views1
Loading…
0 reputation · 21 Nov 2021, 22:30 UTC
Stackblitz manages project environments by automatically installing dependencies defined in the package.json file upon project load. This ensures that the WebContainer environment matches the declared versioning.
A challenge arises when a dependency upgrade is performed that introduces breaking changes or installation failures, causing the live preview to crash. Because the IDE relies on the current state of the package.json for its installation cycle, there is no native mechanism within the UI to revert to a previous working dependency tree without modifying the source file.
While lockfiles provide deterministic installs, the process for recovering from a failed upgrade remains manual, requiring either direct edits to the manifest or a commit revert via a connected GitHub repository.
What is the recommended workflow for recovering a project state when a dependency upgrade breaks the build? Is there a way to trigger a clean reinstall of a previous known-good state without manually rolling back the package.json file?
34775 reputation · 22 Nov 2021, 00:02 UTC
Use the Reinstall dependencies button in the Dependencies pane. If that doesn’t fix the crash, revert package.json to a known‑good state via the Reset button or a GitHub revert. Stackblitz has no built‑in lockfile support, so you can’t reinstall an earlier tree without changing the manifest.
When you click Reinstall dependencies, the WebContainer clears its installed node_modules and runs npm ci (or npm install if no lockfile exists) against the current package.json. This removes any partially‑installed or corrupted packages that may have caused the preview to crash.
If the upgrade introduced a breaking change—say a new major version of a core library—the build will still fail even after a clean install. In that case you need to restore a previous package.json that was known to work.
stackblitzReset button (top‑right of the editor). This discards all unsaved changes and reloads the last committed state from the project’s history. It restores the old package.json and any other files that were committed.Revert or Restore. Push the reverted commit back to GitHub, then reload the Stackblitz project. The IDE will automatically install the dependencies from the restored manifest.package.json in the editor, replace the offending line with the previous version, and click Reinstall dependencies again.npm ls to confirm the dependency tree matches the expected versions.package-lock.json or pnpm-lock.yaml) for deterministic installs.package.json.Would you like to know if the project is connected to a GitHub repository? That determines whether the Reset button or a GitHub revert is the most efficient path.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 21 Nov 2021, 23:31 UTC
Stackblitz’s WebContainer runs npm install (not npm ci) by default, so a package-lock.json only narrows the version range—it does not guarantee the exact tree from a prior successful install. If you need bit-for-bit reproducibility, commit the lockfile and pin exact versions in package.json before upgrading.
When the Reset button or GitHub revert isn’t available, open the WebContainer terminal and run:
npm install <pkg>@<last-known-good-version> --save-exact
This rewrites package.json and package-lock.json in one step, then triggers the WebContainer’s auto-reinstall on save. It’s faster than hand-editing the manifest and works even in forked, non-GitHub projects.
Vite, Next.js, and Astro starters sometimes ship with pnpm or yarn lockfiles; the reinstall button still runs the detected package manager, but the exact command (pnpm install --frozen-lockfile vs npm install) varies. Check the template’s packageManager field if the reinstall behaves unexpectedly.