CommonJS vs ESM differences in Node.js - Visual Side-by-Side Comparison

Concept Flow - CommonJS vs ESM differences

Start: Module Import

↓

Check Module Type

↓

CJS

↓

Use require()

↓

Module Loaded

↓

Code Execution

This flow shows how Node.js decides between CommonJS and ESM modules, uses different import/export syntax, then loads and executes the module.

Execution Sample

Node.js

const fs = require('fs');
import path from 'path';
module.exports = { read: fs.readFile };
export const version = '1.0';

This code snippet mixes CommonJS and ESM syntax to show their import/export differences.

Execution Table

Step	Action	Syntax Used	Module System	Result
1	Import 'fs' module	require('fs')	CommonJS	fs module loaded synchronously
2	Import 'path' module	import path from 'path'	ESM	path module loaded asynchronously
3	Export read function	module.exports = {...}	CommonJS	Exports object set for CJS
4	Export version constant	export const version = '1.0'	ESM	Named export created for ESM
5	Module execution	N/A	Both	Code runs with respective imports/exports
6	Exit	N/A	N/A	Module loaded and ready

💡 Module finishes loading after all imports and exports are processed

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
fs	undefined	fs module object	fs module object	fs module object	fs module object	fs module object
path	undefined	undefined	path module object	path module object	path module object	path module object
module.exports	{}	{}	{ read: fs.readFile }	{ read: fs.readFile }	{ read: fs.readFile }	{ read: fs.readFile }
version	undefined	undefined	undefined	undefined	'1.0'	'1.0'

Key Moments - 3 Insights

Why can't we use 'import' inside CommonJS modules?

Because 'import' is part of ESM syntax which runs asynchronously and requires the module to be treated as ESM, as shown in steps 2 and 4 of the execution_table.

Why does 'module.exports' work only in CommonJS?

'module.exports' is the way CommonJS defines exports synchronously, as seen in step 3, but ESM uses 'export' keyword instead, shown in step 4.

Can we mix 'require' and 'import' in the same file?

No, Node.js treats files as either CommonJS or ESM. Mixing causes errors unless using special loaders or flags, as the execution_table shows separate handling.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the ESM import syntax used?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Check the 'Syntax Used' column for 'import' keyword.

According to variable_tracker, what is the value of 'module.exports' after step 3?

A {}

B undefined

C { read: fs.readFile }

D '1.0'

💡 Hint

Look at the 'module.exports' row under 'After Step 3' column.

If we replace 'module.exports' with 'export default' in the code, what changes in the execution flow?

A Module system stays CommonJS but exports differently

B Module system switches to ESM and uses 'import' syntax

C No change, both work the same

D Module fails to load

💡 Hint

Refer to concept_flow where export syntax determines module system.

Concept Snapshot

CommonJS uses 'require' and 'module.exports' for synchronous imports/exports.
ESM uses 'import' and 'export' keywords for asynchronous, standard module syntax.
Node.js treats files as either CommonJS or ESM, not both.
Mixing syntax requires special configuration.
ESM supports static analysis and tree shaking.
CommonJS is older, ESM is modern standard.

Full Transcript

This visual execution compares CommonJS and ESM modules in Node.js. It starts by checking the module type, then uses either 'require' for CommonJS or 'import' for ESM to load modules. CommonJS exports use 'module.exports', while ESM uses 'export' keywords. The execution table traces each step, showing how variables like 'fs', 'path', 'module.exports', and 'version' change. Key moments clarify why mixing import styles is not allowed and how exports differ. The quiz tests understanding of syntax usage and module system behavior. The snapshot summarizes the main differences and usage rules for these two module systems.

Practice

1. Which syntax is used to import modules in CommonJS in Node.js?

easy

A. const module = require('module')

B. import module from 'module'

C. module.import('module')

D. load('module')

Solution

1. Step 1: Understand CommonJS import syntax

   CommonJS uses the require function to import modules.

