Evolution of npm: From Nested v1/v2 to Flat v3 and Lock‑file v5

npm (Node Package Manager) is the essential package manager for Node.js and a cornerstone tool in front‑end development, used to create the node_modules directory, install dependencies, and manage them.

npm consists of two parts: a CLI (Command Line Interface) for publishing and downloading packages, and an online registry that hosts JavaScript packages. Alternatives such as Yarn, pnpm, cnpm, and tnpm also exist.

Node.js Module Ecosystem – A Double‑Edged Sword

Before Node.js, JavaScript lacked a module system. CommonJS introduced a small, single‑purpose module philosophy, which spurred rapid growth; by the end of 2021, npm hosted over 1.8 million packages. However, this rapid expansion created complex, redundant, and space‑inefficient dependency trees.

1. npm v1/v2 – Nested Dependency Management

The early versions used a simple nested structure: each module’s dependencies were placed in its own node_modules folder, leading to two main problems:

Redundancy – the same dependency could be installed multiple times, wasting disk space.

"Dependency hell" – deep, nested trees made maintenance, updates, and performance difficult.

Illustrations in the original article show the nested folder layout.

2. npm v3 – Flat Dependency Installation

To address redundancy and deep trees, npm v3 introduced a flattening algorithm that hoists sub‑dependencies to the top‑level node_modules directory. This reduces duplicate installations and speeds up resolution.

New issues introduced by flattening include:

Phantom (ghost) dependencies – packages not listed in package.json become usable, risking breakage when upstream modules change.

Multiple‑instance problems – different versions of the same package may still be installed when required by different top‑level dependencies.

Increased algorithmic complexity and performance overhead during installation.

Figures in the source depict the flattened structure and remaining duplicate installations.

3. npm v5 – Introduction of package‑lock.json

npm v5 added package-lock.json , which records the exact dependency tree, versions, source URLs, and integrity hashes. This brings two major benefits:

Installation speed – the lock file provides a pre‑computed dependency graph, reducing the need for recursive look‑ups.

Consistency – installations become deterministic, ensuring the same node_modules layout across environments.

Overall, the evolution from v1/v2 to v3 and v5 shows how the community continuously refines package management to balance simplicity, performance, and reliability, while acknowledging that no solution is perfect.

Conclusion

npm v1/v2 used nested management, causing redundancy and deep dependency trees.

npm v3 flattened dependencies, solving some problems but introducing phantom dependencies and residual duplication.

npm v5’s lock file improves speed and determinism.

Alternative tools (Yarn, pnpm, tnpm) address similar challenges with their own trade‑offs.

The ongoing evolution reflects the front‑end engineering community’s effort to improve package management.