Skip to content

require_dist is not a function — Astro 6 + Cloudflare Adapter v13 #16029

@gregturn

Description

@gregturn

Astro Info

Astro                    v6.0.8
Node                     v25.2.1
System                   macOS (arm64)
Package Manager          unknown
Output                   server
Adapter                  @astrojs/cloudflare
Integrations             @astrojs/sitemap

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

No response

Describe the Bug

Environment

Node.js 25.2.1
astro 6.0.8
@astrojs/cloudflare 13.1.3
@cloudflare/vite-plugin 1.30.0
vite (astro's) 7.3.1
vite (@cloudflare/vite-plugin's) 8.0.1 ← different version
rolldown 1.0.0-rc.10
cookie 1.1.1
OS macOS Darwin 24.6.0

Config: output: 'server', adapter: cloudflare()


Error

require_dist is not a function
TypeError: require_dist is not a function
    at null.<anonymous> (.vite/deps_ssr/logging-C3Ufh6FJ.js:15:19)
    at CustomModuleRunner.directRequest (workers/runner-worker/vite/module-runner:1204:59)
    at null.<anonymous> (.vite/deps_ssr/astro_app_entrypoint_dev.js:17:1)
    at CustomModuleRunner.directRequest (workers/runner-worker/vite/module-runner:1204:59)
    at null.<anonymous> (/virtual:astro:app:1:1)

Crashes on both astro dev and astro build. No routes are ever served.


Traced Root Cause

1. Astro's cookies.js imports cookie as ESM

// node_modules/astro/dist/core/cookies/cookies.js
import { parse, serialize } from "cookie";

2. cookie@1.1.1 ships CJS only

No ESM export, no "type": "module", no exports map. "main": "dist/index.js" points to:

// node_modules/cookie/dist/index.js
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.parseCookie = parseCookie;
// ...

3. Rolldown wraps it with a __commonJSMin shim in .vite/deps_ssr/

// .vite/deps_ssr/chunk-DOseaPKx.js  (rolldown/runtime.js)
var __commonJSMin = (cb, mod) => () => (mod || cb((mod = { exports: {} }).exports, mod), mod.exports);

// .vite/deps_ssr/astro___cookie.js
import { t as __commonJSMin } from "./chunk-DOseaPKx.js";
var require_dist = /* @__PURE__ */ __commonJSMin(/* full cookie CJS body */);
export { require_dist as t };

require_dist is a lazy initializer — calling require_dist() runs the CJS module and returns its exports.

4. The crash in logging-C3Ufh6FJ.js

// .vite/deps_ssr/logging-C3Ufh6FJ.js
import { t as require_dist } from "./astro___cookie.js";  // line 10
// ...
var import_dist = require_dist();  // line 15 ← TypeError: require_dist is not a function

In Node.js this works fine. In workerd's CustomModuleRunner, the live binding resolves to undefined — meaning astro___cookie.js has not finished initializing its exports when line 15 executes.

5. Compounding factor — two Vite versions in the tree

astro@6.0.8 depends on Vite 7.3.1. @cloudflare/vite-plugin@1.30.0 depends on Vite 8.0.1. These are not deduped — both are installed simultaneously. The SSR pre-bundled deps in .vite/deps_ssr/ are produced by one Vite version's pipeline and then executed by the CustomModuleRunner from the other. This version split is a likely contributor to the binding timing issue.

├─┬ @astrojs/cloudflare@13.1.3
│ ├─┬ @cloudflare/vite-plugin@1.30.0
│ │ └── vite@8.0.1 deduped
│ └── vite@7.3.1
├─┬ @tailwindcss/vite@4.2.2
│ └─┬ vite@8.0.1
│   └── rolldown@1.0.0-rc.10
└─┬ astro@6.0.8
  └── vite@7.3.1

What Was Tried

Adding cookie to optimizeDeps.include via a configEnvironment Vite plugin (as recommended in the Cloudflare v13 upgrade docs) does not help. The module is part of Astro's own internal SSR entrypoint bundle — it is not an app-level dependency that can be targeted by optimizeDeps.


Suggested Fix Directions

  1. Astro ships an ESM-native cookie import in its SSR output, eliminating the __commonJSMin shim entirely.
  2. CustomModuleRunner binding initialization@cloudflare/vite-plugin's module runner should fully initialize all module bindings before executing dependents, matching Node.js ESM live-binding semantics.
  3. Resolve the Vite 7/8 version split — Astro and @cloudflare/vite-plugin should share one Vite instance so the dep-bundling pipeline and module runner operate on the same version.

References

What's the expected result?

I was expecting the system to simply come up but instead it reports a rather cryptic stack trace. Claude Code helped me pinpoint where it was coming from.

Link to Minimal Reproducible Example

https://github.com/gregturn/mountainsummitpress.com

Participation

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

Metadata

Metadata

Assignees

Labels

auto triage skippedneeds triageIssue needs to be triagedrequires breaking changeFixing this bug or adding this feature would require breaking changes. For PRs, use "semver: major"

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions