Left-pad in 2016: what 11 lines taught the npm ecosystem

On 22 March 2016, Azer Koçulu unpublished the left-pad package from npm, and thousands of projects that depended on it, including Babel and React, failed to build or install. The final version was 11 lines of code. npm restored it from a backup about two hours later and changed its unpublish policy.

What happened

Per Wikipedia, Koçulu owned the left-pad package and also the kik package name on npm. Kik Interactive asked him to give up the name over trademark concerns, and npm, Inc. manually transferred it to the company. Koçulu then ran a command, supplied by npm's CEO, that deleted all 273 modules he had registered.

Projects depending on left-pad received 404 errors. Note the article's account of timing: it says npm restored version 0.0.3 about two hours after removal, while another Wikipedia article about npm says the package was republished about three hours later. Sources differ, so treat the exact gap as roughly two to three hours.

The policy change

npm changed its policy so that a package cannot be removed if more than 24 hours have passed since publication and at least one other project depends on it. It later released a policy to prevent malicious takeovers in similar name disputes. Community manager Ashley Williams said npm had failed to protect the community.

What it shows

• Tiny packages carry big dependencies. Eleven lines were enough to stop large projects.
• Deletion is a failure mode. Supply chain risk includes a package vanishing, not only a package turning malicious.
• Registries make policy choices. Rules about who may remove or transfer a name shape your risk.

What to do about it

• Use a lockfile, so your build uses known versions.
• Keep a mirror or cache of dependencies for critical builds.
• Know your direct and transitive dependencies. An inventory is the first step.
• Ask whether you need a package for a tiny function you could write and test yourself.

That last point is a trade-off, not a rule. Writing your own code has costs too. The point is to decide on purpose.

A small resilience checklist

Before your next release, confirm four things. Your lockfile is committed and used in CI. A cached or mirrored copy of your dependencies exists for the build that matters most. You can name the five dependencies whose disappearance would stop that build. And you know who to ask if a registry changes a policy. None of this is heavy work, and it turns a surprise outage into an inconvenience. It also helps for reasons unrelated to security, such as reproducing an old build for a customer.

Quick check

Safeguard's SBOM and dependency scanning list what your build depends on, and there is a free scan at gold.safeguard.sh/scan.

Sources

• Left-pad
• npm

Last reviewed: 19 October 2026.