JavaScript Re-Export

Re-exporting in JavaScript is the process of forwarding module bindings from one module through another without importing those bindings into the current module’s local scope. It combines the import and export declarations into a single statement, allowing a module to act as a pass-through for variables, functions, or classes defined in a different file. Because re-exported bindings are never evaluated in the local scope of the forwarding module, they cannot be accessed or manipulated by the forwarding module itself.

Syntax Variations

JavaScript provides several syntactic forms for re-exporting, depending on whether you are handling named exports, default exports, or entire module namespaces.

1. Named Re-exports

You can selectively forward specific named exports from a target module. You can also alias these exports during the pass-through using the as keyword.

// Forward specific named exports exactly as they are
export { foo, bar } from './moduleA.js';

// Forward specific named exports under new identifiers (aliasing)
export { foo as newFoo, bar as newBar } from './moduleA.js';

2. Namespace Re-exports

You can forward all named exports from a target module using the * wildcard.

// Forward all named exports from moduleA
export * from './moduleA.js';

// Forward all named exports as a single namespace object (Introduced in ES2020)
export * as moduleANamespace from './moduleA.js';

Note: The export * from './moduleA.js' syntax explicitly ignores the default export of moduleA.js. It only forwards named exports.

3. Default Re-exports

Handling default exports requires explicit syntax, as the default keyword is treated as a specific named binding in the ES module system.

// Forward the target's default export as this module's default export
export { default } from './moduleA.js';

// Forward the target's default export as a named export
export { default as moduleADefault } from './moduleA.js';

// Forward a target's named export as this module's default export
export { foo as default } from './moduleA.js';

Technical Constraints and Behavior

Scope Isolation: If you write export { foo } from './moduleA.js';, the identifier foo is not declared in the current file. Attempting to console.log(foo) in the forwarding file will result in a ReferenceError.
Name Collisions: If you use export * from './moduleA.js' and export * from './moduleB.js', and both modules export a binding with the same name, JavaScript will not throw an error immediately. However, a SyntaxError will be thrown when another module attempts to import the conflicted binding from the forwarding module.
Live Bindings: Like standard exports, re-exports maintain live bindings to the original module. If the value of a re-exported variable changes in the originating module, that change is reflected wherever the re-export is consumed.