import/export Syntax Essentials

An ES module uses the export keyword to publish values and the import keyword to bring them in. A file that contains either keyword is a module, and its top level has its own scope rather than sharing the global one.

// ---- math.js, written as an ES module ----
// export const add = (a, b) => a + b;
// export default function multiply(a, b) { return a * b; }
//
// ---- app.js ----
// import multiply, { add } from "./math.js";

function add(a, b) {
  return a + b;
}

function multiply(a, b) {
  return a * b;
}

// The same module written with CommonJS, which is what runs as a plain script:
const mathModule = { add, default: multiply };

console.log(mathModule.add(2, 3));        // 5
console.log(mathModule.default(2, 3));   // 6

There are three import forms. A named import uses braces and pulls one or more specific exports. A default import pulls the default export and gives it any local name you like. And a namespace import uses the star syntax to pull everything into a single object, which is useful when you want to forward a whole module.

Exports work the same way in reverse. You can export a declaration directly by putting export in front of it, you can export a list of existing bindings at the bottom of the file, or you can export something as default, which is the single main export of the module.

Two rules make the system work. A module is evaluated once and its exports are live views, so if a value changes, an importer sees the new value. And imports are hoisted, so you can use an imported binding before the import statement appears in the file, which is a difference from the CommonJS behaviour where the require call has to run first.

A named export publishes a value under a name, and you can publish as many as you like from one file. A default export publishes exactly one value, the main thing the module is for, and it can be imported under any name you choose.

The import side mirrors that. A named import uses braces and has to match the exported name exactly. A default import does not use braces and the local name is entirely up to you, which is why the same module can be imported as multiply in one file and as times in another.

Named exports are the better choice for most code. They are explicit, so a reader can see from the import statement what a module provides. They make it obvious when two names in a file come from different places. And they play much better with refactoring tools and with tree shaking, because a bundler can drop an unused named export but has no idea what to do with a default export that might be used in any way.

Default exports are still useful for the single-purpose module, such as a component file or a utility that does one thing. The convention in that case is that the file name matches the exported name, so a file called Button exports a class called Button.

One detail that catches people: you can have both in the same file. A module can have several named exports plus one default export, and an importer can take the default with a plain name and the named ones with braces in a single statement.