Is your feature request related to a problem? Please describe.
Yes. When a VitePress plugin uses transformPageData to inject shared/global data (such as a site-wide page hierarchy) into every page, the result is cached per page file by VitePress's internal markdown LRU cache. When any source file changes, VitePress only re-runs transformPageData for that specific file — all other pages continue serving stale cached data until the dev server is restarted. There is no public API to invalidate this cache from a plugin.
Describe the solution you'd like
A way to opt out of the markdown cache for a specific transformPageData hook, or a lifecycle hook that runs before the cache is consulted on every page request. Alternatively, exposing a public clearCache() function that plugins can call to invalidate the markdown LRU cache when their shared data changes.
Describe alternatives you've considered
Calling VitePress's internal clearCache function located by scanning the dist/node/chunk-*.js files at runtime — this works but relies on an undocumented internal that can break on any VitePress update. Also considered serving shared data via a custom dev middleware endpoint and fetching it client-side, but this requires different code paths for dev and build, significantly complicating plugin architecture.
Additional context
This affects any plugin that injects global or hierarchical data into pages — not just navigation trees. The pattern of computing shared data once and embedding it into every page's __pageData is a natural fit for transformPageData, but the per-file caching makes it unreliable in dev whenever the shared data can change independently of the page being viewed. A real-world example is a site hierarchy built from all pages' frontmatter: changing a label on one page should be reflected in the navigation of every other page, but currently requires a dev server restart.
Worth mentioning: the issue results from several iterations of Vibe-coding with Anthropic Claude to implement a generic theme for VitePress I'd like to use with more regular websites driven by markdown files. Everything provided here except for this paragraph has been provided by the AI coding agent trying to fix the issue for about an hour investigating back and forth the setup. The particular scenario is a breacrumb menu on a page properly updating its view when adjusting the frontmatter of another page listed in the breadcrumb, too. Eventually I'd like to have a clean future-proof solution instead of having to search the chunks of a VitePress release for an internal function.
Validations
Is your feature request related to a problem? Please describe.
Yes. When a VitePress plugin uses transformPageData to inject shared/global data (such as a site-wide page hierarchy) into every page, the result is cached per page file by VitePress's internal markdown LRU cache. When any source file changes, VitePress only re-runs transformPageData for that specific file — all other pages continue serving stale cached data until the dev server is restarted. There is no public API to invalidate this cache from a plugin.
Describe the solution you'd like
A way to opt out of the markdown cache for a specific transformPageData hook, or a lifecycle hook that runs before the cache is consulted on every page request. Alternatively, exposing a public clearCache() function that plugins can call to invalidate the markdown LRU cache when their shared data changes.
Describe alternatives you've considered
Calling VitePress's internal clearCache function located by scanning the dist/node/chunk-*.js files at runtime — this works but relies on an undocumented internal that can break on any VitePress update. Also considered serving shared data via a custom dev middleware endpoint and fetching it client-side, but this requires different code paths for dev and build, significantly complicating plugin architecture.
Additional context
This affects any plugin that injects global or hierarchical data into pages — not just navigation trees. The pattern of computing shared data once and embedding it into every page's __pageData is a natural fit for transformPageData, but the per-file caching makes it unreliable in dev whenever the shared data can change independently of the page being viewed. A real-world example is a site hierarchy built from all pages' frontmatter: changing a label on one page should be reflected in the navigation of every other page, but currently requires a dev server restart.
Worth mentioning: the issue results from several iterations of Vibe-coding with Anthropic Claude to implement a generic theme for VitePress I'd like to use with more regular websites driven by markdown files. Everything provided here except for this paragraph has been provided by the AI coding agent trying to fix the issue for about an hour investigating back and forth the setup. The particular scenario is a breacrumb menu on a page properly updating its view when adjusting the frontmatter of another page listed in the breadcrumb, too. Eventually I'd like to have a clean future-proof solution instead of having to search the chunks of a VitePress release for an internal function.
Validations