bug: Error [ERR_REQUIRE_ESM]: require()

[niyonx]

Provide environment information

I'm getting this error in all my trigger tasks ever since 4.3.3 update.

Describe the bug

Error [ERR_REQUIRE_ESM]: require() of ES Module /var/task/node_modules/.pnpm/superjson@2.2.6/node_modules/superjson/dist/index.js from /var/task/node_modules/.pnpm/@trigger.dev+core@4.3.3_typescript@5.0.4/node_modules/@trigger.dev/core/dist/commonjs/v3/imports/superjson.js not supported.
Instead change the require of index.js in /var/task/node_modules/.pnpm/@trigger.dev+core@4.3.3_typescript@5.0.4/node_modules/@trigger.dev/core/dist/commonjs/v3/imports/superjson.js to a dynamic import() which is available in all CommonJS modules.
    at /opt/rust/nodejs.js:2:13531
    at Function.un (/opt/rust/nodejs.js:2:13909)
    at Ye.e.<computed>.Je._load (/opt/rust/nodejs.js:2:13501)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14) {
  code: 'ERR_REQUIRE_ESM',
  page: '/abc/def'
}

Reproduction repo

n/a

To reproduce

Update NextJS project to 4.3.3

Additional information

No response

[ericallam]

@niyonx what version of Node.js are you using?

[niyonx]

@niyonx what version of Node.js are you using?

v22.4.0

[ericallam]

@claude can you look into this? Doesn't Node.js support requiring ESM modules now? What version did that start? How could we make this backwards compatible without doing dynamic import? Should we just vendor superjson and create our own CJS build

[claude]

Claude finished @ericallam's task in 1m 38s —— View job

---

Investigating ESM/CJS compatibility issue with superjson

• Research Node.js ESM require support
• Examine current superjson import in @trigger.dev/core
• Evaluate solutions for backwards compatibility
• Provide recommendations

---

Findings

1. Node.js require(ESM) Support Timeline

Node.js added support for require() of ESM modules with the following progression:

• v20.17.0, v22.0.0: Initial support added behind --experimental-require-module flag
• v20.19.0, v22.12.0, v23.0.0: Feature no longer behind experimental flag
• v23.5.0, v22.13.0, v20.19.0: No longer emits experimental warning by default
• v25.4.0: Feature is no longer experimental

The user is on v22.4.0, which is before Node 22.12.0 when the flag became enabled by default. So require(ESM) won't work without explicitly enabling the --experimental-require-module flag.

2. Current Package Structure

The @trigger.dev/core package uses tshy to produce dual ESM and CJS builds:

• dist/esm/ - ES module build
• dist/commonjs/ - CommonJS build

The package has a wrapper file packages/core/src/v3/imports/superjson-cjs.cts but the main import at packages/core/src/v3/imports/superjson.ts uses standard ESM import syntax, which tshy transpiles to require() for the CJS build.

3. Root Cause

superjson@2.2.x is ESM-only (has "type": "module" in package.json and only exports ESM). When tshy compiles the CJS build, the import becomes a require() call which fails on Node.js versions before 22.12.0 that don't have require(ESM) enabled by default.

Recommendations

Option A: Vendor superjson with CJS build (Recommended)

Create a vendored copy of superjson as a CJS module. This provides:

• Maximum backwards compatibility (supports Node 18.x+)
• No dependency on experimental Node.js features
• Full control over the build output
• superjson is ~1,000 lines of code and only has one dependency (copy-anything)

Option B: Dynamic import with async initialization

Convert superjson usage to async dynamic imports:

const superjson = await import('superjson');

Downsides:

• Requires making all consumers of superjson async
• Significant refactoring across ioSerialization.ts and other files
• Could affect performance and complicate the API

Option C: Pin superjson to an older CJS version

superjson 1.x was CJS. Could downgrade, but:

• Loses newer features and bug fixes
• May have compatibility issues with newer serialization needs

Option D: Require newer Node.js version

Bump engines.node to >=22.12.0. Downsides:

• Breaks users on Node 18.x LTS, 20.x LTS (up to 20.18), and Node 22.x (up to 22.11)
• Node 18 LTS is supported until April 2025, Node 20 LTS until April 2026

Implementation for Option A

If you'd like to proceed with vendoring superjson, the approach would be:

1. Create packages/core/src/v3/vendor/superjson/ directory
2. Copy superjson source files and the one dependency (copy-anything)
3. Build both as CJS (could use esbuild for this)
4. Update imports to use the vendored version
5. Add a changeset for the fix

Let me know if you'd like me to implement this solution.

[niyonx]

short term fix:

package.json

  "pnpm": {
    "overrides": {
      "superjson": "1.13.3"
    }
  },

[ericallam]

@claude implement option A

[claude]

Claude finished @ericallam's task in 21m 44s —— View job • claude/issue-2937-20260124-2052 • [Create PR ➔](https://github.com/triggerdotdev/trigger.dev/compare/main...claude/issue-2937-20260124-2052?quick_pull=1&title=Issue%20%232937%3A%20Changes%20from%20Claude&body=This%20PR%20addresses%20issue%20%232937%0A%0AGenerated%20with%20%5BClaude%20Code%5D(https%3A%2F%2Fclaude.ai%2Fcode)

---

Implementing Option A: Vendor superjson with CJS build

• Examine current superjson usage in @trigger.dev/core
• Create vendored superjson bundles (CJS and ESM)
• Update imports to use vendored version
• Fix test failures with bundled version
• Add changeset for the fix
• Commit and push changes

Debugging test failures with vendored superjson...

[ChALkeR]

This is a documented and intentional AWS Lambda limitation
They run on a custom-configured Node.js build which disables some default features, including require(ESM)
Which can be re-enabled manually (again, see AWS docs)

Upstream Node.js doc: https://nodejs.org/api/modules.html#loading-ecmascript-modules-using-require

Hopefully, AWS Lamdba will stop doing that

[ChALkeR]

As for Node.js version, Claude is not correct here:

Bump engines.node to >=22.12.0. Downsides:

You can bump engines to ^20.19.0 || ^22.12.0 || >=24.0.0, which will include all non-EOL Node.js branches