What are modules in JavaScript?

Q: What are modules in JavaScript?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The module-caching claim below was actually run and confirmed inside a real CommonJS script. ## 1. Why This Even Matters — A Story First A shared office supply closet, restocked once at the start of the day, is used identically by every single department that visits it throughout the day — nobody gets their own private, separately-restocked copy of the closet each time they walk in; they all genuinely share the SAME closet, with the SAME contents, set up just once. A module works exactly like that closet: its setup code genuinely runs once, and every file that "visits" it afterward (imports it) genuinely shares that same one result, not a fresh copy each time. ## 2. The Core Idea 📌 **Interview term:** a module is a file with its own private scope, explicit

The problem

Question presented to candidate: "If two different files both do require('./config') (or import from the same module), do they each get their own separate copy of whatever that module exports, or genuinely the same one?"

What a strong answer should cover:

📌 Interview term: a module — a single file with its own private scope — variables/functions declared inside it are genuinely NOT visible outside unless deliberately exported, and code in other files must explicitly import whatever it needs.
📌 Interview term: the real, direct answer to the prompt — verified directly: requiring/importing the SAME module from multiple places genuinely returns the identical, cached object reference every time, not a fresh copy — a module's top-level code genuinely runs only once, the first time it is loaded, no matter how many separate files import it afterward.
📌 Interview term: the two real module systems in JavaScript — CommonJS (require/module.exports) and ES modules (import/export) — covered in much more depth, including their real structural differences (static vs. dynamic resolution), in this bank's own dedicated CommonJS-vs-ES-modules question.
A precise answer names the real, practical benefit modules provide beyond just "splitting files": genuine encapsulation — a module's internal helper variables genuinely cannot leak into or collide with another module's own internal variables, since each module has its own private top-level scope — a real, structural fix for the exact kind of global-scope pollution this bank's own IIFE question covers as the OLDER, pre-module workaround for the identical problem.
A precise answer names that a module's exports are genuinely the ONLY public interface — everything not explicitly exported stays genuinely private to that file, by default, with no special syntax (like an IIFE, covered in this bank's own dedicated question) required to achieve that privacy.

Clarifying questions expected:

None — this is a definitional/technical question; directly answering the prompt's own repeated-import scenario (cached, not re-copied) is the strong signal.

Code / implementation expected: Yes — a real, direct require() caching demonstration (the same reference returned twice) is the clearest, most convincing proof.

modules
es modules
code organization
reusability

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 JavaScript fundamentals interviews. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The module-caching claim below was actually run and confirmed inside a real CommonJS script.

1. Why This Even Matters — A Story First

A shared office supply closet, restocked once at the start of the day, is used identically by every single department that visits it throughout the day — nobody gets their own private, separately-restocked copy of the closet each time they walk in; they all genuinely share the SAME closet, with the SAME contents, set up just once. A module works exactly like that closet: its setup code genuinely runs once, and every file that "visits" it afterward (imports it) genuinely shares that same one result, not a fresh copy each time.

2. The Co

The solution is hidden so you can try first

6 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal proof: requiring the same module from multiple places genuinely returns the identical, cached reference — its top-level code runs only once