Movement 0deps: Local Dependencies and Immutable Contracts
Software developers often install hundreds of external libraries in every project. Modern frameworks rely on thousands of transitive dependencies. This means your application runs code from hundreds of unknown contributors.
This speed creates a massive risk for your software supply chain.
The 0deps movement asks a simple question: What if your application only ran code you actually control?
Every dependency increases your attack surface. It can introduce security holes, get abandoned, or break your code with a new update. You lose control over the code running in your production environment.
In the 0deps model, you bring all dependencies directly into your project repository. You do not download them dynamically during installation. Everything needed to build and run your app is already there.
This approach provides several benefits:
- Reproducible builds
- Less reliance on external package registries
- Centralized security audits
- Better predictability
- Lower supply chain risk
The core principle is not to stop code from changing. Algorithms and security fixes must evolve. What stays stable is the public contract.
Each library exposes a carefully designed interface.
- authenticate()
- createSession()
- verifyPasskey()
These functions define a contract. That contract never changes. You can rewrite the underlying code or replace the library entirely. The rest of your application stays the same because it only talks to the contract.
When a vulnerability appears, you fix it internally. You update the implementation behind the interface. The public API remains identical. Your application keeps working without code changes.
This structure uses an internal adapter to isolate external code: Application ↓ Public Interface ↓ Adapter ↓ Implementation
If an external library disappears, you only update the adapter. No other part of your app breaks.
The 0deps movement does not fight open source. It changes how you use it. Libraries become integrated components that you audit and version yourself.
This creates software that lasts for decades. Implementations change, but your contracts remain. This stability makes your software predictable and resilient.