Astro Info

Astro                    v6.1.4
Vite                     v7.3.1
Node                     v22.22.1
System                   macOS (arm64)
Package Manager          pnpm
Output                   server
Adapter                  @astrojs/cloudflare (v13.1.7)
Integrations             @astrojs/svelte
                         @astrojs/react

If this issue only occurs in one browser, which browser is a problem?

Not browser-specific — this is a dev server issue.

Describe the Bug

When using @astrojs/cloudflare with the workerd dev server, the SSR environment does not include common dependencies in optimizeDeps.include. This causes the Vite optimizer to discover them at runtime on first page load, triggering cascading "program reload" cycles that crash with "The file does not exist" errors when chunk files are invalidated during the reload cascade.

Terminal output on first page load (cold start):

[vite] ✨ new dependencies optimized: astro/virtual-modules/transitions.js
[vite] ✨ optimized dependencies changed. reloading
[vite] [vite] program reload
[vite] ✨ new dependencies optimized: @fingerprintjs/fingerprintjs, zod
[vite] ✨ optimized dependencies changed. reloading
[vite] [vite] program reload
[vite] ✨ new dependencies optimized: svelte
[vite] ✨ optimized dependencies changed. reloading
[vite] ✨ new dependencies optimized: nanostores
[vite] ✨ optimized dependencies changed. reloading
[vite] [vite] An error happened during full reload
The file does not exist at ".../node_modules/.vite/deps_ssr/chunk-UZNOVOZ5.js?v=fcc0d116"
which is in the optimize deps directory. The dependency might be incompatible with the
dep optimizer. Try adding it to `optimizeDeps.exclude`.

The cascade pattern is:

1. Vite discovers an un-pre-compiled dep in the SSR environment
2. Optimizes it → triggers a program reload
3. During the reload, discovers another dep → optimizes → another reload
4. A chunk file from optimization pass N is referenced but has been invalidated by pass N+1
5. Crash: "The file does not exist"

After the crash, the server may recover (optimizer caches the deps), but the first page load after a cold start consistently fails. In larger projects with many deps, the cascade can produce 5-8 consecutive program reloads before crashing.

Relationship to #16203

This issue may be compounded by #16203, where the astro-frontmatter-scan esbuild plugin's missing namespace filter causes dep scanning to fail with "No matching export" errors, forcing Vite to skip pre-bundling entirely. If dep scanning fails, even more deps are left for runtime discovery, making the cascade worse.

Current Workaround

A custom Vite plugin that manually adds SSR dependencies via the configEnvironment hook:

// In astro.config.mjs vite.plugins:
{
  name: 'optimize-ssr-deps',
  configEnvironment(name) {
    if (name !== 'client') {
      return {
        optimizeDeps: {
          include: [
            'debug', 'ms',
            'astro/virtual-modules/transitions.js',
            'astro/virtual-modules/transitions-router.js',
            'astro/virtual-modules/transitions-types.js',
            'astro/virtual-modules/transitions-events.js',
            'astro/virtual-modules/transitions-swap-functions.js',
            'svelte', 'nanostores', 'zod', 'consola', 'canvas-confetti',
            '@supabase/supabase-js',
            '@fingerprintjs/fingerprintjs',
            '@fingerprintjs/fingerprintjs-pro',
            'openapi-fetch',
            'convex/browser', 'convex/server', 'convex-svelte',
          ],
          exclude: ['@ark-ui/svelte'],
        },
      };
    }
  },
},

With this plugin, the dev server starts cleanly — zero runtime dep discovery, zero program reloads.

Note: The @ark-ui/svelte exclusion is separate — that package ships raw .svelte source files that esbuild cannot process.

Relationship to #16059 (Astro 6.1.4)

We initially believed Astro 6.1.4's fix for miniflare restart issues (#16059) would resolve this. We tested removing our workaround after upgrading to 6.1.4 — the cascading program reload errors returned immediately. The in-place restart fix addresses config-change restarts but does not address the initial SSR dep pre-compilation gap.

Expected Fix

The Cloudflare adapter (or Astro core) should pre-compile Astro's own virtual modules (astro/virtual-modules/transitions*.js) for the SSR environment, the same way the client environment already handles them. The adapter could also automatically include common framework deps that are known to trigger runtime discovery in workerd.

Alternatively, Vite's SSR dep optimizer could be made more resilient to cascading discoveries — the crash happens because chunk files from optimization pass N are invalidated by optimization pass N+1, but the module runner still references them by the old content hash.

What's the expected result?

Dev server starts and serves first page without cascading program reloads or chunk-not-found crashes. Dependencies should be pre-compiled before the first request, not discovered at runtime.

Link to Minimal Reproducible Example

Working on a minimal repro. The issue reproduces in a monorepo with Astro 6.1.4 + @astrojs/cloudflare 13.1.7 + @astrojs/svelte + multiple npm dependencies. The key trigger is having enough SSR-consumed deps that the optimizer discovers multiple in sequence.

Participation

• I am willing to submit a pull request for this issue.