ESM vs CommonJS

CommonJS is the older system, and it is what Node was built on. It is a runtime system. You call the require function, it returns the exports object, and the code runs immediately as it is required. Everything about it is decided at runtime.

ES modules are the standard system. The import and export keywords are static, so the module graph is built before any code runs. The engine knows exactly what each module imports and exports without executing anything, which is what makes tree shaking possible and what lets it refuse to load a module whose import is misspelled until it is actually needed.

Five differences come up in interviews. Imports are hoisted, so you can use an imported binding before the import statement in the file. Exports are live views, so a change to an exported variable is visible to importers without re-importing, whereas the CommonJS exports object is a snapshot. CommonJS can export a value conditionally or in a loop, and ES modules cannot, because the export list is fixed at parse time. And ES modules support a top level await, which lets a module wait for data before it finishes loading.

There is a practical consequence too. CommonJS is synchronous by default, so requiring a heavy module blocks the event loop. ES module loading is asynchronous, so a large graph does not stall the server in the same way.

The example shows the shape of each system. CommonJS hands you a mutable exports object that you can inspect and change at runtime. ES modules publish fixed, named bindings that importers read through a namespace object.

// CommonJS: a runtime object you can inspect and mutate.
const exportsObject = {};
exportsObject.version = "1.0";
module.exports = exportsObject;

console.log(typeof module.exports);        // "object"
console.log(Object.keys(module.exports));  // ["version"]
console.log(module.exports.version);       // "1.0"

// ES modules: named bindings, published by name and read through a namespace.
const esmNamespace = {
  get version() { return "1.0"; },
  add(a, b) { return a + b; },
};

console.log(esmNamespace.version);        // "1.0"
console.log(Object.keys(esmNamespace));   // ["version", "add"]

// A dynamic import returns a module namespace object at runtime.
import("node:path")
  .then((mod) => console.log("imported:", typeof mod.join))
  .catch((err) => console.log("import failed:", err.message));

The CommonJS side is genuinely mutable. You can add a property after the module has been required and every holder of that exports object sees it. That is why a lot of older libraries attach helpers to the exports object after the fact, and why two libraries that both extend the same module can collide.

The ES module side is deliberately not like that. The export list is fixed when the file is parsed, and an import is a binding to a live value rather than a copy. If the exporting module changes the value, an importer that reads it later sees the new value. The namespace object reflects that too, which is why it exposes the bindings through accessors.

The dynamic import at the end is the one part of the ES module system that is dynamic, and it is the bridge between the two worlds. It returns a promise for the namespace object, so you can load a module at runtime based on a value, and it is usable from CommonJS code, which is how most migrations are done.

You look for the globals that each system defines. CommonJS provides require, module and exports. An ES module provides none of them, because the module scope of an ES module has no access to the CommonJS wrapper.

// Node exposes the module system in a few ways.
console.log(typeof require);   // "function" in CommonJS
console.log(typeof module);    // "object" in CommonJS
console.log(typeof exports);   // "object" in CommonJS

// In an ES module those names are not defined at all.
try {
  console.log(typeof require);
} catch (err) {
  console.log(err.name);   // "ReferenceError"
}

// A dynamic import works in both module systems.
import("node:path").then((mod) => {
  console.log("dynamic import:", typeof mod.join);   // "function"
});

Note the ordering in the output. The first three lines print the function and objects, and the try block succeeds without throwing, because this file is running as a CommonJS module. If you ran the same file as an ES module, the first three lines would print the type name of a missing value, since the typeof operator is safe on a name that does not exist, and the try block would catch the ReferenceError instead.

That difference between typeof and a bare reference is worth knowing, because it is the technique used for feature detection. The typeof operator never throws for a name that was never declared, so it is safe to use on a possibly missing global.

In practice you rarely need this. The package type field in the nearest package.json decides which system a file uses, and every modern tool understands both. The detection matters when you are writing a library that has to work in both, and you need to know whether you can use require or import without breaking the host.