emdash@0.37.0 fails to build on Windows: createRequire() with a driveless file URL in @emdash-cms/registry-verification@0.3.0

[Gohan-mada]

Description

emdash@0.37.0 cannot be built on Windows. The build fails before it starts, with an error that blames the Astro config:

[astro] Unable to load your Astro config
The argument 'filename' must be a file URL object, file URL string, or absolute path string.
Received 'file:///emdash-registry-verification.js'

The Astro config is not at fault. The root cause is in @emdash-cms/registry-verification@0.3.0, which emdash@0.37.0 inlines into its bundle. dist/index.js line 8 contains the rolldown CJS-interop shim:

var __require = /* @__PURE__ */ createRequire("file:///emdash-registry-verification.js");

That file URL has no drive letter. On macOS and Linux it resolves to the absolute path /emdash-registry-verification.js and createRequire() accepts it. On Windows there is no such thing as a driveless absolute path, so fileURLToPath() rejects it and createRequire() throws.

The call sits at module scope, so merely importing the package throws. In a normal EmDash site the import chain is astro.config → @emdash-cms/plugin-forms → emdash → the inlined registry-verification, which is why it surfaces as a config-loading failure.

emdash@0.36.0 is unaffected: grep 'createRequire("file:///' node_modules/emdash/dist/*.mjs returns nothing there. This is a regression introduced in 0.37.0.

Steps to reproduce

Minimal — no EmDash site needed. On Windows:

node -e "require('module').createRequire('file:///emdash-registry-verification.js')"

Throws. With a drive letter it works:

node -e "require('module').createRequire('file:///C:/x/emdash-registry-verification.js')"

Confirmed in the published tarball:

npm pack @emdash-cms/registry-verification@0.3.0
tar xzf emdash-cms-registry-verification-0.3.0.tgz
grep -n 'createRequire(' package/dist/index.js

8:var __require = /* @__PURE__ */ createRequire("file:///emdash-registry-verification.js");

__require itself is only used twice, inside lazily-evaluated CommonJS wrappers — line 2832 (require("crypto")) and line 5059 (require("util")) — but the createRequire() call that builds it is evaluated eagerly at module scope, so the lazy wrappers do not protect it.

In a real site:

1. On Windows, take an EmDash site on Cloudflare (Astro 7, @emdash-cms/cloudflare, @emdash-cms/plugin-forms).
2. Upgrade emdash and @emdash-cms/cloudflare to 0.37.0, and @emdash-cms/plugin-forms to 0.2.6.
3. npm install && npm run build
4. The build fails with the error above. Downgrading to 0.36.0 / 0.2.5 restores a working build.

Suggested fix

dist/index.js is ESM (it opens with import { createRequire } from "node:module"), so import.meta.url is available and is the portable idiom:

var __require = /* @__PURE__ */ createRequire(import.meta.url);

Alternatively, configure the rolldown shim so it is given the real module URL rather than a synthetic file:///<name>.js placeholder.

Environment

• emdash version: 0.37.0 (0.36.0 works)
• @emdash-cms/cloudflare: 0.37.0
• @emdash-cms/plugin-forms: 0.2.6
• @emdash-cms/registry-verification: 0.3.0 (transitive, inlined into emdash)
• Astro: 7.2.3
• Node.js: v24.15.0
• Runtime: Cloudflare Workers (build host is Windows)
• OS: Windows 11

Screenshots

Not applicable — this is a build-time failure, not an interface issue.

Logs / error output

> astro build

[astro] Unable to load your Astro config

The argument 'filename' must be a file URL object, file URL string, or absolute path string. Received 'file:///emdash-registry-verification.js'
  Location:
    node_modules/emdash/dist/api-Dz6rgoa3.mjs:3789:33
  Stack trace:
    at createRequire (node:internal/modules/cjs/loader:2039:13)
    at ModuleJob.run (node:internal/modules/esm/module_job:437:25)
    at async ModuleRunner.directRequest (node_modules/vite/dist/node/module-runner.js:1231:18)
    at async eval (node_modules/@emdash-cms/plugin-forms/src/index.ts:7:31)
    at async ModuleRunner.directRequest (node_modules/vite/dist/node/module-runner.js:1268:59)

The surrounding lines of the bundled chunk show which package it came from:

//#region ../registry-verification/dist/index.js
var __commonJSMin = (cb, mod) => () => (mod || cb((mod = { exports: {} }).exports, mod), mod.exports);
var __require = /* @__PURE__ */ createRequire("file:///emdash-registry-verification.js");

[emdashbot]

Completed

emdash@0.37.0 fails to build on Windows: createRequire() with a driveless file URL in @emdash-cms/registry-verification@0.3.0

• Review the issue and relevant repository context

Outcome: Confirmed. The root cause is in `packages/registry-verification/tsdown.config.ts`. The custom `rebundleSafeRequire` plugin intentionally replaces the rolldown CJS-interop shim `createRequire(import.meta.url)` with `createRequire("file:///emdash-registry-verification.js")` so the published artifact can be rebundled safely. On macOS/Linux `fileURLToPath()` turns that URL into the absolute path `/emdash-registry-verification.js`, which `createRequire()` accepts. On Windows the same URL has no drive-letter mapping, so `fileURLToPath()` rejects it and the module-scope call throws as soon as the package is imported.

