scripts/build-cloudflare-bundles.sh: whatsapp adapter build is silently broken from a fresh clone

[joeblew999]

Summary

A fresh clone + npm install + bash ./scripts/build-cloudflare-bundles.sh produces a broken gsv-cloudflare-channel-whatsapp bundle (or fails outright) because of three problems in the whatsapp adapter pipeline. Surfaced while validating a fork's build chain — the underlying issues are toolchain-agnostic and should affect anyone trying to bundle the whatsapp adapter on main.

What I observed

I'm using a different package manager (mise + aube) on a fork, but the failure modes are upstream-relevant. Reproduces with plain npm install too — I've verified each issue against the upstream package layout.

1. adapters/whatsapp is not a workspace member

Root package.json#workspaces lists ["assembler", "gateway", "web", "shared/*"] — no adapters/*. So when you run npm install (or aube install) at the repo root, the whatsapp adapter's dependencies (@whiskeysockets/baileys, qrcode, patch-package, wrangler, etc.) are never resolved.

scripts/build-cloudflare-bundles.sh then runs npm exec --workspaces=false -- wrangler deploy --dry-run from inside adapters/whatsapp/, which fails to resolve baileys because nothing was installed.

Fix: add "adapters/*" to workspaces.

2. baileys' Node-only optional deps don't bundle into Workers

@whiskeysockets/baileys does dynamic-import-with-catch on three optional deps:

• jimp (image processing)
• link-preview-js (URL preview)
• qrcode-terminal (CLI QR rendering)

const lib = await Promise.resolve()
  .then(() => require('jimp'))
  .catch(() => undefined);   // graceful skip if require throws
if (lib) { /* use it */ }

esbuild/wrangler does static analysis and refuses to bundle without resolving them, even though they're inside a .catch. End result: Could not resolve "jimp" etc., bundle fails.

Fix: alias the three to a throwing shim in adapters/whatsapp/wrangler.jsonc:

"alias": {
  "ws": "./src/ws-shim.ts",
  "axios": "./src/axios-shim.ts",
  "jimp": "./src/optional-noop-shim.ts",
  "link-preview-js": "./src/optional-noop-shim.ts",
  "qrcode-terminal": "./src/optional-noop-shim.ts"
}

The shim must throw at module-load (not return undefined / a no-op object) so baileys' .catch(() => {}) actually fires and lib becomes undefined. A noop module would let baileys think the dep loaded and crash later when calling methods on it.

3. patch-package patch version skew

adapters/whatsapp/patches/@whiskeysockets+baileys+6.7.21.patch is locked to baileys 6.7.21 but the package.json range ^6.7.17 resolves to baileys 6.17.16 today (note: 6.17 vs 6.7 — semver-level confusion). Postinstall errors with:

Patch file: patches/@whiskeysockets+baileys+6.7.21.patch
Patch was made for version: 6.7.21
Installed version: 6.17.16
patch-package finished with 1 error(s).

Plus an upstream rename — npm reports:

deprecated @whiskeysockets/baileys@6.17.16: The new official package name is "baileys".

Fix: pin baileys to a version that matches the patch (or regenerate the patch against the new resolution; or migrate to the renamed baileys package).

Why I'm raising this as an issue, not a PR

You don't run mise/aube on main — your CI uses npm, and your local dev probably doesn't bundle whatsapp every time. So the failure is silent unless someone tries to build it cleanly. I want the visibility for anyone hitting this from a fresh clone, but the workspaces config + shim approach is something you'd want to land on your terms (probably with the package rename to plain baileys).

If a PR would be useful, happy to put one up.

---

Repro on the fork: joeblew999#1 (commit dba9d21 — the build-fix commit).

[deathbyknowledge]

Thanks for the heads up! Looking into it right now