npm ERR! code ELIFECYCLE
What npm ERR! code ELIFECYCLE actually reports, why the real cause is always logged above it, and how to find and fix the script that failed.
Last updated
npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! my-app@1.0.0 build: `next build` npm ERR! Exit status 1
What it means: npm is reporting that a script it ran (build, test, start, or any other package.json script) exited with a non-zero status — ELIFECYCLE is just npm's label for 'the script failed', not a diagnosis of why. Note the vintage: this exact wording is npm 6. npm 7+ dropped ELIFECYCLE for script failures and prints `command failed` with an exit code instead, and npm 10+ writes `npm error` rather than `npm ERR!` — the cause and the fix below are identical either way.
Likely causes
Most probable first — with how to confirm.
- 1.The underlying command itself failed — a compile error, a failing test, or a thrown exception — scroll up in the log above the ELIFECYCLE lines to find the actual error; that's the real cause.
- 2.A missing or mismatched dependency makes the script crash before it can even finish — check `node -v` against the `engines` field in package.json if the failure looks environment-related.
- 3.The script references a binary or file that doesn't exist, often a typo in package.json's `scripts` block or a build step that got skipped — run the underlying command directly to see the raw error without npm's wrapper.
- 4.The script ran out of memory partway through (common on `build` scripts over large codebases) — check for a heap-related error above ELIFECYCLE rather than assuming it's a code bug.
Fixes
Safest first; destructive ones are called out.
- →Scroll up to the real error printed above npm's summary (on npm 7+ look for `command failed` instead of ELIFECYCLE) and fix that — npm's own line never states the cause.
- →Re-run the failing command directly (e.g. `next build`, `tsc`, `jest`) without npm's wrapper for cleaner, unfiltered output.
- →If the failure looks dependency-related, delete `node_modules` and reinstall from the lockfile (`rm -rf node_modules && npm install`) — safe, though slower since everything re-downloads.
- →Confirm your local Node version matches what the project expects; a mismatch can make an otherwise-correct script crash.
Part by part
- npm ERR!
- npm's own prefix on every line it writes to stderr. Its presence means npm is reporting, not necessarily that npm is the thing that failed.
- ELIFECYCLE
- A lifecycle script exited with a non-zero status. This is npm telling you your script failed — it says nothing about why.
Common mistakes
rm -rf node_modules package-lock.json && npm installThe reflex fix for npm problems, and usually wrong here: ELIFECYCLE means your own script failed, not that installation is broken. Deleting the lockfile also discards the exact versions that were working.
npm cinpm install --forceForce affects dependency resolution, which is not what failed. It changes nothing about a script exiting non-zero and can leave you with a tree npm itself considers invalid.
Reading only the npm ERR! linesThe actual error is above them, printed by whatever your script ran. npm's block is a summary appended afterwards, so scrolling up past it is where the answer usually is.
Questions
Where is the real error?
Above the npm ERR! block, in the output of the script itself. npm appends its own summary after the failure, so the compiler error, test failure or missing binary that actually caused it has already scrolled past.
What does the exit code tell me?
npm reports the script's exit status, and conventions vary by tool — 1 is a generic failure, 127 means command not found, 130 means interrupted. A 127 in particular points at a missing binary rather than a broken build.
Is the log file useful?
Sometimes. npm writes a full log under its cache directory and prints the path, but it mostly repeats what was on screen. The script's own output remains the more informative source.
Why did it work in CI but not locally, or the reverse?
Usually a version or environment difference — a different Node version, a missing environment variable, or a dependency installed globally on one machine. Compare node --version first, since it explains a surprising share of these.