NPM JavaScript registry mishaps: What to do

Concerned users can set up their own backup system if they don’t trust the steps NPM Inc. has taken to prevent problems

The NPM registry of JavaScript packages has become a critical cog in the language’s ecosystem, letting developers discover and use reusable code packages. But for developers worried about systems crashing because packages they depend on were removed from the registry, there are not a lot of options other than having your own backup system to cache packages.

The registry holds more than 600,000 packages, with 3.6 billion downloads a week. Smooth operations of applications can depend on packages in the registry staying active. One incident on Jan. 6, 2018, caused by a user being misidentified as a spammer, had NPM Inc. operators scrambling to remedy the situation on a Saturday. In March 2016, the deletion of a 17-line package, called left-pad, broke dependencies with other projects, including the Babel JavaScript compiler.

Officials at NPM Inc. emphasize that such issues around package dependencies have been far and few between, with just two incidents that have come to their attention. But the rarity of package removals presenting problems is of little consolation to users of packages that could be affected.

To lessen risks, users can deploy backup systems

NPM Inc. advises that users who cannot afford to have their installation go away for any amount of time can run an instance of NPM Enterprise, which caches local dependencies. A Dockerized version of an NPM private registry, NPM Enterprise requires a paid subscription. NPM Enterprise can be run on your own servers or in the cloud. NPM Inc. also plans to offer an option for NPM Inc. itself to host a customer’s single-tenancy private registry.

Another backup option is the open source NPM clone Sinopia. Users still would have to pay to run the infrastructure for this themselves.

What NPM Inc. has done to reduce the risk

NPM has taken steps to better ensure uptime on its system.

Since 2016, users cannot delete packages once they have been published for more than 24 hours. NPM staff evaluate deletion requests on a case-by-case basis to assess risks involved in removal. In many cases, deprecating the package rather than deletion solves a user’s need. Deprecation leaves the package on the registry but hides it from search, and users are advised to not use it.

Spam has become a “far larger problem” in the last year, an NPM Inc. incident report said. That’s why NPM Inc. has developed systems to analyze package contents as they are published and flag users associated with spam. NPM Inc. itself also removes other “problematic” content, including malware. Packages that either are harmful or violate the law have to be removed. NPM Inc. has tools to remove packages and user accounts in a single action.

Also, when NPM Inc. responds to a user’s request to delete a package, a replacement is published as a security placeholder to alert those who relied on the package that the original is no longer available. Others are prevented from publishing new code that uses that package’s name. But at the time of the Jan. 6 incident, there was no policy to publish placeholders for packages deleted as spam. Since then, NPM Inc. has instituted a 24-hour cooldown on republication of any deleted package name. NPM Inc. also plans to improve tools for reverting mistaken deletions.