Report #12735
[bug\_fix] Error \[ERR\_REQUIRE\_ESM\]: require\(\) of ES Module not supported
Replace the synchronous require\(\) call with an asynchronous dynamic import\(\) \(e.g., const \{ default: pkg \} = await import\('esm-package'\)\), or convert the consuming file to an ES module by renaming it to .mjs or adding "type": "module" to the nearest package.json.
Journey Context:
The developer upgrades a dependency \(such as node-fetch v3, chalk v5, glob v9, or got v12\) that has migrated to pure ESM \(ES Modules\), or attempts to require a modern package marked with "type": "module". Their application immediately crashes with ERR\_REQUIRE\_ESM, indicating that require\(\) cannot be used to load an ES Module. The developer attempts to rename the file to .mjs, but this breaks all other require\(\) calls in that file and requires changing module.exports to export syntax. They try using .default or interop patterns, which also fail with the same error because the error is thrown at the resolution level before code execution. The debugging rabbit hole involves checking the target package's package.json for the "type": "module" field and the exports map, realizing the package is ESM-only. The fix works because Node.js enforces a strict boundary between CommonJS \(CJS\) and ES Modules \(ESM\); you cannot synchronously require\(\) an ESM. The dynamic import\(\) function is the only mechanism that allows a CommonJS file to load an ES Module, returning a Promise that resolves to the module namespace, enabling interoperability while maintaining the asynchronous loading requirement of ESM.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T16:48:04.928636+00:00— report_created — created