What actually happened
On 22 March 2016, Azer Koçulu — a Turkish open-source developer living in Oakland — woke up to an email from the legal department of Kik, a messaging app you may remember from around 2012. Kik wanted him to rename his npm package called kik, a lightweight scaffolding tool. Azer refused. npm’s then-management sided with the trademark holder and reassigned the package name.
Azer’s response was nuclear: he unpublished all 273 of his packages from npm. Most of them were tiny utilities. One of them was left-pad, a function that takes a string, a length, and a character, and pads the string from the left:
module.exports = leftpad;
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. And yet, within minutes, build systems around the world started failing with a message every JavaScript engineer who lived through it still remembers:
npm ERR! 404 ‘left-pad’ is not in the npm registry.
Why did eleven lines matter so much?
Because left-pad was a dependency of line-numbers, which was a dependency of Babel, the transpiler nearly every modern JavaScript project relied on. Through the transitive-dependency chain, left-pad was pulled by React, webpack, Ember, Atom, and many others. When it disappeared, every fresh npm install on any affected project errored out.
The outage lasted roughly two and a half hours. npm eventually took the unprecedented step of un-unpublishing the package — something that had never been done before and that required new policy to be written on the fly. They also added a 72-hour rule: you can no longer unpublish a package that has been public for more than 24 hours if anything in the registry depends on it.
The DevOps lessons that still apply
Ten years later, left-pad is taught in every software-supply-chain course for a reason. The technical lessons are cheap to restate — but hard to apply in practice.
1. Your build is only as stable as its weakest transitive dependency
If your package.json lists ten direct dependencies, your actual dependency graph is probably in the hundreds. Every one of them is a potential rug-pull, a potential typosquat, and a potential compromised maintainer account. Tools like npm audit, pnpm audit, Snyk, and Dependabot catch known CVEs, but they don’t catch the unknown unknowns.
2. Lock files are not a luxury
package-lock.json and yarn.lock didn’t exist in their current form in 2016. Today they are the reason you can sleep at night: a locked, hashed snapshot of every resolved version means a deleted or hijacked package won’t reshape your dependency tree on the next install. Commit your lock files. Verify them in CI.
3. Cache and vendor your dependencies
Running a private registry mirror (Verdaccio, JFrog Artifactory, GitHub Packages, AWS CodeArtifact) takes an afternoon to set up and turns a public-registry outage from a Sev-1 into a non-event. If caching is too much, at least configure your CI to use an offline cache.
4. Audit the size of tiny dependencies
An 11-line function does not need to be a dependency. Eleven lines is something a senior engineer could rewrite in the time it takes to run npm install. The JavaScript community’s love of micro-packages creates exactly the kind of surface area that left-pad exposed. Before you add a one-function dependency, ask: “Could I just copy this into utils/?”
5. Supply-chain attacks are no longer theoretical
left-pad was an accident. The incidents that followed — event-stream (2018), ua-parser-js (2021), XZ Utils (2024), multiple typosquat campaigns every month — were deliberate attacks. Left-pad was the wake-up call that made the industry take supply-chain security seriously, and it’s why SLSA, Sigstore and SBOMs exist today.
Why this story still matters for your certification
If you’re studying for a DevOps-adjacent cert — AWS DevOps Pro, Terraform Associate, CKA, or even CompTIA Security+ — the left-pad story is the perfect example to have in your back pocket. It shows up in questions about dependency management, CI/CD pipeline reliability, supply-chain risk, and immutable builds. Expect to see variations of:
- “Which of the following best mitigates the risk of a public package being removed upstream?” — answer involves artifact repositories and lock files.
- “What is a transitive dependency?” — a dependency-of-a-dependency, exactly like left-pad was under React.
- “What is an SBOM used for?” — to know, at any point in time, every package your software depends on, so a left-pad-style disappearance is observable.
One last thought
The funniest detail about left-pad is that the 11-line function was arguably buggy. It didn’t handle multi-character pad strings. It didn’t handle negative lengths. ECMAScript later added String.prototype.padStart() natively, rendering the whole thing obsolete. The entire world’s JavaScript infrastructure was briefly held together by a function that shouldn’t have been a package at all.
That, more than anything, is the real lesson. Modern software runs on stacks of tiny, fragile assumptions — and every DevOps engineer’s job is, fundamentally, to make those assumptions observable before they break.