Dormant at the core: Inactivity, dependence and exit among the most downloaded npm packages

Modern software is rarely built from scratch. Instead, it is assembled like a massive structure made of pre-fabricated parts, where each part is a small piece of code written by someone else. In the world of JavaScript, the system that holds these parts together is called npm, a digital warehouse where developers download these code packages to build everything from websites to mobile apps. Most of these parts are maintained by volunteers who work on them in their spare time. When a volunteer stops working on a part, that piece of code becomes dormant. It does not break immediately, but it stops receiving updates, bug fixes, or security patches. This creates a hidden risk: if a widely used part stops being updated, the thousands of projects that rely on it are left with a component that cannot be repaired if something goes wrong. The question is not just whether these parts stop being updated, but how many of them are actually dormant, how many people are using them, and whether the people using them know to stop using them.

A researcher named Revanth Krishna Maddula set out to examine the most popular parts in this system. He looked at nearly sixteen thousand packages that are downloaded at least one million times every week. These are the core components of the JavaScript ecosystem, the parts that hold the most weight. By studying the complete history of these packages up to October 2026, he wanted to see how many had stopped releasing new versions, how many people were still using them, and how the system reacted when a part went silent. The study focused on a specific definition of dormancy: a package that had not published a stable, finished version in the last two years. This timeframe was chosen to distinguish between parts that are simply finished and parts that have been abandoned.

The findings reveal that dormancy is far more common than many might expect. At the end of the study period, nearly thirty-five percent of these top packages had not released a new version in two years. This silence was not limited to obscure or rarely used tools; it reached the very heart of the system. Among the one hundred most downloaded packages, twenty-six percent were dormant. In fact, some of these silent packages had not been updated for more than eight years. Despite this widespread inactivity, the silence was almost always unbroken. When the researcher checked the public notes attached to these packages, known as README files, he found that only about three percent of the dormant packages explicitly stated that they were no longer being maintained. Most of the time, the code simply stopped changing, leaving users to guess whether the project was finished or forgotten.

The danger of this silence is that the active parts of the system are deeply connected to these dormant ones. The study mapped the relationships between the packages and found that more than a quarter of the actively maintained packages depended directly on at least one dormant package. Some of these silent packages were so central that they were reachable through chains of dependencies from more than a thousand other high-traffic packages. Many of these were small, simple tools that might have been completed years ago, but others were substantial modules that formed the foundation for much of the software tooling. The problem is that users cannot easily tell the difference between a tool that is finished and one that has been abandoned, because the system offers no clear signal to distinguish the two.

When a dependency goes dormant, the people using it do not usually react quickly. The study tracked how long it took for users to remove a dependency on a package that had stopped updating. Over a two-year period, users removed only about twenty-seven percent of their dependencies on dormant packages. This rate was only slightly higher than the rate at which they removed dependencies on active packages, suggesting that the mere fact that a package had stopped updating was not enough to prompt action. The researchers tested whether different types of warnings changed this behavior. They found that a note in the project's documentation had no detectable effect on whether users removed the package. The only signal that reliably caused users to act was an official deprecation notice issued by the registry itself. When a dormant package was formally marked as deprecated by the system, users removed dependencies on it at a rate of sixty-five percent. This official warning, which appears to developers when they install the software, was the only mechanism that successfully prompted the ecosystem to move away from the silent code.

There is also a security dimension to this dormancy. While most dormant packages did not have known security flaws in their latest versions, those that did were in a precarious position. The study found that a small number of dormant packages carried known vulnerabilities that could no longer be fixed by their original maintainers. Because the code was no longer being updated, these flaws could not be patched from the top. Users who relied on these packages had to either remove them, replace them with different tools, or fix the security holes themselves. This situation highlights a critical gap in the system: when a widely used part stops being maintained, the responsibility for its safety shifts entirely to the people who use it, often without their knowledge.

The study concludes that dormancy is a normal, silent state for a large portion of the software ecosystem. It is not necessarily a defect if a small tool is finished, but the lack of communication makes it impossible for users to know the difference. The research suggests that the current system relies too heavily on users guessing the status of their tools. The most effective way to manage this risk is for maintainers to use the official deprecation mechanism when they stop working on a package, ideally pointing users to a replacement. For the ecosystem to remain healthy, the registry needs to make dormancy and deprecation more visible, ensuring that the signal reaches the developers who need to see it before a silent package becomes a problem.