Importing from a Module

A module must import references it wants to use, such as primitives, functions, objects, or classes exported by other modules. The import directive should specify the location of the module or file to load. The path may be a relative path, an absolute path, or the name of the module file. In the last case, the location is decided based on the runtime environment and configuration; for example, Node may pick the module from the node_modules directory. The path in general does not include the file extension. JavaScript offers a variety of import options—choose the one that best meets your needs.

Importing Named Exports

There are two rules to bring in named exports from another module. First, the name specified in the import for the reference should match the exported name. Second, the names have to be specified within a {} block. Let’s create a module that imports some references from the temperature module.

The temperature-operations module currently imports only two of the different exports from the temperature module. It imports the inlined export of FREEZING_POINT and the given name celsiusToKelvin for c2k. The reference name c2k is not visible outside of the temperature module and so that reference can’t be imported. Once we import the desired references, we can access them as shown in the last line. The list of names within {} can include any of the named exports from the module specified at the tail end of the import directive.

Resolving Conflicts

Conflicts may occur in one of two ways. A name exported by a module may collide with a name used within the module that is importing that reference. Or a module may be importing two references with the same name from two different modules and those names collide. Thankfully, there are a few workarounds.

Suppose we have a home module with a Thermostat class, as well as a temperature module with a Thermostat class, and a module imports Thermostat from both the temperature module and the home module, like so:

This will result in a fatal error:

One approach to resolve this is to import at least one of the references as a different name.

Alternatively, you can import the exports from one of the modules into a namespace object, like so:

All the exports from the home module are imported into a namespace object, home, in this example. In the module with the previous imports, Thermostat refers to the variable in the temperature module. To access the Thermostat in the home module, an explicit namespace resolution, home.Thermostat, is needed. We’ll delve more into importing into namespaces soon, but first let’s look at importing defaults.

Importing a Default Export

Unlike named exports, default exports do not have a name other than default. Here’s a rather odd but legal way to import the default export from the temperature module.

The import is mapping the default exported name from the temperature module to the name uom for use within the imported module. We can reduce some noise by replacing { default as uom } with uom, like so:

On the importing side, default exports may be given any name that the importing modules desire, like uom in this example.

Importing Both Default and Named Exports

The {} syntax gives access to named exports while the syntax without {} surrounding a name indicates an import of default export. In one import directive we can bring in both the default export, if present, and any of the named exports.

Here uom stands for the imported name of the default export. The names in the {} should match the exported names; you can also use as to give a different name, like brrr in the example.

Importing Everything into a Namespace

If a module will use a number of exports from a module, it can be tedious to mention the name of each one of the desired references within {}. You can ask JavaScript to bring over all of them using the wildcard.

Let’s invite all named exports from the temperature module to the party:

When using wildcards, the exports are imported into a namespace object, heat in this case. The name of the namespace object is at the discretion of the importing module, but the properties imported into the namespace have their respective exported names from the exporting modules.

A wildcard brings over all exports from the specified module, except the default export. If you don’t want the default export to feel left out of the party, do it a favor and send an invite, like so:

While the exported references from the temperature module can be accessed by reaching into the namespace heat, the default export of that module can be accessed using the given uom name.

Importing for Side Effects

On rare occasions we may not need anything to be imported from a module, but we may want to run the code contained in a module for its side effects. A module, when executed, can place some classes into the window object in a browser, for example. The file may not really export any references, or even if it does, we may not care about them at that point. In that case, to have the module file executed without really importing anything, we can use an import followed by the module filename. For example:

will run the specified module without importing anything.

Even though this feature exists, avoid creating modules that cause side effects. Generally, such code becomes hard to maintain and to test, and is error-prone.