Minimizing dependencies

Dependencies feel like speed.
They often become debt.

In user-owned workflows (like an Obsidian vault), every added package extends the trust chain beyond the primary author.

Two costs people underestimate

1) Maintenance cost

A dependency update can:

• break your build
• change behavior quietly
• force upgrades you did not ask for

2) Security cost

Transitive dependencies multiply quickly.
A single compromised package can put your local files at risk.

Why this is sharper in Obsidian

Plugins run with access to your vault.
That is the point of Obsidian, and also the reason plugin integrity matters.

A practical decision rule

Prefer:

• native platform primitives (DOM, fetch, small utilities)
• small local implementations for simple needs
• adapters that make heavyweight integrations optional

Treat heavyweight libraries as a deliberate trade:

• they must reduce total complexity overall
• they must be isolated so the core stays lean

Next step

Pick one project.
List its dependencies.
Ask: "Which of these are conveniences, and which are necessities?"
Then trim one.