vite 6 dev cold start is 41s in a 22-package workspace, deps re-optimize every reload Vite

Do the export conditions properly and you get to keep source-in-dev and built-output everywhere else:

"exports": {
  ".": {
    "development": "./src/index.ts",
    "types": "./dist/index.d.ts",
    "default": "./dist/index.js"
  }
}

Vite resolves the development condition in dev, so your dev server reads source and HMR works across package boundaries. Everything else - your test runner, your build, anything consuming the package from outside - gets dist. You stop needing main to point at TypeScript, which quietly breaks a lot of tooling that expects main to be JavaScript.

Make sure resolve.conditions in your Vite config has not been overridden to something that drops development. If you have set that array yourself you probably clobbered the defaults.

You are not paying for consuming source, you are paying for discovering dependencies twice.

Here is what happens. Vite scans your entry point, finds the bare imports it can see, pre-bundles those with esbuild, and starts serving. Then the browser requests a file from one of your workspace packages, that file imports date-fns or whatever, and Vite has never seen it - so it stops, optimizes the new dependency, and hard-reloads the page. Each of those round trips is expensive and you are getting two.

The fix is to tell it up front:

optimizeDeps: {
  include: ['date-fns', 'zod', 'lodash-es/debounce', '@scope/ui > react-aria'],
  entries: ['index.html', 'src/**/*.tsx'],
}

The > syntax handles transitive deps of a linked package, which is the case the scanner is worst at. Getting the list right took me one pass of reading the reload messages and writing down every package it named.

That took us from 41s to about 13s. The rest of the way was the export condition thing someone else will inevitably mention.

One more: the scanner does not follow deps of linked workspace packages by default, which is precisely why a monorepo hits this and a single-package app almost never does.

server.warmup.clientFiles is worth a look once you have done the above. You give it a glob of the modules your app requests first and Vite transforms them before the browser asks. It does nothing for dep optimization but it removes the transform stall right after the page loads, which is a decent chunk of perceived cold start on a big app.

Check your barrel files while you are in there. One index.ts that re-exports 300 modules means importing a single component pulls the whole package through the transform pipeline. We deleted the barrels from our two biggest shared packages and dev-server work dropped noticeably - and tree shaking in the production build improved as a bonus.

Honestly at 22 packages I would just move to Bun. The dev server is effectively instant and you delete the entire optimizeDeps concept because it does not need a pre-bundling step.

41 seconds is roughly one coffee, which is why nobody on the team ever reported it as a bug.