Internal Cache
Vantris keeps a transparent, self-invalidating cache in node_modules/.vantris/. It exists to make repeat runs fast, and it requires no configuration — you never touch it.
What's cached
- Transpiled dev modules — content-addressed. When a source file's contents don't change, its transpiled output is reused instead of re-running esbuild.
- Pre-bundled dependencies — in
node_modules/.vantris/deps/. See Dependency Pre-Bundling. - Build metadata — reused across builds where safe.
Where it lives
Everything sits under node_modules/.vantris/:
node_modules/.vantris/
├── deps/ # pre-bundled dependencies (dev)
└── … # transpiled modules + build metadataIt is never written to your project root. Because it lives inside node_modules, it's already git-ignored by any normal setup.
Self-invalidation
You don't manage cache freshness — Vantris does. The cache is wiped automatically when either of these changes:
- The Vantris version — upgrading the package invalidates stale artifacts.
- Your config — a change to
vantris.config.tsinvalidates cached output that depended on the old config.
Individual transpiled modules are content-addressed, so editing a file naturally misses the old entry and produces a fresh one. There's no stale-cache class of bug to reason about.
Clearing it manually
You almost never need to, but if you want a clean slate — e.g. after a package manager did something unusual — just delete the folder:
rm -rf node_modules/.vantrisThe next vantris dev/build rebuilds it from scratch. Nothing is lost; it's purely derived data.
Why it's safe
The cache is derived, transparent, and scoped:
- Derived — every entry can be regenerated from your source + config. Deleting it is always safe.
- Transparent — it doesn't change behaviour, only speed. A cached run and a cold run produce identical output.
- Scoped — confined to
node_modules/.vantris/, never your source tree.
That combination is why it needs no configuration surface: there's nothing to tune and nothing that can go subtly wrong.