Modules

// source.ts (ES Module syntax)
export function add(a: number, b: number): number { return a + b; }

// compiled output, if 'module': 'commonjs'
// exports.add = function (a, b) { return a + b; };

Common follow-ups: How do you decide which 'module' setting to use for a given project type?

import type { User } from './types';
import { fetchUser } from './api';

function display(user: User) { /* ... */ } // 'User' never exists in compiled JS output

Common follow-ups: What happens if you accidentally use 'import type' for something you also need as a runtime value?

// Without esModuleInterop, this often fails or needs `import * as x`
// With esModuleInterop: true
import express from 'express'; // works cleanly, even though express uses module.exports

Common follow-ups: What alternative, more verbose import syntax would you need without esModuleInterop enabled?

// tsconfig.json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": { "@components/*": ["src/components/*"] }
  }
}

// usage.ts
import Button from '@components/Button'; // instead of '../../../components/Button'

Common follow-ups: Why doesn't configuring 'paths' alone make the aliases work at runtime in a plain Node.js script?

// With isolatedModules: true, this needs 'export type' explicitly:
export type { User } from './types'; // OK
// export { User } from './types'; // Error if User is type-only and isolatedModules is on

Common follow-ups: Does isolatedModules perform any type-checking itself, or is it purely a structural/syntax constraint?

// a.ts
import { b } from './b';
export const a = 'A';
console.log(b); // may be undefined at this point due to the cycle, regardless of TS

// b.ts
import { a } from './a';
export const b = 'B';

Common follow-ups: Why can't TypeScript's static type checker fully prevent this class of runtime circular-dependency bug?

// assets.d.ts
declare module '*.svg' {
  const content: string;
  export default content;
}
declare module '*.css' {
  const styles: Record<string, string>;
  export default styles;
}

// usage.tsx
import logo from './logo.svg'; // typed as string

Common follow-ups: How would you type a CSS Modules import to get autocomplete on the specific class names it exports?

// tsconfig.json
{
  "compilerOptions": {
    "moduleResolution": "bundler" // matches modern bundler resolution behavior closely
  }
}

Common follow-ups: Why was the 'bundler' moduleResolution setting introduced as an alternative to 'node' / 'node16'?

// index.ts (barrel file)
export * from './Button';
export * from './Modal';
export * from './Tooltip';
// A consumer importing only { Button } may still pull in extra work/analysis for Modal and Tooltip

Common follow-ups: What alternative import strategies help mitigate these barrel-file downsides in a large component library?

// mathLib.ts
export default function add(a: number, b: number) { return a + b; }
export const PI = 3.14159;

// consumer.ts (with esModuleInterop: true)
import add, { PI } from './mathLib';

Common follow-ups: What subtle bug can occur if a CommonJS-compiled module's default export handling doesn't match what a consumer's bundler expects?