The Anti-Dependency Manifesto

This document explains why we changed the dependency model, what we built instead, and what remains in the bill of materials. The bill of materials is short — that's the point.

1. The Problem

Run npm install on a modern web application and it can pull in hundreds or thousands of packages. You selected a small fraction of them directly. The rest arrived through the transitive graph, maintained by people whose code your team and security auditors are unlikely to have read. It still runs in production with the privileges of code you wrote yourself.

Any one of those strangers can break you. In 2016 the author of left-pad — eleven lines of JavaScript — unpublished it after a naming dispute and broke builds across the industry, Babel included, within minutes.

None of this is controversial; it's just how the industry works. The collective decision, made long ago, was that the speed you get from package managers is worth the risk of running unaudited code at every layer of the stack. And for most of the history of the field, that was a reasonable bet: teams were large, engineers were expensive, and writing everything yourself was economically absurd.

We think that calculation deserves to be made again. Code-generation tools changed implementation costs quickly, while the industry’s dependency habits changed slowly.

2. What Changed

Two things, at roughly the same time.

First, supply-chain failures stopped looking like edge cases. Log4Shell (CVE-2021-44228) showed how one flaw in a transitive dependency could expose a vast population of Java applications. The XZ Utils backdoor (CVE-2024-3094) demonstrated a slower route: earn the trust of a foundational project, then use that position to plant a backdoor.

Package distribution created other paths. A maintainer account was socially engineered away in the event-stream incident; a maintainer turned on users in node-ipc; the LiteLLM compromise turned a maintained Python library into a credential harvester; and the PyTorch dependency-confusion attack hijacked installs by publishing a package under a name the installer preferred.

By September 2025, the Shai-Hulud worm was republishing itself through infected developer credentials into more than 500 packages. That same month, a phishing email compromised debug, chalk, and sixteen other packages and introduced a crypto-wallet drainer into widely installed npm code.

The volume is also growing. Sonatype counted more than 454,600 new malicious packages published in 2025, over 99% of them on npm. In May 2026, the TrapDoor campaign planted credential- and crypto-stealers across npm, PyPI, and crates.io. The TanStack compromise reached libraries reporting more than 518 million weekly downloads.

Cool-down windows, staged releases behind interactive 2FA, and heightened vigilance are sensible countermeasures. They manage the risk of running code maintained outside your team; they do not remove the underlying relationship.

Second, the economic case changed. For a well-specified algorithm or protocol, language models can reduce implementation time enough that build-versus-adopt deserves a fresh evaluation. They do not remove specification work, testing, review, or human responsibility. They change the cost of reaching those stages.

Which leaves the industry carrying all of the risk of the dependency model, and none of the economics that used to justify it.

3. What We Built

So we wrote the whole stack. The Virtually Unlimited Library is hundreds of modules covering what modern applications actually need — cryptography, TLS, networking, compression, data formats, image processing, documents, databases, authentication, science and mathematics, geospatial, finance, machine learning — each one written from the specification, tested against reference implementations, and benchmarked against the incumbent it replaces. It has zero external dependencies.

That list is not exhaustive. The versioned module index, benchmark material, and supporting test evidence are available on request. The bill of materials below is the bounded claim this page asks readers to evaluate today.

4. The Bill of Materials

Here is the complete bill of materials for a production application built on the Virtually Unlimited Library:

Four entries. One is yours, one is ours, one is the language runtime, and one is the operating system. There is no application-package graph to resolve or lock. Updates to our code, the runtime, and the operating system still matter, but the audit surface is explicit and bounded by the table.

5. The Development Model

Removing the dependencies also changes where the engineering hours go. Nobody here spends time:

• resolving version conflicts between transitive dependencies;
• working out whether a security advisory three levels down actually affects the application;
• upgrading a dependency because a dependency of that dependency shipped a breaking change;
• chasing behavior differences between the version tested locally and the version CI installed, because the lock file wasn't committed;
• evaluating competing libraries, learning their API surface, and then learning their undocumented behavior where the documentation turns out to be wrong.

Add it up and it is not a rounding error. Removing that work returns engineering time to implementation, testing, and product decisions. It is one reason a small team can sustain a wider surface area.

6. Objections We Have Heard

"You can't possibly write everything well."

True — if "everything" means every piece of software ever, and "well" means best in the world. The relevant answer varies by domain and should be judged from domain-specific tests, compatibility results, and reproducible benchmarks rather than one universal performance claim. Our standard is product code, not prototypes, and there are areas where hand-tuned vendor code remains ahead.

"Open-source libraries are battle-tested."

Some are. Plenty are maintained by one unpaid person with no security review process at all. The XZ backdoor sat in a "battle-tested" library for over two years before anyone noticed. Battle-tested measures how many people run the code, not whether anyone has read it.

"What about updates and security patches?"

When we find a vulnerability, we fix it, and the fix ships in the next release. One place to look, one update to apply, no transitive fallout. That's simpler than the status quo, not harder — and it's why our upstream CVE count is zero.

"This doesn't scale."

Scale should be judged from the module inventory, test corpus, maintained surface area, and shipping applications. We provide the versioned inventory and supporting evidence on request.

"NIH syndrome."

Not Invented Here is a fair charge when the motive is ego, or not knowing what already exists. Our motive is ownership: choose our changes deliberately, test the behavior we ship, and compare it against the implementations it replaces.

7. What This Means

We're not telling every company to rewrite its dependency tree. We're pointing out that the cost of doing so collapsed, the risk of not doing so keeps growing, and the crossover happened recently enough that most of the industry hasn't noticed yet.

We built the library because we needed it. We think others need it too.

And can it run DOOM? Of course.

We are available for questions.

Start with the thesis →