How it works...
The top two results of the npm search are hsl-to-rgb and hsl-to-rgb-for-reals. The first result is unusable because the author of the package forgot to export it and is unresponsive to fixing it at time of writing. The hsl-to-rgb-for-reals module is a fixed version of hsl-to-rgb.
This situation serves to illustrate the nature of the npm ecosystem.
On the one hand, there are over 200,000 modules and counting, and on the other, many of these modules are of low value. Nevertheless, the system is also self-healing in that if a module is broken and not fixed by the original maintainer, a second developer often assumes responsibility and publishes a fixed version of the module.
When we run npm install in a folder with a package.json file, a node_modules folder is created (if it doesn't already exist). Then, the package is downloaded from the npm registry and saved into a subdirectory of node_modules (for example, node_modules/hsl-to-rgb-for-reals).
Our installed module doesn't have any dependencies of its own. But if it did the sub-dependencies would be installed differently depending on whether we're using version 2 of npm or version 3 and higher.
Essentially npm 2 installs dependencies in a tree structure, for instance node_modules/dep/node_modules/sub-dep-of-dep/node_modules/sub-dep-of-sub-dep. Conversely npm 3 and up follows a maximally flat strategy where sub-dependencies are installed in the top level node_modules folder when possible. For example node_modules/dep, node_modules/sub-dep-of-dep and node_modules/sub-dep-of-sub-dep. This results in fewer downloads and less disk space usage. Version 3 and higher of npm resorts to a tree structure in cases where there's two version of a sub-dependency, which is why it's called a "maximally" flat strategy.
Typically if we've installed Node 4 or above, we'll be using npm version 3 or higher.