How to fix npm ERR! Error: ENOENT: no such file or directory, lstat 'node_modules/package' in npm

npmBEGINNERMEDIUMUpdated Dec 6, 2025· 431 views

This error occurs when npm cannot find expected files in node_modules during installation or execution. The fix usually involves clearing node_modules and package-lock.json, then performing a clean reinstall.

Quick fix

Fixes ENOENT

rm -rf node_modules
rm package-lock.json
npm cache clean --force
npm install
  1. Clear node_modules and reinstall dependencies
  2. Use npm ci for consistent installations
  3. Check for file system and permission issues
  4. Fix Windows-specific path length issues
npm — error
rm -rf node_modules
rm package-lock.json
npm cache clean --force
npm install
npm ERR! Error: ENOENT: no such file or directory, lstat 'node_modules/package'

What this error means

The ENOENT error with lstat in npm indicates that npm is trying to access a file or directory that doesn't exist. ENOENT stands for "Error NO ENTry" - a standard POSIX error code indicating a missing file system entry. The lstat operation is used by npm to get file status information without following symbolic links. This error typically appears during `npm install`, `npm ci`, or when running npm scripts. It happens when npm's internal state (tracked in package-lock.json) doesn't match the actual contents of your node_modules directory. This mismatch can occur due to interrupted installations, manual file deletions, corrupted npm cache, or file system issues. The error message includes the specific file path npm couldn't find, which helps identify whether it's a specific package issue or a broader node_modules corruption problem. On Windows, this error is particularly common due to NTFS file locking, antivirus interference, and path length limitations.

Typical symptoms

  • npm install fails with 'ENOENT: no such file or directory, lstat' error
  • Error references a path inside node_modules that should exist
  • npm ci fails despite having a valid package-lock.json
  • npm scripts fail to run with file not found errors
  • Installation works on some machines but fails on others
  • Error appears after pulling new changes from git
  • Intermittent failures in CI/CD pipelines during npm install

Common causes

  1. Corrupted or incomplete node_modules directory from interrupted installation
  2. package-lock.json out of sync with actual node_modules contents
  3. File system permissions preventing npm from accessing files
  4. Antivirus or security software locking files during installation (Windows)
  5. Path length exceeding OS limits (especially Windows 260 character limit)
  6. Symbolic link issues, particularly in WSL or cross-platform development
  7. Stale npm cache containing references to deleted packages
  8. Bug in specific npm version affecting file operations

How to fix "npm ERR! Error: ENOENT: no such file or directory, lstat 'node_modules/package'"

1Clear node_modules and reinstall dependencies

The most reliable fix is to completely remove node_modules and reinstall. This resolves 80% of ENOENT lstat errors:

On Linux/macOS:

bash
rm -rf node_modules
rm package-lock.json
npm cache clean --force
npm install

On Windows (Command Prompt):

cmd
rmdir /s /q node_modules
del package-lock.json
npm cache clean --force
npm install

On Windows (PowerShell):

powershell
Remove-Item -Recurse -Force node_modules
Remove-Item package-lock.json
npm cache clean --force
npm install

If rm -rf is slow or hangs on Windows, try using a faster deletion tool:

bash
npx npkill
2Use npm ci for consistent installations

If you have a valid package-lock.json, use npm ci instead of npm install. This command:

- Deletes node_modules automatically before installing
- Installs exact versions from package-lock.json
- Is faster and more reliable in CI/CD environments

bash
npm ci

If npm ci also fails with ENOENT, try deleting node_modules first:

bash
rm -rf node_modules
npm ci

Note: npm ci requires a package-lock.json file. If you don't have one, use npm install first to generate it.

3Check for file system and permission issues

Verify you have proper permissions to the project directory:

bash
# Check current permissions
ls -la node_modules

# On Linux/macOS, fix ownership if needed
sudo chown -R $(whoami) node_modules
sudo chown -R $(whoami) ~/.npm

On Windows, ensure:
1. You're running terminal as Administrator if needed
2. The project isn't in a protected folder (like Program Files)
3. Your antivirus isn't quarantining files

Temporarily disable real-time antivirus scanning for your project folder during installation (re-enable after).

4Fix Windows-specific path length issues

Windows has a default path length limit of 260 characters. Deep node_modules trees can exceed this limit.

Enable long paths in Windows 10/11:

