Why I stopped using npm install for development

I've completely replaced npm install in my development workflow. After years of dealing with massive node_modules folders, inconsistent lockfiles, and phantom dependency issues, I made the switch to pnpm and enabled Corepack. The difference is night and day.

The breaking point came when I realized my MacBook had 47GB of node_modules folders scattered across old projects. That's more space than most operating systems need.

The Problems with npm That Nobody Talks About

Disk space waste -- npm creates a separate node_modules folder for every project. If you have 20 React projects, you have 20 copies of React stored locally. It's insane when you think about it.

Phantom dependencies -- npm's flat structure lets you import packages you did not explicitly install. Your code might work locally but break in production because you're accidentally using a transitive dependency.

Slow installs -- Even with npm's improvements, installing dependencies still feels sluggish compared to modern alternatives.

Package manager version chaos -- Different projects need different npm versions, but managing that manually is a pain.

My New Setup: pnpm + Corepack

Here's what I run on every new machine:

# Enable Corepack (ships with Node.js 16+)
corepack enable
 
# Set pnpm as default
corepack prepare pnpm@latest --activate

That's it. No global package manager installations, no version management headaches.

Why pnpm Changed Everything

Content-addressable storage -- pnpm stores packages in a global store and creates hard links in your project. One copy of React serves all your projects.

# Traditional npm approach
~/project1/node_modules/react/  # 2.3MB
~/project2/node_modules/react/  # 2.3MB
~/project3/node_modules/react/  # 2.3MB
# Total: 6.9MB for the same package
 
# pnpm approach
~/.pnpm/react@18.2.0/           # 2.3MB (stored once)
~/project1/node_modules/react/  # hard link (0MB)
~/project2/node_modules/react/  # hard link (0MB) 
~/project3/node_modules/react/  # hard link (0MB)
# Total: 2.3MB

True dependency isolation -- pnpm creates a non-flat node_modules structure. You can not import packages you did not explicitly declare as dependencies. This prevents those "it works on my machine" moments.

Workspace support -- pnpm handles monorepos better than npm or Yarn. The workspace linking is faster and more reliable.

Corepack Solves Package Manager Hell

Before Corepack, every project README had instructions like "use npm 8.x" or "this requires Yarn 1.22". Now I just define it in package.json:

{
  "name": "my-project",
  "packageManager": "pnpm@8.15.1",
  "scripts": {
    "dev": "next dev"
  }
}

When anyone runs npm install or yarn install on this project, Corepack automatically downloads and uses pnpm instead. No global installs, no version conflicts.

The Performance Difference Is Real

I timed fresh installs of a typical Next.js project:

• npm install: 47 seconds
• pnpm install: 23 seconds
• pnpm install (with store populated): 8 seconds

The speed improvement compounds across your workday. Faster installs mean faster CI builds, faster Docker builds, and less time waiting around.

Migration Is Painless

Converting existing projects takes two minutes:

# In your project directory
rm -rf node_modules package-lock.json
echo '{"packageManager": "pnpm@latest"}' >> package.json
pnpm install

Your lockfile format changes from package-lock.json to pnpm-lock.yaml, but the dependency resolution is more deterministic than npm's.

The Gotchas I've Hit

Docker builds -- You need to install pnpm in your Docker containers or use Corepack there too:

FROM node:18
RUN corepack enable
COPY package.json pnpm-lock.yaml ./
RUN pnpm install --frozen-lockfile

CI/CD -- GitHub Actions and other CI providers need to know about pnpm:

- uses: pnpm/action-setup@v2
  with:
    version: latest

Team adoption -- Some developers resist change. The disk space savings usually convince them after the first week.

Why I'm Not Going Back

The combination of pnpm's efficiency and Corepack's automatic version management has eliminated entire categories of problems from my workflow. I do not think about package managers anymore -- they just work.

My node_modules folders are smaller, my installs are faster, and I have not hit a phantom dependency bug in months. That's worth the small migration effort.

If you're still using npm install in 2024, you're missing out on a significantly better development experience.