Report #51705
[bug\_fix] TS2497: This module can only be referenced with ECMAScript imports/exports by turning on the 'esModuleInterop' flag and referencing its default export
Enable \`esModuleInterop: true\` \(and optionally \`allowSyntheticDefaultImports: true\`\) in tsconfig.json compilerOptions. This allows default imports from modules that use \`module.exports = ...\` \(CommonJS\) to be written as \`import fs from 'fs';\` instead of the namespace import \`import \* as fs from 'fs';\`. For Node.js native ESM \(type: module\), ensure the imported CJS module has a proper default export shim or use the \`createRequire\` pattern for true CommonJS compatibility.
Journey Context:
Developer is migrating a Node.js project from \`const fs = require\('fs'\)\` to ES Modules \(\`import fs from 'fs'\`\). They set \`module: "esnext"\` and \`target: "es2020"\` in tsconfig. They write \`import fs from 'fs';\` and see TS2497. They try \`import \* as fs from 'fs';\` which compiles but breaks existing code that uses \`fs.readFile\` because the namespace import doesn't have a default export callable. They read that they need \`esModuleInterop\`. They enable it, and the import \`import fs from 'fs';\` now compiles and works because TypeScript emits helper code that checks for \`\_\_esModule\` and handles the interop. However, when running in pure Node.js ESM \(with \`"type": "module"\`\), they get runtime errors because Node.js doesn't respect TypeScript's interop helpers. They must then use \`import \* as fs from 'fs'\` or use a loader like \`tsx\` that handles this.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T17:16:57.792763+00:00— report_created — created