1. Open Group Policy Editor (gpedit.msc)
2. Navigate to: Computer Configuration > Administrative Templates > System > Filesystem
3. Enable "Enable Win32 long paths"

Or via Registry (requires reboot):

powershell
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

Alternative: Use shorter project paths:
Move your project to a shorter path like C:\dev\project instead of C:\Users\YourName\Documents\Projects\MyApp\.

5Fix WSL and cross-filesystem issues

When using Windows Subsystem for Linux (WSL), keep all project files on the same filesystem:

Recommended: Store projects in WSL's native filesystem, not Windows drives:

bash
# Good - WSL native filesystem
cd ~/projects/myapp
npm install

# Avoid - Windows drive mounted in WSL
cd /mnt/c/Users/you/projects/myapp
npm install

If you must use Windows paths from WSL, try:

bash
# Clone fresh instead of using Windows files
git clone https://github.com/user/repo.git ~/projects/repo
cd ~/projects/repo
npm install

For Docker users: Ensure volume mounts are configured correctly. Use named volumes instead of bind mounts for node_modules:

yaml
volumes:
  - .:/app
  - /app/node_modules  # Anonymous volume for node_modules
6Verify npm cache integrity

A corrupted npm cache can cause ENOENT errors. Verify and clean the cache:

bash
# Verify cache integrity
npm cache verify

# If issues found, clean the cache
npm cache clean --force

Check where npm stores its cache:

bash
npm config get cache

If the cache directory has permission issues:

bash
# Linux/macOS
sudo rm -rf ~/.npm
npm install

# Windows
rmdir /s /q %AppData%\npm-cache
npm install
7Update npm to the latest version

Older npm versions have known bugs with file operations. Update to the latest:

bash
# Update npm globally
npm install -g npm@latest

# Verify version
npm --version

If using nvm (Node Version Manager):

bash
nvm install-latest-npm

For specific npm bugs, you can also try the LTS version:

bash
npm install -g npm@lts

After updating npm, clear node_modules and reinstall:

bash
rm -rf node_modules package-lock.json
npm install

Advanced notes

### CI/CD Pipeline Considerations

In CI/CD environments, ENOENT errors often stem from caching issues:

1. Use npm ci instead of npm install - It's designed for automated environments
2. Clear cache between builds if you suspect corruption
3. Don't cache node_modules directly - Cache ~/.npm instead

Example GitHub Actions configuration:

yaml
- name: Cache npm dependencies
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}

- name: Install dependencies
  run: npm ci

### Docker Volume Mounting Issues

When using Docker with bind mounts, node_modules can become corrupted. Best practices:

dockerfile
# Install dependencies in a separate stage
FROM node:20 AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:20
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

### Symbolic Link Problems

Some packages create symbolic links in node_modules. On Windows or when using network drives, symlinks may not work correctly:

bash
# Check if symlinks are being used
npm config get link

# Disable if causing issues
npm config set link false

### Debugging ENOENT Errors

Get more details about what's failing:

bash
# Verbose output shows exact file operations
npm install --verbose 2>&1 | grep -i enoent

# Check what files exist
ls -la node_modules/<problematic-package>/

### Platform-Specific Notes

macOS: APFS case-insensitivity can cause issues with packages that have similar names with different casing.

Linux: SELinux or AppArmor policies may block npm file operations. Check audit logs if you see permission-related ENOENT errors.

Windows: The NTFS file system can lock files that are in use. Close all Node.js processes and IDEs before deleting node_modules.

### Prevention Tips

1. Commit package-lock.json to version control
2. Use .gitignore for node_modules (never commit it)
3. Run npm ci in CI/CD for reproducible builds
4. Keep npm updated to avoid known bugs
5. Use consistent Node.js versions across team (consider .nvmrc file)

Frequently asked questions

What does "ENOENT" mean?
The ENOENT error with lstat in npm indicates that npm is trying to access a file or directory that doesn't exist. ENOENT stands for "Error NO ENTry" - a standard POSIX error code indicating a missing file system entry. The lstat operation is used by npm to get file status information without following symbolic links.
How do I fix "ENOENT"?
This error occurs when npm cannot find expected files in node_modules during installation or execution. The fix usually involves clearing node_modules and package-lock.json, then performing a clean reinstall.
What causes "ENOENT"?
Corrupted or incomplete node_modules directory from interrupted installation package-lock.json out of sync with actual node_modules contents File system permissions preventing npm from accessing files
Is the "ENOENT" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading