How to fix 'esModuleInterop' and 'allowSyntheticDefaultImports' require module resolution in TypeScript

### Understanding esModuleInterop vs allowSyntheticDefaultImports

These two options solve different but related problems:

allowSyntheticDefaultImports (type checking only):

This option tells TypeScript to allow default imports from modules that don't have a default export. It only affects TypeScript's type checker - no JavaScript code is changed:

// CommonJS module (lodash)
// module.exports = { map, filter, reduce, ... }

// With allowSyntheticDefaultImports: true
import _ from "lodash";  // Type checking allows this
// But emits: const _ = require("lodash"); // Won't work at runtime!

esModuleInterop (runtime code generation):

This option emits additional helper code to make default imports work correctly with CommonJS modules:

import _ from "lodash";

// Emits:
var __importDefault = (this && this.__importDefault) || function (mod) {
  return (mod && mod.__esModule) ? mod : { "default": mod };
};
const lodash_1 = __importDefault(require("lodash"));
// Now lodash_1.default works correctly

Setting esModuleInterop: true automatically enables allowSyntheticDefaultImports and generates the runtime helpers.

### Module Resolution Strategies Explained

TypeScript supports several moduleResolution strategies:

classic - Legacy strategy, rarely used today. Doesn't support node_modules.

node - Traditional Node.js CommonJS resolution:
- Looks in node_modules
- Supports package.json "main" field
- Default for module: "commonjs"

node16/nodenext - Modern Node.js with ES module support:
- Respects package.json "type": "module"
- Supports "exports" field
- Requires .js extensions in relative imports
- Auto-enables esModuleInterop

bundler - For Vite, webpack, esbuild:
- Supports package.json "imports" and "exports"
- Never requires file extensions
- Assumes bundler handles module resolution
- Auto-enables esModuleInterop

### When to Use Each Configuration

Building a library for npm:

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler",
    "esModuleInterop": true,
    "declaration": true
  }
}

Node.js backend (CommonJS):

{
  "compilerOptions": {
    "module": "commonjs",
    "moduleResolution": "node",
    "esModuleInterop": true,
    "target": "ES2020"
  }
}

Node.js backend (ES modules):

{
  "compilerOptions": {
    "module": "node16",
    "moduleResolution": "node16",
    "target": "ES2022"
  }
}

Note: With node16, you must use .js extensions in relative imports even though source files are .ts:

// WRONG
import { foo } from "./utils/helper";

// CORRECT
import { foo } from "./utils/helper.js";

React frontend (bundled):

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler",
    "jsx": "react-jsx",
    "esModuleInterop": true
  }
}

### Why This Requirement Exists

In older TypeScript versions, you could set esModuleInterop without moduleResolution, leading to ambiguous behavior. Modern TypeScript enforces that these interop options must be paired with an explicit resolution strategy because:

1. The interop code generated depends on how modules are resolved
2. Different resolution strategies have different rules (e.g., file extensions)
3. Type checking behavior differs based on resolution mode
4. It prevents misconfigured projects that compile but fail at runtime

### Checking Your Configuration

Verify your current configuration:

npx tsc --showConfig

This outputs the final resolved configuration including defaults, helping you see exactly what TypeScript is using.