Everything Blocks Devs From Removing Their Own Npm Packages
Over the holidays, the npm package registry was flooded with more than 3,000 packages, including one called “everything,” and others named a variation of the word.
The package is quite aptly named as downloading “everything” will gradually pull in every single npm package that’s ever been published to the npmjs.com registry onto your computer, potentially making it run out of storage. But, that’s just the tip of the iceberg.
If you’re asking, “But who would install ‘everything’?”—that ignores a bigger side-effect of the package.
Since these 3,000+ packages manage to include every single npm package on the npmjs.com registry as their dependency, npm package authors who have ever published to the npm registry would now be unable to remove their packages at will, because of npm’s policy.
everything prevents you from unpublishing your packages
What may have started as a simple prank, ended up having bigger repercussions for all authors across the npm ecosystem.
Installing everything could have just caused your computer to potentially fall short of storage space and slow down, but the package’s mere existence on npmjs.com prevents authors—unrelated to this package whatsoever, from unpublishing their packages from the world’s largest JavaScript software registry.
The “everything” package has just 5 sub-packages, published under the “@everything-registry” scope, listed as its dependencies, BleepingComputer has observed.
(BleepingComputer)
These 5 packages, however, gradually manage to pull in every single package present on the entire registry as a dependency. For example, “everything” pulls in “@everything-registry/chunk-2,” which may further attempt to pull in several other packages by the same author, such as “@everything-registry/sub-chunk-1623.”
Each of these sub-packages (or “chunks” as the author calls them), ultimately includes about 800 npm projects as their dependency.
Considering the author of “everything” has published 3,000 plus such packages (chunks), each with hundreds of dependencies, a single `npm install everything` command will start resolving, what’s referred to as transitive dependencies, and end up downloading millions of packages.
gdi2290 aka PatrickJS who is behind this prank apologized for “any difficulties this package has caused,” and contacted npm admins to remedy the issue.
A preserved snapshot of the now-removed GitHub discussion is provided below:
“Imagine you did an experiment, published a package to NPM and now you want to remove your NPM package. You can’t do it if other packages are using it,” writes Jossef Harush, Head of Software Supply Chain Security at Checkmarx on the company’s blog.
Harush, who labeled this campaign, “dependency hell,” further states, “The problem is, since ‘everything’ relies on every package (including yours), your package gets stuck, and there’s some unknown package preventing you from removing it.”
The researcher drew comparisons between “everything” and the “no-one-left-behind” package published in January 2023 that attempted to pull off much the same stunt.
npm policy shift follows left-pad incident
Unlike some open-source software registries like Maven Central, which are immutable and generally prevent authors from removing their published components, npm and PyPI have traditionally allowed developers to delete, or “yank” their releases at will.
Following a 2016 incident though, that entailed left-pad’s author removing his npm package in protest, and breaking a large part of the internet, npm made it more difficult for authors to unpublish packages.
One such policy change involved allowing authors to unpublish packages only if no other package on the npm registry is dependent on it.
Ironically, this policy has also left PatrickJS, the author of “everything,” unable to easily remove his prank packages, given the extensively long dependency chain he has setup.
BleepingComputer observed, as of this morning, while “everything” continues to live on the registry, the thousands of “@everything-registry” scoped packages used by it have now been made private, potentially resolving the issue.