How to import everything from a module in JavaScript

Using the import everything syntax in JavaScript can be a powerful tool for developers looking to streamline their code. The syntax allows you to import all exported members from a module under a single namespace. This can be particularly useful when you have a module with multiple exports and you want to keep your code organized.

import * as myModule from './myModule.js';

myModule.functionOne();
myModule.functionTwo();

This approach not only reduces the number of import statements you need to write, but it also makes it clear that the functions or variables you’re using originate from the same module. This can enhance readability and maintainability, particularly in larger projects.

Another practical use of this syntax is when you want to quickly prototype or test functionality from a module without having to explicitly import each function or variable. Instead of cluttering your code with numerous import statements, you can simply import everything at once and use it as needed.

import * as utils from './utils.js';

const result = utils.calculateSum(5, 10);
console.log(result);

However, while the import everything syntax can simplify your imports, it can also lead to large namespaces that may contain more than you actually need. This can increase memory usage and make it harder to determine where specific functions or variables are defined, especially when collaborating with others.

It’s essential to balance the convenience of this syntax with the potential downsides, particularly in larger applications where clarity and performance are crucial.

import * as allFunctions from './largeModule.js';

allFunctions.firstFunction();
allFunctions.secondFunction();

When using this syntax, it’s a good practice to think how the imported namespace will be used throughout your code. This can help you avoid unnecessary bloat and keep your codebase lean and efficient. Additionally, if you are only using a small portion of the module’s exports, it might be more efficient to import only what you need:

import { specificFunction } from './module.js';

specificFunction();

This targeted approach not only improves performance but also enhances the readability of your code by making it clear which specific functionalities are being used. It creates a clear mapping between the imports and their usage, which can be particularly beneficial during debugging and maintenance.

Managing namespace collisions when importing all

One of the challenges that arises when using the import everything syntax is managing namespace collisions. Since all exported members from the module are gathered under a single object, the risk of name clashes is generally reduced compared to importing everything directly into the local scope. However, collisions can still occur when multiple modules are imported with similar or identical namespaces.

Consider the following example where two modules export functions with the same name:

import * as mathUtils from './mathUtils.js';
import * as stringUtils from './stringUtils.js';

const result = mathUtils.calculate(10, 20);
const formatted = stringUtils.calculate('Hello World');

Here, both modules export a calculate function, but because they’re imported as separate namespaces (mathUtils and stringUtils), you can safely use both without conflict. That’s the primary advantage of importing everything under a namespace: it scopes the imports and prevents direct collisions.

Problems arise when you try to merge namespaces or re-export imported members without renaming. For example:

import * as moduleA from './moduleA.js';
import * as moduleB from './moduleB.js';

export const combined = {
  ...moduleA,
  ...moduleB
};

If both moduleA and moduleB export a function or variable with the same name, the spread operator will cause the latter to overwrite the former silently, leading to unexpected behavior.

To handle such collisions, you can explicitly rename conflicting imports when re-exporting or combining namespaces:

export const combined = {
  ...moduleA,
  calculateB: moduleB.calculate,
  otherFunctionB: moduleB.otherFunction
};

This approach makes naming conflicts explicit and forces you to ponder carefully about which version of a function or variable you want to use. Alternatively, you can alias the entire namespace during import to distinguish usages more clearly:

import * as moduleA from './moduleA.js';
import * as moduleB as moduleBAlt from './moduleB.js';

moduleA.calculate();
moduleBAlt.calculate();

Note that the import * as alias from ... syntax does not allow for aliasing during import itself (the as keyword is used only within the import { ... } syntax). To rename an entire namespace, you must choose a unique identifier when importing:

import * as moduleBAlt from './moduleB.js';

Being deliberate about namespace names helps avoid confusion and collisions in larger codebases where many modules are imported simultaneously.

In cases where you find yourself frequently needing to disambiguate imports because of naming collisions, it might be a sign that your modules are not well-factored or that the API surface is too large. Refactoring modules into smaller, more focused units can alleviate this by reducing the chance of overlapping export names.

Additionally, tools like TypeScript provide static analysis that can warn about such collisions ahead of time, making it easier to maintain clean and collision-free imports.

When integrating third-party libraries, namespace collisions can also occur if multiple libraries export similar utilities. In those situations, selectively importing only what you need or wrapping imports in your own namespaces can help:

