How to Fix npm ERR! code ELIFECYCLE — Diagnose errno 1, 134, and SIGKILL by Cause

Fixing npm ERR! code ELIFECYCLE — Diagnose errno 1, 134, and SIGKILL by Cause

You ran npm run build and the terminal filled with red text. At the bottom you see lines like this:

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! my-app@1.0.0 build: `next build`
npm ERR! Exit status 1

If you landed here by searching that exact message, remember one thing first: ELIFECYCLE is not the culprit. Don't panic—look one line above. The real cause is always there.

What ELIFECYCLE Actually Is: npm Isn't at Fault

Key concept ELIFECYCLE = a signal that a lifecycle script (a command defined in package.json scripts) exited with a non-zero exit code. npm just ran a child process; when that process failed, npm's only job was to wrap it as "the script I ran died." The real error messages are in the lines immediately above npm ERR! code ELIFECYCLE.

A real log makes the structure obvious. Below is typical output when a build dies because of an ESLint failure.

> my-app@1.0.0 build
> eslint . && next build

/src/components/Header.tsx
  12:7  error  'useState' is defined but never used  no-unused-vars

✖ 1 problem (1 error, 0 warnings)

npm ERR! code ELIFECYCLE      ← 여기는 결과 요약일 뿐
npm ERR! errno 1              ← '실패했다'는 사실만 알려줌

The 'useState' is defined but never used at the top is the real cause. If you copy only the ELIFECYCLE line and search, you'll never find the answer. The key is to scroll up through the log and find the first real red error.

Don't Confuse It with ERESOLVE

People who moved to pnpm/yarn and then touch npm again after a while often mix these up. They occur at different stages.

• ELIFECYCLE: occurs at the script execution stage (build/start/test) after npm install
• ERESOLVE: occurs during npm install at the dependency tree resolution stage (peer dependency conflicts, etc.)

If you got ERESOLVE, this article isn't the one—look for a guide on resolving dependency conflicts (--legacy-peer-deps, etc.). This article covers the case where install succeeded but the script dies.

5-Second Classification by errno and signal

Find the word errno or signal in the red log and match it against the table below. The cause category narrows immediately.

The takeaway: 134/Killed is memory, 1 is a code error, ENOENT is a missing file. Remember these three branches and you're done 80% of the time.

Six Copy-Paste Fixes by Cause

① Actual script error (errno 1) — the most common

npm run build often chains several commands, which hides where it died. Run that script by itself to surface the original error.

# Run the commands bundled in the build script separately
npm run lint          # lint only
npx tsc --noEmit      # type errors only
npm test              # tests only

The red message you get here is the real cause. Fix it and you're done.

② Corrupted node_modules or lock file

This is when the install got tangled, or the lock file and the actual tree drifted apart.

rm -rf node_modules package-lock.json
npm install

③ Corrupted cache

If the same error repeats after the method above, clear the cache.

npm cache clean --force
rm -rf node_modules
npm install

# Windows (PowerShell/CMD)
rd /s /q node_modules
npm cache clean --force
npm install

④ Out of memory (errno 134 / SIGKILL)

If you see Killed or JavaScript heap out of memory, raise the heap limit. Node.js 20/22 LTS does scale the default heap with system memory, but monorepos and large webpack builds still blow up.

# temporary
NODE_OPTIONS=--max-old-space-size=4096 npm run build

# pin it in package.json (cross-env for OS compatibility)
# "build": "cross-env NODE_OPTIONS=--max-old-space-size=4096 next build"

In CI, injecting it as an environment variable is cleaner.

env:
  NODE_OPTIONS: --max-old-space-size=4096

⑤ Node version mismatch

If your local Node version differs from your teammates' or CI, certain packages die at the build stage. Pin the version.

# create .nvmrc at the project root
echo "20" > .nvmrc
nvm use

// package.json
{
  "engines": {
    "node": ">=20.0.0 <23.0.0",
    "npm": ">=10.0.0"
  }
}

⑥ Permissions / EACCES

When you see EACCES: permission denied, avoid sudo npm install -g. It creates root-owned files and causes bigger problems. Moving the global prefix to your user folder is safer.

mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'
# add to ~/.zshrc or ~/.bashrc
export PATH=~/.npm-global/bin:$PATH

How to Read the Log: Scrolling Up Is Everything

npm 10/11 writes the full log to a file on failure. If the terminal output got truncated, open that file.

# macOS / Linux
cat ~/.npm/_logs/*.log | tail -n 100

# re-run with more detail
npm run build --verbose

On older versions, check npm-debug.log in the project folder. Whatever log you look at, the method is the same. Find the ELIFECYCLE line, then scroll up from there to the first real error.

It Works Locally but Fails Only in CI (GitHub Actions)

The most frustrating situation. Here's the checklist.

• Node version mismatch: Confirm node-version in actions/setup-node matches .nvmrc
• npm ci vs npm install: CI should use npm ci, which strictly follows the lock file. If the lock and package.json are out of sync, it fails immediately
• Runner memory limits: GitHub's default runner has about 7GB. Large builds hit SIGKILL, so adjust the heap with NODE_OPTIONS
• CI=true promotion: Especially with CRA (Create React App), CI=true promotes warnings to errors, so a build that passed locally dies. The proper fix is to fix the warnings themselves

- uses: actions/setup-node@v4
  with:
    node-version-file: '.nvmrc'   # match local version
    cache: 'npm'
- run: npm ci                      # not install!

A Practical Note

After debugging many projects, I've learned that 90% of the time spent searching for ELIFECYCLE is wasted. As a junior I pasted npm ERR! code ELIFECYCLE straight into Google and burned half a day, when the answer was Module not found three lines up in the terminal. These days, when I see a red log I always start from the topmost error, and troubleshooting time has dropped to about 1/5. ELIFECYCLE is just the obituary saying "the script died"—the cause of death is written above it.

References: Official Docs

The primary source for the behavior, settings, and errors covered in this article is the following official documentation. Check there for version-specific options and exact behavior.

• Node.js 공식 문서

FAQ

Q. Are ELIFECYCLE and ERESOLVE the same error? A. No. ERESOLVE happens during npm install from dependency conflicts (peer dependencies, etc.). ELIFECYCLE happens later, when a build/start/test script runs after install. They occur at completely different stages.

Q. What's the difference between errno 1 and 134? A. errno 1 means the script failed in the usual way (lint, type, or test errors, etc.). 134 (or SIGKILL/Killed) means the process was force-killed due to lack of memory. If you see 134, try NODE_OPTIONS=--max-old-space-size=4096 first.

Q. The build works locally but GitHub Actions only shows ELIFECYCLE. A. Check Node version mismatch, using npm ci instead of npm install, SIGKILL from runner memory limits, and warnings being promoted to errors under CI=true (especially CRA), in that order. Start by aligning .nvmrc with node-version-file.