The Death of node_modules: Why We Built Everything From Scratch

The Elephant in Your Repository

Run npx create-react-app my-app and wait. In under a minute, you will have downloaded over 1,400 packages totaling roughly 200MB of code you have never read and never will. Your fresh, empty application already has more transitive dependencies than most operating system kernels have source files. Welcome to modern JavaScript development.

This is not a theoretical problem. The average enterprise Node.js project carries between 800 and 2,000 transitive dependencies. Each one is a potential vector for supply-chain attacks, license violations, breaking changes, and silent regressions. And yet, the JavaScript ecosystem has collectively decided this is acceptable.

When we started building HBForge at HyperBridge Digital, we made a decision that most people thought was insane: zero external dependencies. Not "minimal" dependencies. Not "carefully vetted" dependencies. Zero. Every line of code in the framework is written, audited, and maintained by our team.

The Supply-Chain Nightmare Is Not Hypothetical

If you think supply-chain attacks are rare, consider the last few years alone:

• event-stream (2018) — A maintainer handed off a popular package to a stranger who injected cryptocurrency-stealing malware. 8 million weekly downloads compromised.
• ua-parser-js (2021) — Hijacked to distribute cryptominers and password stealers. 7 million weekly downloads affected. Used by Facebook, Amazon, Google, and Microsoft.
• colors.js / faker.js (2022) — The maintainer deliberately sabotaged his own packages, injecting infinite loops. Millions of CI/CD pipelines broke overnight.
• node-ipc (2022) — The maintainer added code that wiped files on machines with Russian or Belarusian IP addresses. This was a direct dependency of Vue CLI.

Each of these incidents affected millions of developers and production systems. And these are only the ones we know about. The uncomfortable truth is that most supply-chain compromises go undetected because nobody is reading the code in their node_modules folder.

The Audit Theater

Run npm audit on any non-trivial project and you will see a wall of vulnerabilities. Most teams do one of three things:

1. Ignore the warnings entirely (the most common approach)
2. Run npm audit fix --force and pray nothing breaks
3. Spend days manually resolving conflicts between nested dependency versions

None of these are engineering. They are coping mechanisms. The fundamental problem is that when you depend on 1,200 packages, you cannot meaningfully audit any of them. You are accepting risk you cannot quantify.

What Zero Dependencies Actually Means

HBForge is 35,762 lines of JavaScript across 15 modules. Every line is written by HyperBridge Digital engineers. There are no external dependencies, no transitive dependencies, no phantom packages hiding three levels deep in your dependency tree.

Here is what a package.json looks like with HBForge:

Compare this to a standard React + Express stack. Here is what you are actually installing:

The Version Conflict Maze

Dependencies breed dependency conflicts. Package A requires lodash@4.17.21. Package B requires lodash@4.17.15. Package C requires a fork of lodash. Now you have three copies of the same library in your bundle, each slightly different, each adding to your bundle size, and each potentially behaving differently at runtime.

With HBForge, version conflicts are structurally impossible. There is one package. It either works or it does not. You never spend a Friday afternoon debugging why semver resolution picked the wrong version of a transitive dependency you did not know existed.

But Can You Really Replace 60+ Packages?

This is the question we hear most. The answer is: we already have. HBForge's 15 modules cover the same surface area as over 60 npm packages:

• forge/client replaces React, React Router, Redux, Zustand, Emotion, TanStack Query
• forge/server replaces Express, Fastify, ws, Apollo Server, BullMQ, node-cron
• forge/schema replaces Zod, Yup, Joi, validator.js
• forge/animate replaces Framer Motion, GSAP, Motion One, auto-animate
• forge/data replaces Prisma, Drizzle, Knex, node-pg-migrate
• forge/test replaces Jest, Vitest, Testing Library, Supertest

Each module is designed to interoperate perfectly with the others. There are no integration gaps, no version mismatches between complementary libraries, and no "glue code" required to make things work together.

The Real Cost of "Free" Dependencies

Open-source packages appear free, but the total cost of ownership is substantial:

• CI/CD time: Installing 1,200 packages adds 30-90 seconds to every pipeline run. At 50 builds per day, that is 25-75 minutes of pure waiting, every single day.
• Security review: Enterprise teams spend 2-4 hours per week triaging npm audit findings. Most of these are false positives or unfixable without breaking changes.
• Upgrade maintenance: Major version bumps in transitive dependencies cascade unpredictably. A single Webpack 5 migration took some teams weeks.
• Bundle bloat: Tree-shaking cannot eliminate code from packages that use dynamic requires or side effects. The average production bundle includes 40-60% dead code from dependencies.

HBForge eliminates every single one of these costs. Install time is under 2 seconds. There are no audit findings. Upgrades are a single version bump. The entire framework tree-shakes cleanly because we control every line.

How We Built It

Building a zero-dependency framework is not about rejecting the ecosystem out of principle. It is about understanding that every dependency is a liability, and asking: can we own this instead?

For each module, we studied the best existing implementations, identified the essential complexity (the parts that are genuinely hard), and built purpose-built solutions that are smaller, faster, and more cohesive than the originals. We did not port or fork. We rewrote from first principles.

The result is a framework where every piece knows about every other piece. The router knows about signals. The server knows about the schema validator. The animation engine knows about the component lifecycle. This deep integration is only possible when you own the entire stack.

"The best dependency is the one you don't have. The second best is the one you wrote yourself."

Try It Yourself

The entire HBForge source is auditable. You can read every line in an afternoon. Try doing that with your current node_modules folder.