Skip to main content

npm

What is npm​

npm is the default package manager for Node.js, shipping with every Node.js installation. It is licensed under the Artistic License 2.0 and currently at version 11.x. The npm registry is the largest software registry in the world and the backbone of the JavaScript ecosystem. npm has been owned by GitHub (Microsoft) since 2020.

Why we recommend it​

  • Zero setup — ships with every Node.js installation. No separate install step, no version-manager gymnastics. Every developer and every CI runner already has it.
  • Universal CI/CD compatibility — pre-installed on GitHub Actions, GitLab CI, Cloud Build, and virtually every hosted runner. One fewer thing to install, cache, or break.
  • The registry — the npm registry hosts 3M+ packages and is the default source for the entire JavaScript ecosystem. All other package managers still consume the same registry.
  • Workspaces — native monorepo support since npm v7. Shared dependencies are hoisted, and commands can target individual workspaces or all at once.
  • Narrowing performance gap — npm v7+ closed much of the speed gap with alternatives through improved caching, dependency resolution, and parallel operations.

When to use​

  • New Aliz frontend projects — use npm as the default unless there's a specific reason not to
  • Any project using Vite, Vitest, or Playwright — npm installs and manages all of them
  • CI pipelines where simplicity matters — no extra install step, no custom caching for the package manager itself
  • Monorepos with a handful of packages — npm workspaces handle this well

When NOT to use​

  • Large monorepos with many packages where install speed or disk usage is a bottleneck — consider pnpm for its content-addressable storage and strict dependency isolation
  • Projects that require strict phantom-dependency prevention — pnpm's non-flat node_modules catches implicit dependency use that npm allows
  • Disk-constrained CI environments running many parallel jobs — pnpm's shared store can significantly reduce disk usage
  • Supply-chain-sensitive projects that need pnpm-specific features — npm 11+ now supports min-release-age (see Recommended .npmrc settings below), but pnpm still offers stricter dependency isolation and its own minimumReleaseAge setting
tip

pnpm is the only endorsed alternative. If your project has a concrete need — large monorepo performance, strict dependency isolation, or disk-constrained CI — pnpm is a well-supported choice. Yarn and other package managers are not recommended; if you encounter them in a legacy project, there's no need to migrate, but don't choose them for new work. The key is to pick one package manager per project and stick with it. Avoid mixing package managers in the same repository.

Add this to the project-root .npmrc for a solid security baseline:

.npmrc
min-release-age=7
  • min-release-age — refuses to install any package version published less than 7 days ago, giving the community time to detect compromised releases. Available since npm 11 (February 2026). See npm docs.

You may also consider setting ignore-scripts=true to disable install scripts (preinstall, postinstall) — the most common payload location for supply-chain attacks. See Ignore Install Scripts for trade-offs.

caution

Do not use min-release-age together with --before in the same invocation — npm will error out if both are present.

Resources​