ESM-only exports break CJS consumers — missing "default" or "require" condition

[anmol098]

Problem

The following packages ship with "type": "module" and only an "import" condition in their exports field:

• chat
• • @chat-adapter/whatsapp
• • • @chat-adapter/shared
• • • • @chat-adapter/state-memory
• • • • • @chat-adapter/state-redis
• • • • • • @resend/chat-sdk-adapter (and its dependency remend)
            This means CJS consumers (projects with "module": "commonjs" in tsconfig) get the following error at runtime:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in .../node_modules/@chat-adapter/whatsapp/package.json

Node's CJS loader looks for a "require" or "default" condition in exports. Since only "import" is present, resolution fails.

Expected

Either:

1. Add a "default" condition pointing to the same ESM file — Node 22.12+ supports require() of synchronous ESM natively, so "default": "./dist/index.js" is sufficient
2. 2. Or ship a separate CJS build with a "require" condition

Current workaround

Using pnpm patch to manually add "default": "./dist/index.js" to each package's exports — but this must be re-applied on every version bump.

Environment

• Node.js v23.11.0
• • pnpm 9.x

[sakgoyal]

why do you need CJS at all? Everything supports ESM now so you can just do that instead right?

[bensabic]

Thanks for the detailed report. You’re right about the immediate cause: the current packages publish type: "module" and only expose import conditions in exports, so require() from a CommonJS project won’t resolve.

These packages are intended to be ESM-only today, so CJS consumption is not something we officially support right now. That said, the current failure mode is confusing, and we should make the packaging/docs clearer so this doesn’t read like an accidental omission.

We’re not planning to add separate CJS builds at the moment. If we improve compatibility here, the most likely direction would be adding a default condition to the existing ESM entrypoints rather than maintaining dual ESM/CJS outputs.

For now, the supported path is to consume these packages from an ESM project, or use dynamic import() from CJS where that’s workable. I’m treating this as an interop/docs follow-up rather than a supported CJS bug.