fix!: require @workos-inc/node >=10.4.0 (eventemitter3 Vite dev crash #106)

[nicknisi]

Summary

Fixes #106. Pins the transitive @workos-inc/node peer floor to >=10.4.0, the version that removed eventemitter3.

Root cause

The TanStack Start client hydration entry imports the app's src/start.ts, which imports authkitMiddleware from this package's main entry. In Vite dev there's no tree-shaking, so the whole server barrel — including its transitive @workos/authkit-session → @workos-inc/node chain — is eagerly evaluated in the browser. @workos-inc/node 8.11.1–10.3.x bundled eventemitter3, whose CJS index.js (default-imported by its own index.mjs) cannot be served as raw ESM by Vite, so the browser throws:

Uncaught SyntaxError: The requested module '.../eventemitter3/index.js' does not provide an export named 'default' (at index.mjs:1:8)

@workos-inc/node@10.4.0 replaced eventemitter3 with an internal emitter, removing the landmine at the source.

Why this fix

• The crash is in a transitive dependency; the cure is ensuring consumers resolve @workos-inc/node >= 10.4.0.
• This package doesn't import @workos-inc/node directly (it's @workos/authkit-session's peer), so we declare the floor as a peer here to enforce it for consumers. It intersects with authkit-session's ^8 || ^9 || ^10 to an effective >=10.4.0 <11.
• engines.node bumped to >=22.11.0 to match what @workos-inc/node@10 requires (it dropped Node 20 in v9).

Why this never reproduced in example/

example/ consumes the SDK via a workspace:* symlink whose real path is outside node_modules, so Vite pre-bundles @workos/authkit-session with esbuild and fixes the CJS interop — masking the crash. A real install (npm/pnpm/bun) serves it raw and crashes. (The production build-based leak check can't catch this either — Rollup tree-shakes the prod bundle clean.)

Breaking change

• Requires @workos-inc/node >= 10.4.0.
• Requires Node >= 22.11.

Consumers on an older @workos-inc/node / Node 20 will get a peer/engine warning prompting the upgrade.

Test plan

• pnpm build (typecheck + emit) — passes
• pnpm test — 234 passing (incl. exports.spec.ts; error classes still exported from the main entry)
• cd example && pnpm build — passes
• pnpm run build:check — no server fingerprints in the client bundle
• Reproduced eventemitter3 default export error still occurs in Vite dev with v0.9.1 #106 in a real Bun isolated install on @workos-inc/node < 10.4.0, and confirmed >= 10.4.0 removes eventemitter3 from the client module graph

[devin-ai-integration]

Devin Review found 1 potential issue.

[greptile-apps]

Greptile Summary

• Raises the package runtime requirement to Node >=22.11.0.
• Adds @workos-inc/node as a peer dependency at >=10.4.0 to avoid the Vite dev crash from older transitive WorkOS Node versions.
• Updates pnpm-lock.yaml so the resolved dependency graph uses @workos-inc/node@10.4.0 and drops eventemitter3.

Confidence Score: 4/5

The dependency floor addresses the Vite dev crash, but the unbounded WorkOS peer range leaves installs open to unsupported future major versions.

The change is small and localized to package metadata and lockfile updates, and the dependency-range issue is specific and reproducible from declared package contracts.

package.json

T-Rex Logs

What T-Rex did

• T-Rex ran the requested verification, but its local artifact references were not uploaded.
• Two runs of the node check script were performed: the base run returned exit code 0 with peerDependencies.@workos-inc/node: <missing>, and the head run returned exit code 0 with peerDependencies.@workos-inc/node: >=10.4.0 and authkit-session resolved as 0.6.0(@workos-inc/node@10.4.0).
• Two dependency-inspection steps were observed with pnpm: before, pnpm why eventemitter3 showed a chain to @workos-inc/node@8.13.0, and after the install there was no dependency chain and @workos-inc/node@10.4.0 was resolved, with eventemitter3 paths removed from node_modules and the lockfile reflecting the change.
• Engine checks were run: the before state allowed Node >=20.0.0 for the install, while the after state required Node >=22.11.0 for @workos-inc/node@10.4.0, alignment was true, and a simulated Node 20.9.0 engine-strict error was reported.

_{Ran code and verified through T-Rex}

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
package.json:73
**Cap WorkOS major**

This package relies on `@workos/authkit-session@0.6.0`, whose peer contract only supports `@workos-inc/node` through major 10. The new `>=10.4.0` peer range also accepts future major versions, so a consumer can install a version that satisfies this package while violating the downstream session package's supported API range, causing peer conflicts or an unsupported dependency pair once v11 exists. Encoding the intended intersection keeps installs on the tested `>=10.4.0 <11` range.

_{Reviews (1): Last reviewed commit: "chore: pnpm-lock" | Re-trigger Greptile}

[greptile-apps]

Cap WorkOS major

This package relies on @workos/authkit-session@0.6.0, whose peer contract only supports @workos-inc/node through major 10. The new >=10.4.0 peer range also accepts future major versions, so a consumer can install a version that satisfies this package while violating the downstream session package's supported API range, causing peer conflicts or an unsupported dependency pair once v11 exists. Encoding the intended intersection keeps installs on the tested >=10.4.0 <11 range.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: package.json
Line: 73

Comment:
**Cap WorkOS major**

This package relies on `@workos/authkit-session@0.6.0`, whose peer contract only supports `@workos-inc/node` through major 10. The new `>=10.4.0` peer range also accepts future major versions, so a consumer can install a version that satisfies this package while violating the downstream session package's supported API range, causing peer conflicts or an unsupported dependency pair once v11 exists. Encoding the intended intersection keeps installs on the tested `>=10.4.0 <11` range.

How can I resolve this? If you propose a fix, please make it concise.

[gjtorikian]

Because of fix!, we should double check if this will promote from 0.9 -> 0.10 or 0.9 -> 1.0, the latter of which is undesirable.

According to semver, breaking changes before a 1.0.0 release do not require a major version bump.