Describe the Node.js module system. What are CommonJS and ES Modules?

Q: Describe the Node.js module system. What are CommonJS and ES Modules?

**Target Audience:** Engineers preparing for Node.js phone screens — assumes basic `import`/`export` syntax familiarity. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every interop claim below was **actually executed** on Node v24.19.0, including a genuinely surprising interop detail found while testing rather than assumed. ## 1. Why This Even Matters — A Story First Two countries share a border and mostly get along, but they run on different legal systems — one common-law, one civil-law — each fully coherent on its own terms. A contract written under one system does not automatically make sense read under the other's rules; crossing the border with any agreement requires a deliberate, well-defined translation step, not just goodwill. CommonJS and ES Modules are Node's two legal systems. `package.json`'s `"type"` field decides which one a file lives under; the interop rules are th

The problem

Question presented to candidate: "A file uses import/export syntax and another uses require()/module.exports in the same project. What determines which system a given file uses, and can the two actually interoperate?"

What a strong answer should cover:

Node supports two distinct module systems: CommonJS (CJS) — require()/module.exports, synchronous, Node's original system — and ES Modules (ESM) — import/export, the standard JavaScript module system, asynchronous-capable, file-extension- or package.json-determined.
Which system a .js file uses is decided by package.json's "type" field: "type": "module" makes .js files ESM; its absence (or "type": "commonjs") makes them CJS. The explicit extensions .mjs (always ESM) and .cjs (always CJS) override the package.json setting file-by-file, regardless of "type".
📌 A verifiable, not just documented, distinction: require is genuinely undefined inside a real ESM file — calling it throws a ReferenceError, not a discouraged-but-working fallback.
ESM importing CJS works one direction cleanly: a default import receives the entire module.exports object. A named import additionally works for properties Node's static analysis (cjs-module-lexer) can detect as simple assignments — but this is a best-effort heuristic, not a full guarantee, for dynamically-computed CJS exports.
CJS require()-ing ESM used to be impossible entirely (only dynamic import() worked); modern Node (from Node 22, broadening in later releases) allows require() to load a synchronous ES Module directly, with one hard exception (top-level await) — covered with its own live verification in the dedicated require(esm) question.
A precise answer keeps CJS and ESM's caching mechanisms conceptually distinct even though both cache: CJS keys its cache by resolved file path; ESM's module registry keys by resolved URL — this matters for edge cases like the same file reached via different URL forms.

Clarifying questions expected:

"Is the codebase fully ESM, fully CJS, or a mix?" — decides how much of the interop-specific detail actually matters here.
"Is the concern about how to WRITE interop code, or just understanding which system a given file uses?" — different depths of the same topic.

Code / implementation expected: Yes — showing a real ESM file importing a CJS file (and vice versa, referencing the dedicated require(esm) question) with the actual observed export shapes is the concrete, convincing version of this answer.

modules
commonjs
es modules
dependencies

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js phone screens — assumes basic import/export syntax familiarity. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every interop claim below was actually executed on Node v24.19.0, including a genuinely surprising interop detail found while testing rather than assumed.

1. Why This Even Matters — A Story First

Two countries share a border and mostly get along, but they run on different legal systems — one common-law, one civil-law — each fully coherent on its own terms. A contract written under one system does not automatically make sense read under the other's rules; crossing the border with any agreement requires a deliberate, well-defined translation step, not just goodwill.

CommonJS and ES Modules are Node's two legal systems. `packag

The solution is hidden so you can try first

7 min read · 10 sections

Read the code

JavaScriptESM exporting named + default, require() genuinely absent inside it, and ESM importing a CJS module's real export shape

// math.js (package.json has "type": "module")
export function add(a, b) { return a + b; }
export default function multiply(a, b) { return a * b; }

// main.js
import multiply, { add } from "./math.js";
console.log(add(2, 3), multiply(2, 3)); // 5 6
try {
  require("./math.js");
} catch (e) {
  console.log(e.message); // require is not defined
}

// cjs-mod.cjs
module.exports = { greeting: "hello from cjs" };
module.exports.extra = "bonus";

// import-cjs.mjs
import pkg from "./cjs-mod.cjs";
import * as ns from "./cjs-mod.cjs";
console.log(pkg); // { greeting: 'hello from cjs', extra: 'bonus' }
console.log(Object.keys(ns)); // [ 'default', 'extra', 'module.exports' ]
console.log(ns.default === ns["module.exports"]); // true

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.