Understanding Module Specifier

Nick Baughan — Wed, 19 Mar 2025 18:28:25 +0000

In my previous post, to keep things simple all code files are living together in the same directory. When importing, specifying "./" and then the name of the file tells the compiler or bundler to look in the current directory to find the file. This simple setup works fine for a simple demonstrative example, but in a real project with even a little bit of complexity we need to organize our files better.

The specifier part of an import statement is how you indicate where the file is located. As I already mentioned, using "./" indicates "look in the current directory". But the files you need in many cases are probably within a subdirectory. In the example below all of the math functionality has been cleaned up and moved into its own folder.

Now, from the index.js file, to access the add.js file, you would need to use the module specifier "./calculator/add.js". This is saying "look in the current directory for a folder named 'calculator', then inside of it, grab the file named 'add.js'"

A feature of the module specifiers spec is that if a file isn't explicitly declared in the import statement, the compiler will look for a file named "index.js". This can be used to organize functionality and to clean up the amount of import statements for the consuming code. As you can see below, all of the operation and constants are imported to an index file, where they can be imported with only one import statement.

The calculator could be refactored and organized itself. With constants and operations moved to their own nested directory we would need to update our module specifier to take into account the new folder structure.

All of these examples have started with "./" since the subdirectories are in the same folder as the consuming code, but that might not always be the case. Let say that some code wants to import code from a sibling level directory. While “./” can be used to access the current directory, “../” will access one directory higher.

In the example below, the circle that lives in the operations folder is able to import a file from the constant folder by using "../" to navigate outside of its current directory. That will take it to the calculator directory, where it can access the constants directory.

This can be done recursively as needed. The deeper the consuming code is relative to the needed code, the more "../" are used. You can combine these like "../../", which would take you two directories higher.

A good way to think about it is that "./" puts you in the directory of the current file. "../" takes you one directory higher. These patterns can be combined to access and expose code as needed.

In the next post I'll cover a few more module specifier patterns.

JavaScript Modules: An Introduction

Nick Baughan — Wed, 19 Mar 2025 17:36:41 +0000

When I began as a web developer, one of the first projects I worked on had multiple JavaScript files all loaded into the browser using script tags. This was a fragile method for managing multiple files. With one file having a dependency on another, the ordering of these script tags were critical. One script tag out of order would crash the application.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Script Tag Example</title>
</head>
<body>
    <script src="https://code.jquery.com/jquery-3.7.1.js"></script>
    <script src="./scripts/main.js"></script>
</body>
</html>

In the example above, since jquery.js is a dependency of main.js, failure to load JQuery will throw an error! Or if the ordering of the script tags were reversed, main.js would try and use JQuery before it had been loaded into the browser. In a simple example like this it doesn't seem too difficult to manage, but with a large production application with multiple developers, it was a nightmare. When trying to refactor and clean up old script tags, a mistake could crash the app.

Another problem was that everything was loaded onto the global scope. It wasn't very hard to overwrite a variable by accident. Declaring a new variable with the same name of an already existing variable and the first variable was replaced(This was before ES6 introduced "const"). This would lead to bugs and unexpected behavior.

JavaScript started as a simple scripting language for the browser, mostly used for form validation and adding a bit of interactivity to otherwise static html pages.
In time developers began using the language to build larger and more dynamic applications. The codebase being used for web applications was growing. Splitting code between files and using third party libraries was a headache. The JavaScript ecosystem needed a module system.

The JavaScript community began to experiment and design their own module systems. CommonJS and Asynchronous Module Definition were two early specifications. For a time I was most familiar with Asynchronous Module Definition, or AMD for short. Working with ESRI's JavaScript API, which was built on the Dojo Toolkit gave me plenty of experience with the AMD pattern.

But in 2015 the JavaScript specifications finally included a built in module system. JavaScript Modules or ES6 Modules, while not immediately implemented, is today the standard in all browsers and NodeJS.

JavaScript Modules uses import and export statements to share code between files.

There are multiple ways to export code.

Named Exports

This is called a named export and will export the add function.

Using the below syntax, the function can be imported and used within another file.

You also have the ability to export multiple named exports, like in the snippet below

correspondingly, you would import these like this.

Another useful trick is to rename a named export when importing it.

This will allow two named exports with the same name, to be used in the same file and avoid variable collision. This is most common when using multiple third party code, where you don't have control over naming.

Default Exports

Another way to export is using a default export.

As a sidenote, a default export can be named within the exporting file and it will work the same. The name you give it will have no effect when importing it. The below snippet would work just the same.

const pi = 3.14;
export default pi;

Naming the default export pie will work the same as pi. It really doesn't matter how you alias a default import, as long as it isn't a JavaScript reserved word.

import pie from "./constants.js";

const radius = 3;
const radiusSquared = radius * radius;

console.log(pie * radiusSquared);

A file can have only one default export by definition and when importing it, it can be aliased with any name.

Another way that you will often see default exports used is with Object Property Shorthand. In the default export statement, an object literal will be created with all of the variables as the objects properties. The imported variable will be an object that contains all the exported functionality as the object's properties.

And of course you can mix named and default exports.

Module Object

One last module pattern I will mention is creating a module object with the import. By using the syntax import * as [object variable] from [source] you can wrap all of the imported functionality into a convenient object in the consuming code. '[object variable]' can be replaced with a variable name the contain the imported object. '[source]' can be replaced with the file location or the module identifier to indicate where the code lives.

Take a look at the refactor below for an example. Now the consuming code is importing the functionality into an object being aliased as 'calculator', and has the methods 'add' and 'subtract' bundled into it. A nice way to keep your code a bit cleaner.

In the next article I will go into more details about module identifiers.

DEV Community: Nick Baughan

Understanding Module Specifier

JavaScript Modules: An Introduction

Named Exports

Default Exports

Module Object