{"id":"l-js-5-1","courseId":"javascript-fundamentals","lang":"en","kind":"lesson","summary":"Split a growing program into modules with export and import, load them in the browser with type=“module” from a dev server, and organise Pocket into files with clear jobs.","html":"

Pocket now has money helpers, validation, storage, rendering, event handlers and network code. In one file that is several hundred lines, every function can see every variable, and changing one part means scrolling past all the others. Real programs are split into files, each with one job, and JavaScript’s way of doing that is modules.

\n

A module is a file with its own scope

\n

In a module, top-level variables and functions are private to that file. To share something, you export it. To use something from another module, you import it:

\n
src/money.js
export function toCents(dollars) {\n  return Math.round(dollars * 100);\n}\n\nexport function formatMoney(cents, symbol = \"$\") {\n  return `${symbol}${(cents / 100).toFixed(2)}`;\n}\n\nconst SECRET_ROUNDING_NOTE = \"not exported, so only this file can see it\";
\n
src/main.js
import { toCents, formatMoney } from \"./money.js\";\n\nconsole.log(formatMoney(toCents(12.2)));
\n

The curly braces list the named exports you want. The path starts with ./, meaning “relative to this file”, and in the browser it includes the .js extension. SECRET_ROUNDING_NOTE cannot be imported at all; that is the point. Each module decides what it offers, and everything else is hidden, much like the closures from section 2, at file level.

\n

A few more forms you will see:

\n
src/main.js
import { formatMoney as fmt } from \"./money.js\";   // rename on import\nimport * as money from \"./money.js\";                // everything, as money.toCents etc.
\n

There is also a default export, one per file, imported without braces and under any name you like: export default function renderApp() {} and then import renderApp from "./ui.js". Many teams prefer named exports, and so does this course: a named export has the same name in every file that uses it, so search and automatic renaming in your editor work reliably.

\n

Loading modules in the browser

\n

The entry file is loaded with type="module", and it imports everything else:

\n
index.html
<script type=\"module\" src=\"./src/main.js\"></script>
\n

Module scripts behave a little differently from the classic scripts you have used so far. They are deferred automatically, so the DOM is ready when they run. They run in strict mode, which turns some silent mistakes into errors. And each module runs once, however many files import it, so a module-level variable is shared by all its importers.

\n\n

In practice, most projects use a build tool such as Vite. It serves your modules during development, lets you import packages from npm by name (import { something } from "some-package"), and at build time bundles everything into a few optimised files. The import and export syntax you write is exactly the same.

\n

Modules in Node.js

\n

Node.js supports the same syntax. A file is treated as an ES module when the nearest package.json contains "type": "module", or when the file name ends in .mjs. (Recent Node.js versions also detect import syntax in a plain .js file, but setting "type" explicitly is clearer.) You will also meet the older Node.js system, CommonJS, which uses require() and module.exports; it is still common in existing projects, but new code uses import and export.

\n

Organising Pocket

\n

A good split follows jobs, and keeps the parts that touch the outside world separate from the pure logic:

\n
\n main.js imports from ui.js, storage.js and expenses.js. ui.js imports from money.js. expenses.js and money.js are pure logic that never touch the page or storage.\n \n main.js\n \n ui.js\n \n storage.js\n \n expenses.js\n \n money.js\n \n \n \n \n green: pure logic, no DOM, no storage\n
Pocket’s modules and what imports what
\n\n

The rule behind the split: dependencies point from the outside in. main.js knows about everything; expenses.js knows about nothing but data. That means you can test, or reuse in Node.js, the core logic without a browser, and you can swap localStorage for a server later by changing one file.

\n\n

This course’s playground runs one file at a time, so the practice below is about reading module code. In the next lesson you will meet another way to organise code, classes, which group data with the functions that act on it.

\n","toc":[{"id":"sec-1","text":"A module is a file with its own scope","level":2},{"id":"sec-2","text":"Loading modules in the browser","level":2},{"id":"sec-3","text":"Modules in Node.js","level":2},{"id":"sec-4","text":"Organising Pocket","level":2}],"takeaways":["A module is a file with its own scope; nothing in it is visible to other files unless it is exported.","Prefer named exports (export function formatMoney), which keep the same name everywhere and are easy to search for.","In the browser, load the entry file with <script type="module">, use relative paths with the .js extension, and serve the files over http.","In Node.js, files are ES modules when the nearest package.json has "type": "module" or the file ends in .mjs.","[object Object]"],"further":[{"title":"JavaScript modules (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules"},{"title":"export (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export"},{"title":"Modules: ECMAScript modules (Node.js)","url":"https://nodejs.org/api/esm.html"}],"quiz":[{"q":"

The browser console says Uncaught SyntaxError: Cannot use import statement outside a module. What is the fix?

","options":[{"text":"Rename the file from .js to .mjs.","why":"The browser does not decide by file extension. It decides by how the script tag loads the file."},{"text":"Move the import lines to the bottom of the file.","why":"Imports are allowed only in modules, wherever they appear. Moving them does not make the file a module."},{"text":"Wrap the imports in a function.","why":"Static import statements must be at the top level of a module; inside a function they are a syntax error."},{"text":"Load the entry file with <script type="module" src="./main.js">.","why":"Correct. Without type="module", the browser runs the file as a classic script, where import is not allowed."}],"answer":3},{"q":"

money.js declares function toCents(d) { … } without export. What happens when main.js runs import { toCents } from "./money.js";?

","options":[{"text":"It works, because all top-level functions are shared between modules.","why":"Each module has its own scope. Only exported names can be imported."},{"text":"Loading fails with a SyntaxError saying money.js does not provide an export named toCents.","why":"Correct. Imports are checked before any code runs, so the mistake is reported immediately."},{"text":"toCents is imported as undefined and the error appears when you call it.","why":"Named imports are linked before the code runs; a missing export stops the module graph from loading at all."}],"answer":1},{"q":"

You open index.html by double-clicking it, and the module script fails to load with a CORS error. Why?

","options":[{"text":"Module scripts are blocked from file:// pages, so the files must be served over http, for example by a dev server.","why":"Correct. Browsers apply stricter loading rules to modules. Any local server, such as the one Vite starts, fixes it."},{"text":"Modules only work after the site is deployed to the internet.","why":"A local server on your own computer is enough. Deployment is not required."},{"text":"The browser is too old to support modules.","why":"Every current browser has supported modules for years. The problem is the file:// origin, not the browser."}],"answer":0}],"exercise":{"kind":"spot-bug","language":"js","code":"// src/money.js\nexport function formatMoney(cents) {\n return `$${(cents / 100).toFixed(2)}`;\n}\nfunction toCents(dollars) {\n return Math.round(dollars * 100);\n}\n\n// src/main.js (loaded with