ember-cli-update interrupted upgrade leaves half-applied files and no rollback path
0 reputation · 03 Dec 2021, 08:09 UTC
0 reputation · 03 Dec 2021, 08:09 UTC
Ember projects are typically upgraded with ember-cli-update, which offers a dry-run preview and an interactive mode that pauses whenever a file such as ember-cli-build.js conflicts with the incoming blueprint. The prompt shows old and new content side by side and leaves the merge decision entirely to the developer.
The open question is what the tool guarantees if an upgrade is abandoned partway through. There is no built-in rollback flag, so files touched before the interruption stay in a partially applied state, and new dependency entries in package.json can end up mismatched with node_modules when the install step never completes. Manual conflict resolution also risks dropping addon imports, which would only surface as missing modules at runtime. Recovery appears to rest entirely on external version control rather than on the tool itself.
ember-cli-update run?35275 reputation · 03 Dec 2021, 14:53 UTC
ember-cli-update has no built-in rollback mechanism. The only supported recovery after an interruption is to discard uncommitted changes using version control (e.g., git checkout -- . or git reset --hard). The tool treats clean recovery as a version-control responsibility, not a tool responsibility.
ember-cli-update applies codemods and blueprint changes directly to the working tree. If the process is killed, Ctrl-C'd, or fails mid-run, every file touched up to that point remains modified. There is no --rollback flag, no snapshot, and no internal journal to revert from.
The CLI help and README both state: commit or stash all changes before running ember-cli-update. Running on a dirty working tree makes it impossible to distinguish tool-applied changes from pre-existing local edits. Clean recovery is purely a version-control concern.
The side-by-side diff prompts wait for stdin and are not stable across releases. They are not designed for scripted or automated handling. The --dry-run flag only previews changes without writing them; it does not produce machine-parseable output suitable for automation.
If package.json is modified but the subsequent npm install/yarn install/pnpm install step never completes, node_modules will be out of sync. The standard fix is to restore package.json from version control and re-run the package manager.
Manual conflict resolution can drop addon imports or other required code. The tool does not validate semantic correctness after merges; missing-module errors surface only at build or runtime.
git status to see which files were modified.git checkout -- . (or git reset --hard if you also want to drop staged changes).package.json was restored, run npm install (or yarn/pnpm install) to bring node_modules back in sync.ember test or your CI script) to confirm the project builds and passes.Did you have uncommitted local changes before starting the upgrade? If yes, git reset --hard will destroy them. In that case, you need git stash before the reset, then re-apply the stash after recovery and manually re-merge any tool changes you still want.
ember-cli-update --dry-run on a clean branch to see the full file list before committing to the upgrade.git status first—do not assume only the file shown in the last prompt was touched.Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 03 Dec 2021, 18:03 UTC
ember‑cli‑update does not ship a rollback flag. If the process stops, the files it has already touched stay in the working tree, and package.json may be partially edited. The safest path is to rely on version control:
git status – identify the altered files.git reset --hard HEAD~1 (or the commit before the update) and delete node_modules.
npm install then rebuild.git checkout -- <file> on the modified files and re‑run the update.Always commit or stash changes before running ember-cli-update. The conflict prompts are not part of a public API and can change, so scripted handling is discouraged.