Cloudflare Workers + MoonBit bundle pipeline

The canonical way to ship a Cloudflare Worker where the bulk of the request handler is MoonBit code (compiled to JS via moon build --target js --release) but the entry shim is hand-written TypeScript.

When to invoke

Use when you're:

• Setting up a new MoonBit → Cloudflare Workers project.
• Migrating an existing project from a hand-written dist/worker.mjs shim to wrangler-native TS bundling.
• Diagnosing a Worker that hangs on the first await after startup (FFI rewrite missed; see references).

Key facts about wrangler + MoonBit

1. wrangler bundles TS natively. As of wrangler 4.x, main: "src/worker.ts" in wrangler.jsonc is enough — wrangler's built-in esbuild integration transpiles + bundles + emits a single JS file on every wrangler dev / wrangler deploy. No separate tsc emit step is needed for the worker.
2. MoonBit output is plain ESM JS. moon build --target js --release writes _build/js/release/build/<package>.js. wrangler can import it from a TS entry — no bridging needed except for the side-effect import (the moon module registers globals at module init).
3. Two MoonBit-specific source rewrites are mandatory. These are not optional and cannot move into TS:
   • moonbitlang$async$internal$event_loop$$reschedule() → the mangled _M0FP...event__loop10reschedule() name. The legacy hook only drains the deque once; the new name re-pumps via setTimeout(0). Without the rewrite, every await past startup hangs.
   • Module-scope random seed → a constant. Workers reject random in module init. Both must happen between moon build and wrangler deploy, applied to the moon JS output. See assets/scripts/prepare-worker.ts.template.