Glossary / Package managers

Package managers

A JavaScript package manager resolves declared dependencies, downloads or links package contents, records a dependency graph, and runs project scripts. npm, pnpm, and Yarn share core concepts but differ in storage, linking, lockfile formats, workspace features, and defaults; package-manager choice affects reproducibility and developer workflows.

Project manifest and install model

package.json describes the project, scripts, dependency ranges, and package metadata. A lockfile records a resolved dependency graph for a specific package manager and format. node_modules is an installation result, not the full source of dependency intent. Installers may hoist dependencies, create symlinks, use a virtual store, or enforce isolation. Hoisting can accidentally allow undeclared “phantom” imports that fail under a stricter layout.

Package managers also execute lifecycle scripts, which may run dependency code during installation. Modern versions offer policies and flags to limit such scripts; review the selected manager's behavior. Registry configuration, proxy settings, authentication, and platform-specific optional packages affect resolution and installation.

Choosing and operating one

Pick one manager and version policy per repository. Use its lockfile consistently; avoid concurrent lockfiles that describe different graphs. Pin the manager via packageManager metadata and a Corepack or CI policy where appropriate. Use clean/frozen installs in CI, cache package downloads rather than mutable installation trees when portability is uncertain, and review lockfile changes.

Do not assume npm, pnpm, and Yarn commands or semantics are interchangeable. Workspace syntax, peer resolution, overrides, patching, script security, and immutable install flags differ by manager/version. Team documentation should name exact commands and expected runtime versions.

Interview questions

  1. What does a package manager do beyond downloading packages? Resolves a graph, materializes it, manages metadata/lockfiles, and runs scripts.
  2. Why commit a lockfile? To share exact resolved versions and graph metadata across installs.
  3. What is a phantom dependency? Code imports a package it did not declare, often working only due to hoisting.
  4. Why pin the package-manager version? Lockfile and install behavior can change across releases.
  5. Are package managers interchangeable? No; formats and resolution/install policies differ.

References