Question
Vite dev server pre‑bundles different modules when optional dependencies are missing
Lax Dey
0 reputation · 01 Feb 2020, 22:33 UTC
57K views
Loading…
0 reputation · 01 Feb 2020, 22:33 UTC
Goal: Achieve a deterministic development server startup where the set of pre‑bundled modules is identical for every developer who shares the same package.json, regardless of which optional dependencies happen to be installed locally.
Concern: Vite’s esbuild‑based optimizeDeps step silently omits any optional dependency that cannot be resolved, does not log the omission, and caches the resulting bundle in node_modules/.vite. If a developer’s machine lacks an optional package, the dev server may reuse a stale bundle after a version change, leading to divergent module graphs and hidden inconsistencies.
Questions: Should Vite warn when a listed optional dependency is skipped during pre‑bundling? Should the dev server automatically bypass the cache or force a re‑bundle when optional‑dependency resolution changes? Could an opt‑in mode treat missing optional dependencies as errors to guarantee repeatability?
34275 reputation · 02 Feb 2020, 10:33 UTC
Vite does not currently emit a warning when an optional dependency listed in package.json cannot be resolved during the optimizeDeps step. The pre‑bundle cache in node_modules/.vite is kept as‑is, so a developer who has the optional package installed will get a different set of bundled modules than one who does not. The dev server will not automatically re‑bundle when the presence of an optional dependency changes, and there is no built‑in configuration to treat missing optional dependencies as fatal errors.
vitejsoptimizeDeps, simply drops imports that cannot be resolved without throwing an error. Vite forwards that behaviour, so no console message appears.optimizeDeps.force (or the --force CLI flag) to bypass the cache; there is no option that turns missing optional dependencies into an error.vite --force or set optimizeDeps.force = true in vite.config.ts whenever the optional‑dependency set may have changed. This clears the cache and forces a fresh pre‑bundle.node_modules/.vite before starting the dev server. This guarantees a clean slate on every machine.package.json at build start and explicitly check that every listed optional dependency can be resolved. If a check fails, the plugin can call this.error to abort the dev server. This gives an opt‑in “strict” mode for teams that need repeatability.To decide whether the custom‑validation approach is appropriate, could you confirm whether the optional dependencies in question are required for core application functionality on any platform, or are they purely additive (e.g., telemetry, OS‑specific binaries)?
Use comments to ask for clarification. Post a solution as an answer.
34,275 reputation · 02 Feb 2020, 05:48 UTC
The _metadata.json hash in node_modules/.vite is derived from package.json dependencies and devDependencies only. It does not encode which optionalDependencies were actually resolved during the esbuild scan, so two machines with identical lockfiles but different optional-dep installation states produce the same cache key and reuse the same pre-bundle.
DEBUG=vite:deps vite and look for lines like skip optional dep <name> — they appear only at debug level.node_modules/.vite/_metadata.json across machines; the hash field will match even when the generated deps_*.js chunks differ.This makes the divergence systematic with pnpm (optional-dependencies: false by default) versus npm/yarn, not sporadic.