Named, Default and Re-exports

There are three export forms and four import forms, and knowing them all is what lets you read any module file quickly.

On the export side. You can put export in front of a declaration, so the declaration and the export happen together. You can export a list of existing bindings at the bottom of the file with a single export statement. And you can mark one binding as the default export, which is the module's main export and is the only one you can have per file.

On the import side. A named import uses braces and pulls one or more specific exports. A default import has no braces and gives you the default export under a name you choose. A namespace import uses the star syntax and gives you an object containing every export. And you can combine a default and named imports in one statement by putting the default name first and the named ones in braces after it.

Re-exports let a module forward what another module exports. The export from form forwards specific names, the star form forwards everything except the default, and you can also re-export a default under a new name. A module that gathers exports from several files and publishes them as one is called a barrel file, and it is a common way to give a package a single entry point.

One warning about barrels. Every file in the barrel is loaded when anything in the barrel is imported, so a barrel that re-exports large modules can slow down your start-up time and bloat your bundle. Many teams keep one barrel for the public API and use direct imports internally.

The example models a module namespace so the import patterns can be shown in a script that runs anywhere. The real syntax is in the comments.

// A module namespace object, modelled so it can run in a plain script.
const mathModule = {
  add(a, b) { return a + b; },
  multiply(a, b) { return a * b; },
  default(a, b) { return a - b; },
};

// Named import: pick one property by name.
const { add } = mathModule;
console.log(add(2, 3));   // 5

// Default import: pick the default export, under any name.
const subtract = mathModule.default;
console.log(subtract(5, 2));   // 3

// Namespace import: take everything.
const math = mathModule;
console.log(Object.keys(math));   // ["add", "multiply", "default"]

// A re-export forwards a binding without changing it.
const publicApi = { ...mathModule, version: "1.0" };
console.log(publicApi.version);   // "1.0"
console.log(publicApi.add(1, 1));  // 2

// The real syntax:
// export { add, multiply } from "./math.js";
// export { default } from "./math.js";
// export * from "./math.js";

The distinction that matters most in practice is between named and default exports. A named export says what it is. The import statement reads as a list of things the module provides, and a reader can see at a glance what they are getting. A default export says only that this is the main thing, and the name at the import site is chosen by the importer, so two files can import the same module under completely different names.

That flexibility is also the downside. When the name can change at every import site, searching for where a function is used means searching for every possible name, and renaming the export means touching every importer.

The re-export lines in the comments are the other pattern worth knowing. They let a package present a curated public API from several internal modules, so consumers import from one place rather than reaching into the internals. The star form forwards every named export but not the default, which is why the default needs its own line.

Renaming happens in the import statement, with a colon. It works for named imports and for the default export, and the two can be combined in a single statement.

const mathModule = {
  calculate: (n) => n * 2,
  default: (n) => n + 1,
};

// Renaming a named import.
const { calculate: double } = mathModule;
console.log(double(21));   // 42

// Importing a default export under any name.
const { default: increment } = mathModule;
console.log(increment(5));   // 6

// Both in one statement.
const { calculate, default: fallback } = mathModule;
console.log(calculate(3), fallback(3));   // 6 4

The most common reason to rename is a name clash. If two modules both export a function called format, you can import one of them as formatDate and keep the other as formatNumber without renaming anything in the source modules. That keeps the change local to the importing file rather than rippling outwards.

The other reason is clarity. When the default export of a module is called something very generic, giving it a descriptive name at the import site makes the calling code read better, and the reader does not have to open the file to find out what the function actually does.

One thing to keep in mind. Renaming an import creates a new local name that only exists in that file. If you rename in one place and not in another, the same function will appear under two different names across your code base, which makes searching for its usage harder. Renaming is a local convenience, not a renaming of the export.