Report #38462
[bug\_fix] TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'
The target package is ESM-only \('type': 'module' in its package.json\) but TypeScript is configured to output CommonJS. Update tsconfig.json to emit ESM: set 'module': 'NodeNext' \(or 'ES2022'\) and 'moduleResolution': 'NodeNext'. Ensure your package.json includes 'type': 'module'. If you must remain in CJS, downgrade the dependency to a CJS-compatible version \(e.g., node-fetch v2 instead of v3\) or use a dynamic import\(\) for the ESM module.
Journey Context:
Developer installs a modern package \(e.g., 'node-fetch' v3 or 'got' v12\) in a legacy TypeScript project. The tsconfig.json has 'module': 'commonjs' and 'target': 'es2017'. Immediately upon importing the package, TypeScript throws an error indicating the file is an ESM module and cannot be required. Developer tries adding 'esModuleInterop': true or 'allowSyntheticDefaultImports': true, but the error persists. They search and find that the package is ESM-only. They consider using 'require' with a dynamic import but TypeScript warns about top-level await or async context. The realization is that TypeScript's module output must match the target package's module type when using static imports. Switching 'module' to 'NodeNext' aligns TypeScript's emit with Node.js's native ESM resolution, allowing the import to resolve correctly.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T19:02:14.241859+00:00— report_created — created