import/export Modules & Exports (incl. CommonJS interop)
Last updated: 2026-10-23
import/export Modules & Exports (incl. CommonJS interop)
ES Modules is the official JavaScript module standard. TypeScript reuses export/import syntax and brings types into the module system too: types can be exported and imported, and import type imports types only — fully erased after compilation. A barrel file (usually index.ts) re-exports several modules so consumers need a single entry point. Interop with CommonJS is governed by compiler options like module and esModuleInterop.
| Group | Engineering & Practice |
|---|---|
| Kind | Syntax |
| Strict mode | Not required |
ℹ️ Info The editor transpiles TypeScript to JavaScript and runs it (no type checking); see each example's Output for type-check results.
📝 Syntax
// Exporting
export interface User { id: number; name: string } // export a type
export const add = (a: number, b: number) => a + b; // export a value
export default function greet() {} // default export
// Importing
import greet, { add } from "./math"; // default + named
import type { User } from "./types"; // types only, erased after compilation
export * from "./math"; // barrel re-export⚙️ Parameters
| export default | The module's default export, at most one per module; import it with any name and no braces |
|---|---|
| export * from / re-export | The core of barrel files: forwards all named exports of a sub-module; type-only exports are forwarded too |
| import type / inline type | import type { User } and the inline modifier import { type User } both declare a type-only import — no runtime code is emitted |
Returns：Modules return nothing; exported values and types together form the module's public interface for other modules to import.
▶ Example
Edit the code below and click Try it to see the transpiled result:
Output：
Hello, Ada!
add === add2: true
(Runtime output after transpilation; this editor runs as an inline script in the browser and cannot really import across files, so the code above marks the module boundaries in comments and shows an equivalent runnable form — in a real project these are still four separate files, types.ts / math.ts / utils.ts / main.ts, User is a pure type and import type leaves no trace after compilation)💡 Notes
ℹ️ Info import type and importing a type through a normal import behave the same, but import type is explicit and safe under isolatedModules; the type part of both disappears after compilation.
💡 Tip Put the barrel at the src root (index.ts) containing only export * from / export { x } from lines; consumers then import from @/utils instead of deep paths like @/utils/math, and restructuring only touches the barrel.
⚠️ Note CommonJS interop is a common trap: how import default maps to module.exports in compiled CJS is error-prone; esModuleInterop (with module: commonjs) makes behavior spec-compliant, and module: node16/nodenext additionally requires full file extensions on relative imports.
🏷️ Related Engineering & Practice
💡 Related cases
More cases coming soon.
📚 Related tutorials
❓ FAQ
Q What is the difference between import type and a normal import?
A A normal import may compile to a require call even if you only use its types; import type guarantees a type-only import with zero runtime code. Under isolatedModules or with bundler tree-shaking, it avoids keeping a whole package just for its types.
Q When is a barrel file worth creating?
A When a directory exposes more than a handful of modules that consumers import together. Note barrels pull all sub-modules into one dependency graph and can hurt tree-shaking; fine for pure utility libs, evaluate carefully for large component sets where bundle size matters.
Q Why do I get "Cannot use import statement outside a module" at runtime?
A The runtime does not understand ESM syntax: imports were not transformed (target too new or wrong module option), or Node treats .js as CJS. Fix by setting module to commonjs (or letting a bundler handle ESM), using .mjs, or declaring "type": "module" in package.json.
