left-pad (2016)¶

The Lesson: Transitive dependencies are invisible risk. Trivial code still has dependency weight.

What Happened¶

On March 22, 2016, Azer Koçulu unpublished all 273 of his npm packages.¹ One of them was left-pad—an 11-line function that pads strings with spaces or zeros on the left side.

Within minutes, builds started failing across the internet. Babel broke. React Native broke. Thousands of projects that had never heard of left-pad suddenly couldn't build.²

The function itself was trivial:

function leftPad(str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

Eleven lines. No dependencies of its own. And yet when it disappeared, the JavaScript ecosystem ground to a halt.

Why It Happened¶

Koçulu's dispute wasn't about left-pad. He'd created a package called kik, and Kik Interactive (the messaging company) sent him a takedown request through npm. When npm complied—transferring the package name to the company—Koçulu rage-quit, unpublishing everything he'd ever contributed.¹

The left-pad package had been downloaded 2.5 million times in the month before its removal.³ But almost nobody installed it directly. It came in as a transitive dependency—a dependency of a dependency of a dependency. Most developers had no idea it existed in their projects.

Why It Mattered¶

This incident exposed several uncomfortable truths about modern software development:

The dependency graph is invisible. Developers were adding packages they knew—Babel, React—without realizing those packages depended on hundreds of other packages. The average npm project in 2016 had over 100 transitive dependencies. Today it's often closer to 1,000.⁴

Trivial packages accumulate. The JavaScript ecosystem had developed a culture of publishing tiny single-function packages. is-odd, is-even, is-number. Individually reasonable, collectively they created a fragile web of dependencies that any single maintainer could disrupt.

Unpublishing was too easy. Before this incident, npm allowed package authors to unpublish at will, regardless of how many projects depended on their code. The ecosystem had built critical infrastructure on assumptions that turned out to be false.

There was no warning. Projects didn't fail gracefully. They just stopped building. No fallback, no cached copies, no time to react.

What Changed¶

npm changed its unpublish policy within hours of the incident.⁵ Packages with dependents, or packages older than 24 hours with significant downloads, can no longer be unpublished without npm support intervention. Once code is in the registry and being used, it stays.

The incident also sparked conversations about:

• Dependency hygiene — Do you really need a package for 11 lines of code?
• Vendoring and caching — Should your builds depend on external registries being available?
• Lock files — At least know which versions you depend on, so you can debug when things break.

Timeline¶