import * as lodash from 'lodash';
import * as underscore from 'underscore';

const result1 = lodash.map([1, 2, 3], x => x * 2);
const result2 = underscore.map([1, 2, 3], x => x + 1);

This explicit scoping reduces ambiguity and helps maintain clarity about which implementation is being used.

Finally, when exporting your own modules that aggregate others, consider carefully how to expose the combined API to avoid unintentional collisions. For example, instead of blindly re-exporting everything:

export * from './moduleA.js';
export * from './moduleB.js'; // May cause conflicts if names overlap

Use selective re-exports or rename conflicting exports:

export { funcA } from './moduleA.js';
export { funcB as funcBFromModuleB } from './moduleB.js';

This practice keeps your module’s public API explicit and manageable, preventing namespace pollution and conflicts downstream.

Managing namespace collisions effectively requires a combination of thoughtful import naming, selective importing, clear API design, and sometimes refactoring. The import everything syntax is a tool that can help organize code, but it must be applied with an awareness of these potential pitfalls to maintain a clean, understandable codebase.

When you find that namespace collisions are becoming cumbersome to manage, it may be time to reconsider whether importing everything is the best approach. In many cases, importing specific members explicitly not only avoids collisions but also improves the readability and maintainability of your code.

For example, instead of:

import * as utils from './utils.js';

const { calculate, format, parse } = utils;

You can directly import what you need:

import { calculate, format, parse } from './utils.js';

This makes dependencies clearer and reduces the surface area for potential naming conflicts. It also enables contemporary bundlers and tree-shakers to eliminate unused code more effectively, improving application performance.

Nonetheless, there are scenarios where importing everything under a namespace is appropriate—especially when dealing with modules that export a large number of related utilities intended to be used together. In those cases, managing namespace collisions carefully through naming conventions and selective re-exports is the key to maintaining a clean codebase.

When to avoid importing everything from a module

Despite its convenience, there are several scenarios where importing everything from a module is best avoided. One significant drawback is the potential for increased bundle size, especially in environments where tree-shaking is not fully effective. When you import an entire namespace, the bundler may include all exports from that module, even those you do not use, resulting in unnecessary code bloat.

This can be particularly problematic when working with large utility libraries or frameworks that export many functions and constants. For example, importing everything from a library like Lodash can pull in the entire library, whereas selectively importing only the functions you need keeps your bundle lean:

import * as _ from 'lodash';
// Potentially imports all of lodash, increasing bundle size

import { map, filter } from 'lodash';
// Imports only map and filter, enabling tree-shaking and smaller bundles

Another situation to avoid using the import everything syntax is when the module exports functions or variables with generic names that can easily clash with local identifiers or other imports. Using named imports in this case reduces ambiguity and clarifies exactly what is being brought into scope.

Consider a module that exports a function named init. Importing everything under a namespace might seem safe, but if you destructure or merge namespaces, it can lead to confusion:

import * as helpers from './helpers.js';

function init() {
  // local init function
}

// Later in code
helpers.init(); // Clear: calls helper's init
init();         // Calls local init

But if you destructure or re-export without caution, the distinction blurs, and bugs may creep in. Explicit named imports can help maintain clarity:

import { init as helperInit } from './helpers.js';

function init() {
  // local init function
}

helperInit(); // Unambiguous call to helper's init
init();       // Local init function

Additionally, importing everything can obscure the dependencies of a module. When you explicitly import only what you need, it creates a clear contract of which functionalities are used. This helps future maintainers understand the code quickly and supports automated tools that analyze dependencies.

From a tooling perspective, some IDEs and static analyzers provide better autocomplete and refactoring support when named imports are used instead of a large namespace object. This can improve developer productivity and reduce errors.

Finally, in tests or modules with a limited scope of functionality, importing everything may be overkill. Importing only the necessary parts keeps the test focused and easier to read, avoiding the mental overhead of a large namespace object.

For example, instead of:

import * as mathHelpers from './mathHelpers.js';

test('adds numbers', () => {
  const result = mathHelpers.add(2, 3);
  expect(result).toBe(5);
});

Prefer:

import { add } from './mathHelpers.js';

test('adds numbers', () => {
  const result = add(2, 3);
  expect(result).toBe(5);
});

Source: https://www.jsfaq.com/how-to-import-everything-from-a-module-in-javascript/

You might also like this video