virtual:emdash/plugins silently generates empty in production builds (content-hash dependent)

[kgittyup]

Summary

Under specific, reproducible conditions, astro build produces a green build where the generated virtual:emdash/plugins module is never emitted: no const plugins = [ literal and no adaptSandboxEntry(...) call anywhere in dist/ (only the definition chunk), while the chunk count and chunk name set are identical to a healthy build. All configured plugins are silently absent at runtime — the app boots with an empty plugin list and no errors. astro dev is unaffected and fully correct.

Environment

• emdash 0.34.0, Astro 6.4.6 (also reproduced on 6.4.8), Node 22.22.3, macOS arm64
• One standard-format plugin registered via plugins: [factory()] with a package entrypoint (format: "standard", private scoped package, compiled ESM in dist/)
• vite: { ssr: { noExternal: [/^@scope\//] } } on the consuming site

Evidence (~25 controlled builds, each checked for a positive marker string in dist)

1. Reproduces with a single plugin and no other integrations; independent of Vite cache state (node_modules/.vite and .astro wiped between builds), bare-specifier vs absolute-path entrypoint, TS-source vs compiled-JS package form, and the trigger file's name.
2. A stub entrypoint (export default {}) is always healthy — the failure follows the entrypoint's import graph.
3. Bisecting with used imports (side-effect imports get tree-shaken and mask the failure — important trap) traces the trigger to one small dependency file in node_modules. Most modules in the same package are fine; that one file alone triggers the empty output.
4. The failure is content-hash dependent, not syntactic. Flip-switch table, all in the same environment, changing only content:
   • Remove the JSDoc comment above one function AND a secondary export → healthy
   • Keep the comment, single export → empty; no comment + two exports → empty
   • Two other exports from the same original file, without that function → healthy
   • Exact same bytes moved to a file in the project's src/ → healthy
   • Trivial content at the same node_modules path (same filename) → healthy
   • Renamed copy (different filename, same content, same directory) → empty
5. Byte-level dodging is not a viable mitigation: two independent byte patterns of the trigger file (one with comments, one comment-stripped — a pattern never previously built) produce the same empty output in the affected environment, while an unaffected environment stays healthy with both. The sensitivity is to aggregate content, not any specific token.

Minimal trigger

A file in node_modules with this content, imported with used symbols:

import { createHash } from "node:crypto";
/** Short stable fingerprint from the identifying parts of an event. */
export function fingerprint(...parts) {
    return createHash("sha256").update(parts.join(" ")).digest("hex").slice(0, 16);
}
export const dummy = 1;

Plugin entrypoint (pointed at by the plugin descriptor):

import * as m from "<abs path>/node_modules/<pkg>/dist/events-copy.js";
export default { probe: m };

Caveat: this minimal trigger reproduces deterministically in one environment but NOT in another with an identical version stack and module graph — consistent with content-hash dependence on the overall graph. The strength of this report is the flip-switch evidence above (comment on/off in the same environment), which proves hash dependence regardless of whether a maintainer reproduces directly.

Interpretation

Looks like a transform-/cache-collision in the production bundling of the virtual module: certain content hashes in the graph cause virtual:emdash/plugins to resolve to empty, silently.

Suggested hardening regardless of root cause

generatePluginsModule() output is critical infrastructure. A build-time assertion that the emitted bundle actually contains the expected plugin registrations — or at minimum a loud runtime warning when plugins.length differs from the configured descriptor count — would turn this silent failure into a visible one. In our case the site shipped green builds with security tooling silently absent; we now grep dist for a positive marker before every deploy, but that shouldn't be necessary.

Happy to share the full build matrix on request.

[ascorbic]

@emdashbot investigate

[emdashbot]

Completed

Generation code is correct; empty output is a downstream Vite/Rollup production bundling issue. Astro 7/Vite 8 in this checkout does not reproduce it. EmDash lacks a build-time guard, making the failure silent.

• Find virtual:emdash/plugins generation code
• Review plugin loading and build integration
• Attempt to reproduce empty module in production build
• Diagnose root cause and assess confidence
• Report investigation findings

Outcome: Investigated `virtual:emdash/plugins` empty output in production builds.

Findings:

• `generatePluginsModule()` at `packages/core/src/astro/integration/virtual-modules.ts:252` is correct: with one standard-format plugin it emits `import { adaptSandboxEntry }`, the plugin default import, and `export const plugins = [adaptSandboxEntry(pluginDef0, {...})];`.
• `packages/core/src/astro/middleware.ts` consumes the `plugins` export and passes them into `EmDashRuntime.create()`, so under normal Rollup semantics the export should not be tree-shaken.
• I reproduced the reporter's minimal trigger in this checkout (standard plugin entrypoint importing a `node_modules` file with the exact `fingerprint`/`dummy` content) and tried the reported flip-switch variants. In this environment (Astro 7.0.0 / Vite 8.0.11 / Rollup 4.55.2) every build is healthy: the SSR bundle contains `adaptSandboxEntry(..., {"id":"repro-plugin"})` and the plugins array.
• The reporter's evidence (25 builds; outcome flips when only comments/exports change, yet chunk names stay identical) points to an upstream Vite/Rollup production-bundling bug, likely a content-hash-dependent module-graph cache/chunking interaction that drops the virtual module content. The current Astro 7/Vite 8 stack does not reproduce it.
• EmDash lacks a build-time check that the emitted bundle contains the expected plugin registrations; this is why the failure is silent.

Root cause: most likely an upstream Vite/Rollup content-hash-dependent bundling bug, compounded by missing build-time validation in the EmDash integration.

Suggested hardening: add a build-time assertion in `packages/core/src/astro/integration/vite-config.ts` (`generateBundle`/`writeBundle`) or `index.ts` (`astro:build:done`) that scans the server bundle for each configured plugin marker and throws if any are missing.

Mode: diagnose

View live dashboard · Run: 94c6a816-eb90-43c0-801c-6a9957da7ec4