Spec
npm's installation mechanism uses a nested
directory structure relying on Node's node_modules fallback.
Due to npm's popularity as a package manager, technology, as well as a company, this algorithm has been popularized as the only "viable" option for installing Node.js packages in the past.
While npm 3 famously introduced a flattened dependency graph, a lot of the original problems remain, including, but in no way limited to:
- Unpredictable dependency graphs after subsequent installations
- Significant performance penalty due to "flattening" of dependency graph
- Redundant dependencies due to partially flattened dependency graph
ied, an alternative package manager
for Node.js, as well as its fork pnpm, rely on a different, symlink-based
algorithm, which aims to address most of these issues.
As part of this document, this algorithm will be formally specified and documented.
In order to understand the proposed algorithm, it's essential to understand Node's module system and way of resolving dependencies.
Node looks for dependencies in node_modules, when the specified dependency
couldn't be located, the parent directory's node_modules folder will
recursively be traversed until the root of the file system is reached.
This enabled implementors of package managers to create circular dependency
graphs by relying on Node's require call "falling back" to the parent
directory.
npm exploits this implementation by creating nested dependency graphs.
Especially npm 2 famously created deeply nested node_modules directories that
caused issues due to a limit on the maximum possible file system path under
Windows. ConSequently, npm 3 introduced an additional step following a
successful package installation that flattened the dependency graph in question.
