Can an Angular workspace be recovered cleanly when ng update fails mid-run?

Short answer

Angular CLI’s ng update does not create a snapshot or rollback point. If it stops mid‑run, the changes it already made to package.json, lockfiles and source files cannot be undone by the CLI itself. The only reliable way to return to a clean state is to restore the workspace from version control taken before the update.

Why there is no built‑in rollback

The update command runs migration schematics that mutate the workspace tree in place. Once a schematic writes a file, the CLI has no record of the previous contents to revert. Consequently, a partial run leaves the workspace in an inconsistent state that only an external history (e.g., Git) can repair.

Confirmed recovery steps

1. Identify the last known good commit (the one you made before running ng update).
2. Restore the working tree:

   git checkout <commit‑hash>   # or git reset --hard <commit‑hash>
   git clean -fdx   # remove untracked files, node_modules, dist, etc.
   

3. Re‑install dependencies from the committed lockfile:

   npm ci   # uses package‑lock.json exactly as committed
   

4. Verify the workspace is clean:

   git status   # should show no modifications
   ng --version   # should match the pre‑update toolchain
   

When the recommendation changes

If you do not have a pre‑update commit or branch, the only safe fallback is to manually inspect git diff (or git status) after the failed run, revert each changed file individually, and then reinstall dependencies. This is error‑prone and not guaranteed to succeed, so having a version‑control snapshot is strongly advised.

Missing diagnostic detail that would change the recommendation: Do you have a pre‑update git commit or branch to restore to?