The `scripts/check-packed-output.mjs` guard explicitly forbids leaving `createRequire(import.meta.url)` in the published bundle, so the fix must keep a synthetic URL while making it valid on all platforms. The smallest change is to add a synthetic drive letter: `createRequire("file:///C:/emdash-registry-verification.js")`, which resolves to a valid absolute path on both Windows (`C:\...`) and Unix (`/C:/...`), still without requiring the file to exist.

Next step: update `rebundleSafeRequire` in `packages/registry-verification/tsdown.config.ts`, rebuild, run `pnpm --filter @emdash-cms/registry-verification test:package`, and add a patch changeset for `@emdash-cms/registry-verification`.

Mode: triage

View live dashboard · Run: 2c333f73-10b2-4f60-a78a-5c6fdc012b63

[emdashbot]

Completed

Fix Windows build failure in @emdash-cms/registry-verification by replacing driveless synthetic URL in rebundleSafeRequire with a Windows-valid absolute file URL, then rebuild and run the package output guard.

• Reproduce the current packed output
• Add regression test for cross-platform createRequire URL
• Update rebundleSafeRequire with drive-letter URL
• Rebuild and run package checks
• Add changeset and publish candidate

Outcome: Fixed `@emdash-cms/registry-verification` so its bundled ESM artifact uses a `createRequire` base URL that is valid on Windows.

### What changed

• `packages/registry-verification/tsdown.config.ts`: the `rebundleSafeRequire` plugin now substitutes `createRequire("file:///C:/emdash-registry-verification.js")` instead of the driveless `file:///emdash-registry-verification.js`. The drive letter keeps `fileURLToPath()` happy on Windows while still being a synthetic, rebundle-safe base on macOS/Linux.
• `packages/registry-verification/scripts/check-packed-output.mjs`: added a regression guard that parses the packed `dist/index.js`, verifies the URL includes a drive letter, and confirms it resolves to an absolute path with `fileURLToPath()`.
• Added a patch changeset for `@emdash-cms/registry-verification`.

### Reproduction / verification

• Rebuilt the package and checked the line now reads: `var __require = /* @__PURE__ */ createRequire("file:///C:/emdash-registry-verification.js");`
• The new check failed against the old driveless URL (`Packed verifier createRequire URL is not Windows-valid: file:///emdash-registry-verification.js`) and passes after the fix.
• `pnpm --filter @emdash-cms/registry-verification test` passed: 114 vitest tests + 38 workerd tests.
• `pnpm --filter @emdash-cms/registry-verification test:package` passed.
• `pnpm typecheck` passed.
• `pnpm lint:json | jq '.diagnostics | length'` returned `0`.
• `pnpm lint:quick` passed.
• `pnpm format` applied cleanly.

The candidate was published after these checks.

Mode: work

View live dashboard · Run: 9e7c91e5-80af-4c34-8c1b-be105396b012

[emdashbot]

A candidate change is ready to preview.

Fixed @emdash-cms/registry-verification so its bundled ESM artifact uses a createRequire base URL that is valid on Windows.

What changed

• packages/registry-verification/tsdown.config.ts: the rebundleSafeRequire plugin now substitutes createRequire("file:///C:/emdash-registry-verification.js") instead of the driveless file:///emdash-registry-verification.js. The drive letter keeps fileURLToPath() happy on Windows while still being a synthetic, rebundle-safe base on macOS/Linux.
• packages/registry-verification/scripts/check-packed-output.mjs: added a regression guard that parses the packed dist/index.js, verifies the URL includes a drive letter, and confirms it resolves to an absolute path with fileURLToPath().
• Added a patch changeset for @emdash-cms/registry-verification.

Reproduction / verification

• Rebuilt the package and checked the line now reads: var __require = /* @__PURE__ */ createRequire("file:///C:/emdash-registry-verification.js");
• The new check failed against the old driveless URL (Packed verifier createRequire URL is not Windows-valid: file:///emdash-registry-verification.js) and passes after the fix.
• pnpm --filter @emdash-cms/registry-verification test passed: 114 vitest tests + 38 workerd tests.
• pnpm --filter @emdash-cms/registry-verification test:package passed.
• pnpm typecheck passed.
• pnpm lint:json | jq '.diagnostics | length' returned 0.
• pnpm lint:quick passed.
• pnpm format applied cleanly.

The candidate was published after these checks.

Try the change against your own site:

npm i https://pkg.pr.new/emdash@bot/fix-2978

Or try the candidate in a ready-to-use playground:

Open the playground preview

@Gohan-mada could you try this? Reply naturally to say whether it works or explain what still needs to change.

_{A maintainer can accept on the reporter's behalf. Acceptance opens a draft PR; requested changes start another candidate revision.}

Fix branch: bot/fix-2978 · Artifacts branch: bot/artifacts-2978

[ascorbic]

@emdashbot accept