Answer
Shifting the Vite 5.x dev server default to a restrictive allow list of only the project root would improve the default security posture by preventing the server from serving files outside the immediate project directory. It would also break common monorepo and workspace patterns that rely on the dev server reading, serving, or hot-reloading files located outside the project root.
Confirmed facts vs likely behavior
Confirmed: Vite exposes server.fs.allow and server.fs.deny to whitelist/blacklist directories the dev server may serve. The setting controls file serving, inline imports, and HMR file watching, not general Node module resolution.
Likely, with uncertainty: Model knowledge indicates Vite 5.x defaults to allowing the project root and is permissive about readable paths outside it. The exact default list and whether "any readable directory" is truly unrestricted requires current verification against the Vite 5.x source and docs, as defaults have changed across minor releases.
Implications for monorepos
Restricting to ['.'] blocks serving from sibling packages, workspace roots, or parent directories. That can cause:
- HMR failures for files imported via relative paths such as
../packages/ui
- 404s for assets or source files that Vite inlines from outside the root
- Broken alias resolutions that point above the project root
Imports resolved through package names via node_modules are generally unaffected, because Vite resolves those dependencies through Node resolution rather than server.fs.allow. The restriction primarily hits local path imports, shared workspace configs, and dev-time file serving.
Verification steps for this case
- Set a test config:
// vite.config.js
export default {
server: {
fs: { allow: ['.'] }
}
}
- Start the dev server and watch console for fs-related warnings.
- Trigger an import from a sibling workspace package or a relative
../ import and check HMR propagation and asset loading.
If failures appear, add explicit paths with glob support, e.g. ['.', '../packages/*'], or use resolve.alias and preserveSymlinks to keep imports inside the allowed root.
To give a precise allow list recommendation, one missing diagnostic detail changes the advice: are sibling packages imported by package name resolved through node_modules, or by relative file paths like ../packages/ui?
vitejs