3 ms·

There are several methods you can end up with extra/redundant NPM libraries. At my last company, we had a cleanup project which ended up with a similar number

There are several methods you can end up with extra/redundant NPM libraries. At my last company, we had a cleanup project which ended up with a similar number of libraries removed over the epoch which cleaned up+upgraded NPM dependencies. (1) the number might be multiplied if one library is removed from each package of a monorepo. Eg. If there are 10 packages in the monrepo, then you only need to remove on average 12 NPM libraries. (2) sometimes updating the upstream libraries to newer versions reduces the size of the upstream dependency tree. Similarly, it was more common for NPM libraries to declare a dependency, whereas more mature libraries might move those to devDependencies or peer dependencies. (3) removing unnecessary / unused code can unblock you so you can remove a library which is no longer referenced in your repo. (4) sometimes programmers over engineer early. Sometimes your product requirements change. Reviewing your codebase after each of these conditions allows you to decide if you still need all of the code/dependencies. (5) as the NodeJS runtime changes, sometimes you can migrate from a 3rd party library to use the built-in tool (we did this with BluebirdJS / Promises).

hinkley 1y ago
Older versions of node especially had problems resolving mutual secondary dependencies efficiently, though all versions struggle to an extent. Sometimes you have to declare a dependency at the top level in order to force the most common one to be installed at the root, so the less common one gets installed in all of the places it is needed rather than sharing the single one at the root. The likelihood you ever get back to zero copies of that module are fairly low, unless it has become persona non grata for some reason (leftpad). So it's easy to forget to back out the disambiguation entry at the top level. Especially if git blame doesn't make it dead apparent (see also people manually adding entries in non-alphabetic order so that the next 'npm install --save' rearranges five lines).
- thephyber 1y ago
  Yeah, agree. I think the best solution for the ecosystem might be to have best practices NPM conventions for minimizing dependency redundancy explosion, then forking/migrating most of the popular libraries to use these newer best practices libraries. Also, it’s best practice to freeze your versions+lockfile, but that also means that version upgrades are manual and expensive friction. If there is a way to reduce the frequency of NPM library version bumps, then the cost of upgrading dependencies drops.

hinkley 1y ago

Older versions of node especially had problems resolving mutual secondary dependencies efficiently, though all versions struggle to an extent. Sometimes you have to declare a dependency at the top level in order to force the most common one to be installed at the root, so the less common one gets installed in all of the places it is needed rather than sharing the single one at the root. The likelihood you ever get back to zero copies of that module are fairly low, unless it has become persona non grata for some reason (leftpad). So it's easy to forget to back out the disambiguation entry at the top level. Especially if git blame doesn't make it dead apparent (see also people manually adding entries in non-alphabetic order so that the next 'npm install --save' rearranges five lines).

thephyber 1y ago
Yeah, agree. I think the best solution for the ecosystem might be to have best practices NPM conventions for minimizing dependency redundancy explosion, then forking/migrating most of the popular libraries to use these newer best practices libraries. Also, it’s best practice to freeze your versions+lockfile, but that also means that version upgrades are manual and expensive friction. If there is a way to reduce the frequency of NPM library version bumps, then the cost of upgrading dependencies drops.