npm is the default because Node ships it
npm handles the ordinary JavaScript package loop: install dependencies, record resolved versions, run scripts, inspect packages, and publish releases to a registry. Most Node.js distributions bundle it, so a new contributor can usually run the command without choosing another package manager first. It also ships npx for one-off commands and supports any compatible registry, not only the public npm service.
The CLI now reaches well beyond npm install. It has workspace commands, clean CI installs, dependency auditing, provenance verification, package queries, SBOM output, and controls for dependency install scripts. The repository reflects that breadth. Our checkout contained 4,860 files and about 362,925 lines of source, arranged as a monorepo with workspaces for components such as Arborist. This is infrastructure software, even if most users meet it as one command bundled beside Node.
The 337 MB install ended with 22 known vulnerabilities
Our sandbox installed commit b317f16 in 28 seconds. The install pulled 1,265 packages and occupied 337 MB on disk. There was no root build script or target, so we skipped a build rather than inventing one. The checkout itself occupied 312.2 MB before that install. npm audit then reported 22 known vulnerabilities: 1 critical, 13 high, 7 moderate, and 1 low.
Those figures describe npm's development tree, not every application that uses npm. They still matter if you plan to contribute, fork the CLI, or run its source in a controlled environment. A package manager sits directly on the path that retrieves code and runs lifecycle scripts. Twenty-two advisories in its own dependency graph deserve review, especially the critical and high findings. The supplied measurement does not identify affected packages or prove exploitability, so it cannot support a stronger claim.
What happened when we ran it
Our run used Node 22 in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. Installation succeeded in 28 seconds. With no build target available, the next meaningful check was the repository's test command. It failed with exit code 1 after 160 seconds.
The log reported 1 failed test out of 124. Its final lines show tests 114 through 124 passing, including the stage and trust command cases, followed by failed 1 of 124 tests. The tail does not name the failed case or show its exception. We can say the complete suite was not green at commit b317f16; blaming Node 22, the container, a service, or a particular module would go beyond the evidence.
Lockfiles make CI predictable only when flags match
npm ci requires an existing package-lock.json, removes an existing node_modules, and refuses to update a lockfile that disagrees with package.json. That is a useful release property: CI either installs the recorded tree or stops. There is a catch in npm's own documentation. If the lockfile was created with a tree-shaping option such as legacy-peer-deps or install-links, CI needs the same option, usually committed in the project's .npmrc.
Auditing also depends on the configured registry. npm sends the dependency description to that registry and calculates possible remediations from the response. A normal result may still require manual changes, and the command exits nonzero when findings meet the configured threshold. In our source checkout, that process returned 22 findings. Teams using a private registry should verify its audit endpoint behavior instead of assuming it matches the public service.
Install scripts now require an explicit project decision
The v12.2.0 documentation describes npm approve-scripts, which writes decisions into the project's allowScripts field. Dependency install scripts are blocked by default unless an entry permits them, and approvals can be pinned to the installed package version. Global installs and npx cannot write a project policy, so they use an install-time flag or user-level configuration instead. That difference is easy to miss when a local project install works but a global tool does not.
Release v12.2.0 was published on September 30, 2026 and added OIDC authentication for distribution tags. The repository was pushed again on October 1. GitHub listed 812 open issues and pull requests on October 5, split by search into 634 issues and 174 pull requests. That is a large queue, but the recent release, push, and active dependency pull requests show ongoing maintenance rather than an idle repository.
npm favors compatibility over a new package-store model
npm is the sensible baseline when contributors already have Node and the project commits a compatible lockfile. Workspaces cover common monorepo linking and command execution, while npm pack --dry-run lets maintainers inspect published files before upload. The public registry integration also gives the CLI a direct path for login, publishing, advisory checks, signatures, and provenance attestations.
pnpm is the sharper choice when disk sharing and strict dependency linking are central. Yarn earns a trial when Plug'n'Play or its plugin model solves a concrete team problem. Bun combines package installation with a runtime, bundler, and test runner, which changes more of the toolchain at once. None is a drop-in decision based on an isolated timing claim. Run each against your lockfile, native dependencies, workspace scripts, and deployment image.
Artistic License 2.0 and current releases make npm a safe standard choice
The package declares Artistic-2.0, and the repository license spells out separate terms for npm's application code, dependency licenses, registry service, branding, and bundled Node references. Organizations distributing a modified CLI should read those conditions rather than treating the registry's availability as part of the source license. The 26 CI workflow files and late-September v12.2.0 release point to a mature maintenance process.
Our result still puts a boundary around that confidence. Installation worked, but 1 of 124 tests failed and the audit returned 22 findings. For ordinary Node projects, npm remains the least surprising default because it arrives with the runtime and speaks the registry's native workflow. For a fresh monorepo or a maintained fork, compare it with pnpm and Yarn, then require a clean test and advisory review before standardizing.