Heavy dependency quarantine (the baseline is the metric)
Generated from
pattern-library/registry.json— do not edit by hand; change the registry and runbun run patterns:build.
Category: Runtime Velocity · Tier: deep · Maturity: proven (verified 2026-09-09 @ 921e8266-dirty) · Risk: medium — the gate fails a build, which is the point
Optional heavyweight capabilities load behind dynamic-import boundaries, and the gated metric is not the route's own size but the shared baseline every other route pays — baseline_js_kb, ratcheted with ~3% headroom.
When to use: Use when a dependency is large, feature-specific, rarely used, browser-only or expensive to initialize — 3D, maps, charts, editors, graph visualization.
Docs
- docs/blueprint/velocity/runtime.md#heavy-dependency-quarantine — Why the baseline is the number that matters (GitHub · GitLab)
Code
scripts/perf/snapshot.ts— Walks the Vite manifest import graph and gzips each chunk (GitHub · GitLab)src/lib/server/perf/budgets.json— baseline_js_kb ceiling — the shared cost of every route (GitHub · GitLab)
Tests
Proof
Invariants
- An optional heavy capability does not enter the shared baseline without explicit justification.
- Browser-only capabilities stay off SSR paths unless needed.
- The question a bundle review answers is 'did this capability make every OTHER route heavier', not 'is this route big'.
Emulation notes
- Watch barrel files: importing a component through a barrel can pull an unrelated heavyweight sibling into everything. v10r imports
CodeBlockdirectly for exactly this reason — the composites barrel would drag the markdown sanitizer along. - The bundle gate must run a PRODUCTION build; a dev-mode build compiles both halves differently and inflates client JS ~9%. Note that v10r's
validatehas no build step — bundle regressions are only caught byvalidate:build.
Depends on
Machine-readable record: heavy-dependency-quarantine in pattern-library/registry.json.