Pre-bundling workspace packages vs. native ESM resolution in pnpm monorepos

In a pnpm workspace monorepo, managing local package dependencies presents a trade-off between development server performance and HMR accuracy.

optimizeDeps.include to force esbuild to pre-bundle hoisted workspace packages into a single cache. While this significantly reduces cold start times for large dependency graphs, it risks capturing stale symlink targets when pnpm hoists packages, resulting in the server serving outdated code until the cache is manually invalidated.

Alternatively, relying on server.deps.inline combined with resolve.preserveSymlinks allows Vite to resolve local packages as native ESM. This ensures that the latest source code is always served, but it can increase per-request resolution overhead and introduce noticeable HMR latency as the project grows.

uncertainty lies in the deterministic behavior of cache invalidation during package.json changes and how Vite interacts with the pnpm nested node_modules structure.

• Is it more reliable to use optimizeDeps.exclude for all workspace packages or selectively include them with a custom server.fs.allow list?
• Does the interaction between pnpm symlinks and optimizeDeps remain consistent across different Vite major versions?