Why FileMayor has three dependencies (and you don’t need more).

Most modern tools are dependency forests. You install one package, and it quietly pulls in hundreds more — each with its own assumptions, risks, and maintenance burden. This is not a moral failing. It is how software has evolved: modular, composable, and fast to build.

But it comes at a cost.

Every dependency you add becomes part of your trusted computing base. Every transitive dependency becomes something you are implicitly executing on your machine. And if your tool touches the filesystem — renaming, moving, deleting files — that trust boundary matters.

Minimize the number of things that can break, misbehave, or be compromised between intent and execution.

FileMayor ships with three runtime dependencies: electron-updater, tar, yauzl. That is the entire list.

Why this matters

1. Supply chain risk is real

When you install a tool globally, you are not just installing its code — you are installing its entire dependency tree. In some cases, that tree spans hundreds of packages.

Each one:

• can publish a malicious update
• can be abandoned and later hijacked
• can introduce subtle bugs or breaking changes

Reducing dependencies does not eliminate risk. But it shrinks the attack surface dramatically.

2. Determinism over convenience

A smaller dependency set means fewer version conflicts, fewer breaking upgrades, and more predictable builds. When FileMayor analyzes or modifies your filesystem, it does so in a controlled and auditable environment. There are fewer moving parts, and therefore fewer surprises.

3. Performance is a side effect

Lean dependencies reduce install size, improve startup time, and lower memory overhead. But performance is not the primary goal. It is a consequence of restraint.

Why not zero?

"Zero dependency" is a popular claim. It is also often misleading.

FileMayor uses three carefully selected packages for specific, constrained purposes — update delivery and archive handling. Rewriting these from scratch would increase maintenance burden, introduce new untested code paths, and distract from the core problem FileMayor solves.

The goal is not purity. The goal is intentionality.

The real philosophy

FileMayor does not try to eliminate complexity. It tries to own it. Every dependency is understood, reviewed, and justified. Everything else is built in-house, where behavior can be reasoned about and controlled.

When you run FileMayor, you are not running a sprawling ecosystem of unknown code. You are running a focused tool with a narrow, deliberate surface area — designed to explain what it will do, give you control over how it does it, and execute safely with rollback.

In a world where software increasingly abstracts away its own complexity, FileMayor takes the opposite approach: make fewer assumptions, depend on fewer things, do the job well.