Question 1

What are the key differences between ES modules and CommonJS?

Accepted Answer

ESM is static and asynchronous-friendly with import/export; CommonJS uses sync require/module.exports and is still common in Node legacy code. ESM: static structure enables tree-shaking, top-level await (in modules), strict mode by default, and live live-bindings for exports. CJS: dynamic require, copies of exported values for primitives, sync loading. Node interop can be tricky (createRequire, dual packages). Browsers natively support ESM via type="module". Prefer ESM for new code; understand CJS for ecosystem maintenance.

Question 2

Explain default vs named exports and re-exports. What pitfalls exist?

Accepted Answer

Named exports are explicit and tree-shake friendly; default exports are singular sugar that can confuse renames; re-exports forward module public API. Prefer named exports for APIs with multiple symbols and clearer refactors. Default exports allow any import name, which can hurt consistency and some tooling. export { x as y } from './mod' builds barrels — convenient but can accidentally bloat bundles if barrels re-export everything. Circular dependencies behave differently than people expect — design acyclic graphs. Use import type in TypeScript to erase types.

Question 3

How many times is an ES module evaluated, and how does that affect singletons?

Accepted Answer

Each module is evaluated once per module map/realm; subsequent imports get the same exports — module scope is a natural singleton. The module graph deduplicates by resolved URL (and attributes). Side effects in module scope run once, which is useful for registering singletons and dangerous for unintended side effects. Hot Module Replacement and multiple bundles/copies of the same library can create multiple evaluations — classic 'duplicate React' issues. Dynamic import() still returns the same module namespace after first load. Design modules to be idempotent when possible.

Question 4

What happens with circular dependencies in ESM, and how do you fix them?

Accepted Answer

ESM allows cycles with live bindings, but you may read undefined before initialization finishes; fix by breaking cycles or deferring access. If module A imports B while B imports A, exports exist as live bindings but may be uninitialized when accessed during evaluation — TDZ-like surprises for let/const exports. Symptoms: undefined functions at startup. Fixes: extract shared code to a third module, inject dependencies, convert to functions that look up later, or redesign APIs. Bundlers may warn. Treat cycles as design smells in domain layers.

Question 5

How would you design package exports for a library supporting both ESM and CJS consumers?

Accepted Answer

Use package.json exports conditional maps carefully, avoid dual-package hazards, and publish clear ESM-first entrypoints with tested interop. Dual package hazard: two copies of a module loaded via ESM and CJS break singletons (instanceof fails). Prefer ESM-only when possible, or a thin CJS wrapper that re-exports without duplicating state. exports field restricts deep imports and maps import/require/types conditions. Provide type: module or .mjs/.cjs extensions deliberately. Document node/browser conditions. Test in both Jest/Node and bundlers. Version breaking export map changes carefully. Lead-level packaging decisions affect the whole ecosystem of consumers.

Modules JavaScript Interview Questions

Other JavaScript interview topics