ObsidianPluginVitestConfigContext.desktopPerformance
ObsidianPluginVitestConfigContext › desktopPerformance
Type: ObsidianPluginVitestProjectConfig
Theintegration-tests:desktop-performance project, running the at-scale suites. It is declared for every plugin even when there is no such suite yet — passWithNoTests makes an empty project free, and the matching test:integration:desktop:performance script exists in every plugin built on this library.A plugin's
test:integration aggregate leaves this project out on purpose, and it stays out even on a machine with a desktop Obsidian set up. The reason is the fixture rather than the cost: a perf suite needs its own generated, populated vault, sized through env vars, and the aggregate's small temporary vault is the wrong one. The 600 s below is a timeout, not a duration — measured end to end, most perf suites finish in seconds, and only one that generates tens of thousands of notes takes minutes.Its CDP transport's per-eval cap is raised to 600 s as well (the budget clears it by the usual margin), because a perf suite's whole measurement is typically ONE long in-page evaluation, which the transport's 30 s default killed as a bare
CDP command timed out … Runtime.evaluate naming neither the wait nor the assertion. Three plugins had each hand-written this raise in their own editContext before it moved here. Unlike a raised desktop cap, which is a backstop rather than a budget a closure may spend, this one IS a budget: no-over-cap-wait-in-eval-in-obsidian reads it for these files and for no other.No routine command runs them, but something does: a weekly sweep runs every plugin's
test:integration:desktop:performance, which is also how to reach them by hand. Adding them to that aggregate is drift, not a gap to close.