2. Step 2: Compare with other options

   Options A, B, and C are not valid CommonJS import syntax; B is ESM syntax.

3. Final Answer:

   const module = require('module') -> Option A

4. Quick Check:

   CommonJS imports use require() [OK]

Hint: CommonJS uses require(), ESM uses import [OK]

Common Mistakes:

• Confusing ESM import syntax with CommonJS
• Using import in CommonJS files
• Trying to use module.import() which doesn't exist

2. Which of the following is the correct way to export a function in ESM syntax?

easy

A. export = function() {}

B. module.exports = function() {}

C. exports.function = function() {}

D. export default function() {}

Solution

1. Step 1: Identify ESM export syntax

   ESM uses export default to export a default function or value.

2. Step 2: Eliminate CommonJS and invalid options

   module.exports = function() {} and C are CommonJS exports; D is invalid syntax.

3. Final Answer:

   export default function() {} -> Option D

4. Quick Check:

   ESM default export uses export default [OK]

Hint: ESM exports use export default or named export [OK]

Common Mistakes:

• Using module.exports in ESM files
• Trying to use export = which is invalid in ESM
• Confusing exports.function with ESM named exports

3. Given this CommonJS code, what will be the output?

const message = require('./message');
console.log(message);

And the file message.js contains:

module.exports = 'Hello from CommonJS';

medium

A. 'Hello from CommonJS'

B. undefined

C. SyntaxError

D. ReferenceError

Solution

1. Step 1: Understand module.exports in CommonJS

   The file exports a string 'Hello from CommonJS' using module.exports.

2. Step 2: Import and log the exported value

   The require call imports the string, so console.log prints it.

3. Final Answer:

   'Hello from CommonJS' -> Option A

4. Quick Check:

   CommonJS require returns module.exports value [OK]

Hint: require() returns module.exports value [OK]

Common Mistakes:

• Expecting require to return an object by default
• Confusing with ESM import behavior
• Thinking require throws error without .js extension

4. What is wrong with this ESM import statement in a Node.js file?

const fs = require('fs');

medium

A. Missing semicolon at the end

B. require is not defined in ESM modules

C. fs module cannot be imported in Node.js

D. Should use import fs from 'fs' instead

Solution

1. Step 1: Identify module system used

   The code uses require which is CommonJS syntax, but in ESM modules, require is not available.

2. Step 2: Understand ESM import rules

   ESM modules must use import statements; require is undefined.

3. Final Answer:

   require is not defined in ESM modules -> Option B

4. Quick Check:

   require() undefined in ESM [OK]

Hint: require() is undefined in ESM modules [OK]

Common Mistakes:

• Thinking require works in ESM without extra setup
• Confusing missing semicolon as error
• Believing fs cannot be imported in Node.js

5. You want to write a Node.js module that can be imported both by CommonJS and ESM users without errors. Which approach is best?

hard

A. Use module.exports and add a separate export default for ESM

B. Write only CommonJS syntax and use dynamic import() in ESM

C. Use a dual package approach with conditional exports in package.json

D. Write only ESM syntax and rename file to .mjs

Solution

1. Step 1: Understand compatibility challenges

   CommonJS and ESM have different import/export systems, so a single file often can't serve both seamlessly.

2. Step 2: Use Node.js dual package support

   Node.js supports conditional exports in package.json to provide separate entry points for CommonJS and ESM consumers.

3. Step 3: Evaluate other options

   Use module.exports and add a separate export default for ESM mixes syntaxes which doesn't work reliably, C requires dynamic import in consumers, D limits to ESM-only.

4. Final Answer:

   Use a dual package approach with conditional exports in package.json -> Option C

5. Quick Check:

   Dual package conditional exports solve CommonJS/ESM compatibility [OK]

Hint: Use package.json conditional exports for dual support [OK]

Common Mistakes:

• Trying to mix module.exports and export default in one file
• Using only .mjs files limits CommonJS users
• Relying on dynamic import() without package config