Minimizing dependencies

Fewer outside-authored dependencies means fewer hidden trust links around your vault.

Obsidian is powerful because your notes are yours: local files, plain text, and a workspace you can inspect.

Plugins add power to that workspace.

That is why dependencies matter.

When you install a plugin, you may be trusting more than the plugin maintainer. You may also be trusting package authors, package maintainers, update paths, build tools, and transitive code you never chose directly.

Smart Plugins minimize those hidden trust links.

Why excessive dependencies are bad

Dependencies are not automatically bad.

A good dependency can make software safer, faster, and easier to maintain.

Excessive dependencies are different.

They add:

• more outside-authored code near your vault
• more maintainers you indirectly trust
• more updates that can change behavior
• more places where a vulnerability or compromise can enter
• more code for users, maintainers, and auditors to inspect

For an Obsidian user, this is not abstract.

Your vault may contain private notes, client work, research, drafts, journals, plans, unfinished ideas, and future decisions.

The closer software runs to that work, the more its dependency chain matters.

The Smart Plugins principle

Smart Plugins minimize outside-authored dependencies.

That means:

• use native platform features when they are enough
• write small local implementations when the job is simple
• reuse first-party Smart modules for shared behavior
• avoid convenience packages that only save short-term effort
• keep outside-authored dependencies visible and purposeful
• scope heavier capabilities behind adapters where practical
• avoid forcing a dependency onto workflows that do not need it

The goal is not zero dependencies at any cost.

The goal is fewer unnecessary trust links around your vault.

What this protects

Minimizing outside-authored dependencies helps protect four things Obsidian users already care about.

Your privacy

Less outside-authored code near your vault means fewer hidden paths to understand.

Your durability

Fewer moving parts means fewer pieces that can break, disappear, or become unmaintained.

Your ability to inspect

A smaller outside-authored dependency chain is easier to review than a large one.

Your independence

A tool with fewer outside-authored dependencies is less exposed to changes outside the project.

The practical rule

Every outside-authored dependency is a trust decision.

Use dependencies when they earn that trust.

Avoid them when they only make the code look easier today.

Current outside-authored dependency snapshot

Last checked: 2026-05-13.

This table focuses on direct dependency entries that appear to be authored or maintained by people other than the plugin maintainer.

It counts direct entries declared in:

package.json -> dependencies

It separates:

• outside-authored direct package entries
• first-party local/file Smart module entries

It does not count:

• devDependencies
• peerDependencies
• transitive dependencies
• lockfile dependency trees
• shipped bundle contents
• whether code is actually included at runtime
• verified npm author metadata for every package

This is not a full safety audit.

It is a first-pass way to inspect how much direct outside-authored code a project declares.

First-party local/file Smart modules are still code.

The difference is authorship and maintenance boundary: they are Smart modules maintained as part of the Smart Plugins codebase, not outside registry packages maintained by unrelated authors.

What the numbers mean

A lower outside-authored dependency count does not prove a plugin is safe.

A higher outside-authored dependency count does not prove a plugin is unsafe.

The number tells you how large the direct outside-authored trust chain is before you begin deeper inspection.

The practical question is:

How many people outside the plugin maintainer am I trusting before this code runs near my vault?

How Smart Plugins decides

Before adding an outside-authored dependency, Smart Plugins should ask:

• Can the platform already do this?
• Can a small local implementation do this clearly?
• Can a first-party Smart module do this?
• Does this dependency reduce total complexity?
• Is the maintainer reputable and active?
• Does it bring transitive dependencies?
• Can the capability be scoped behind an adapter?
• Will users understand why this dependency exists?

If the answer is unclear, the dependency should wait.

Dependencies should earn trust

Smart Plugins minimize outside-authored dependencies because your vault deserves fewer hidden trust links.

Not every dependency is bad.

But every outside-authored dependency should be visible, purposeful, and worth the trust it asks from users.

That is the principle.