How to Import all Exports from a File in JavaScript/TypeScript
When working with ES modules, you sometimes need to import everything that a file exports into a single, neat object. This is especially useful when a module provides a large number of utility functions or constants, and you want to group them under a single name to keep your code organized. This is known as a namespace import.
This guide will teach you the correct syntax for a namespace import (import * as ...), explain how it works with both named and default exports, and provide a clear best practice for when to use it versus standard named imports.
The Core Method: The Namespace Import (import * as ...)
The import * as ... syntax is the standard and only way to import all exports from a module into a single object.
Syntax:
import * as YourNamespace from './your-file.js';
where
*: A wildcard that means "everything."as YourNamespace: This assigns all the exports to a single object with the nameYourNamespace. You can then access each export as a property on this object.'./your-file.js': The path to the module.
How it Works with Named Exports
This is the most common use case. A module exports multiple, named functions or variables.
For example, you have a utility file that exports several named members, and you want to import all of them.
./utils.js:
// All of these are named exports
export const PI = 3.14159;
export function double(n) {
return n * 2;
}
export const appName = 'My Application';
The solution is to use the namespace import to group all of these under a single identifier, like utils.
./main.js:
import * as utils from './utils.js';
console.log(utils.PI); // Output: 3.14159
console.log(utils.double(10)); // Output: 20
console.log(utils.appName); // Output: 'My Application'
The utils object now acts as a "namespace," containing all the exports from the utils.js file as its properties.
How it Works with Default Exports
The namespace import also works with modules that have a default export. The default export is simply assigned to a property named default on the namespace object.
For example, a module has a default export and you want to access it through a namespace import.
./math.js:
export default function add(a, b) {
return a + b;
}
export const subtract = (a, b) => a - b;
The add function will be available on the .default property.
./main.js:
import * as math from './math.js';
// Access the default export via the .default property
const sum = math.default(5, 5);
console.log(sum); // Output: 10
// Named exports are accessed as usual
const difference = math.subtract(10, 3);
console.log(difference); // Output: 7
Named Imports vs. Namespace Imports: Which to Use?
While the namespace import is powerful, it is not always the best choice. Standard named imports are often more readable and better for modern tools.
The standard approach is Named Imports:
import { PI, double, appName } from './utils.js';
console.log(PI);
console.log(double(10));
Rule of Thumb:
- Use Named Imports (Recommended Best Practice): If you only need a few specific members from a module. This is more explicit, makes your code easier to read, and allows for better "tree-shaking" (a build process that removes unused code), which can reduce your final bundle size.
- Use Namespace Imports: When a module exports a large number of members and you need to use many of them. Grouping them under a namespace can prevent polluting your local scope with too many variable names (e.g.,
const fs = require('fs');in Node.js).
In most modern front-end development, explicit named imports are strongly preferred.
Conclusion
The namespace import is a powerful tool for managing modules with many exports.
- To import all exports from a file, use the
import * as MyNamespace from './file.js'syntax. - Named exports from the module will be available as properties on the
MyNamespaceobject (e.g.,MyNamespace.myFunction). - The default export will be available on the special
.defaultproperty (e.g.,MyNamespace.default). - While useful, prefer explicit named imports (
import { a, b } from ...) for better readability and code optimization unless you have a specific reason to group everything under a single object.