CommonJS vs ESM differences in Node.js - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does CommonJS handle module exports compared to ESM?

Which statement correctly describes how CommonJS and ESM export modules in Node.js?

A CommonJS uses module.exports to export a single object, while ESM uses export statements to export multiple bindings.

B CommonJS uses export statements like ESM but requires a special flag to work.

C ESM uses module.exports to export a single object, while CommonJS uses export statements.

D Both CommonJS and ESM use the same syntax: export default and export named.

💡 Hint

Think about how you write exports in a CommonJS file versus an ESM file.

CommonJS modules export a single object using module.exports. ESM allows multiple named exports and a default export using export syntax.

❓ component_behavior

intermediate

What happens when importing a CommonJS module in ESM?

Given an ESM file importing a CommonJS module, what is the shape of the imported object?

Node.js

import pkg from './commonjsModule.js';
console.log(typeof pkg);

A "string" because CommonJS exports are converted to strings in ESM.

B "function" because CommonJS exports are always functions in ESM.

C "undefined" because ESM cannot import CommonJS modules.

D "object" because the entire CommonJS export is wrapped as the default export in ESM.

💡 Hint

Think about how ESM treats the CommonJS module.exports object when imported.

When importing a CommonJS module in ESM, the entire module.exports object is available as the default export, so its type is "object".

📝 Syntax

advanced

Identify the syntax error in mixing CommonJS and ESM imports

Which option contains a syntax error when mixing CommonJS require and ESM import in the same file?

Node.js

import fs from 'fs';
const path = require('path');

A Both import and require can be used without errors in the same file.

B Using import fs from 'fs' in a CommonJS file causes a syntax error.

C Using require('path') in an ESM file causes a syntax error.

D Using import fs from 'fs' requires a .cjs file extension.

💡 Hint

Consider the file type and module system when mixing import and require.

In an ESM file, using require() causes a syntax error because require is not defined. You must use import statements only.

🔧 Debug

advanced

Why does this ESM import fail when importing a CommonJS module?

Given this ESM code importing a CommonJS module, why does accessing a named export fail? commonjsModule.js: module.exports = { greet: () => 'hi' }; esmFile.mjs: import { greet } from './commonjsModule.js'; console.log(greet());

A Because the CommonJS module does not export greet as a default export.

B Because CommonJS exports are treated as a default export in ESM, named imports like { greet } are undefined.

C Because ESM cannot import CommonJS modules at all.

D Because the import path is missing the file extension.

💡 Hint

Think about how named imports work with CommonJS default exports.

CommonJS modules export a single object as default in ESM. Named imports expect named exports, so { greet } is undefined.

❓ state_output

expert

What is the output of this mixed CommonJS and ESM code?

Consider these two files: commonjsModule.cjs: let count = 0; module.exports.increment = () => ++count; module.exports.getCount = () => count; esmFile.mjs: import { increment, getCount } from './commonjsModule.cjs'; console.log(increment()); console.log(getCount()); What will be the output when running esmFile.mjs with Node.js configured for ESM?

A Throws a TypeError because named imports from CommonJS are undefined.

B 0 and 0 printed on separate lines.

C 1 and 1 printed on separate lines.

D Throws a SyntaxError due to mixing module types.

💡 Hint

Recall how named imports work with CommonJS default exports in ESM.

Named imports from a CommonJS module fail because the entire export is treated as a default export object. So increment and getCount are undefined, causing a TypeError.

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