Modules are the building blocks of an application. Modules are isolated pieces of code that when put together construct the larger functioning application. Node.js accomplishes this abstraction through the CommonJS standard or recently introduced ES module system.

The main idea of modules is to break down large pieces of code into smaller pieces. So by storing relevant code in individual files, code can be plugged into other portions of an application via importing. Importing a file means loading in code that is made available for use within the file.

A simple import statement with CommonJS would be something like the following.

const sample = require('./sample.js');

In CommonJS, importing a file involves using the require() function, which takes in a module identifier, and loads in that module within the current module.

When importing the built-in or third-party modules, the process is the same, a single word module identifier is passed into require().

// built-in module used for creating HTTP servers
const http = require('http');

The other side of this process is the exportation of code so that other modules can access it within their scope.

// sample.js
const sample = 'sample variable string';
const sample2 = 'sample2 variable string';

Expanding on the example above, here we see the structure within “sample.js” that allows other modules to import its API for use. Any code that is defined within a module is private to other modules unless it is explicitly exported. When I tried to log the “sample2” variable, a reference error was thrown because it was not explicitly exported via assignment to the “exports” property on the module object. This is how Node.js allows files access to encapsulated code. Node.js also provides the same exporting functionality via the shorthand “exports” object.

// sample.js
const sample = 'sample variable string';
exports.sample = sample;

As of Node.js version 14.x, the standard JavaScript module system, ES modules, has also been adopted and provides alternatives to utilizing modules along with some key differences. The ES module system utilizes the “import” statement to import modules and does so asynchronously as opposed to the synchronous require() function.

A simple import statement with CommonJS would be something like the following:

// importing with ES Modules
import sample from './sample.mjs';

Aside from the syntactical differences, CommonJS and ES modules provide other key differences. Like the “module” object which is injected by default into each CommonJS module by Node, other values are made available within the modules. The __filename and __dirname are variables that are made available within every CommonJS module, useful for various configurations.

// within a CommonJS module
// by default .js extensionconsole.log(__filename, __dirname); // double underscore

When working with ES modules, these variables are not available and need to be computed. This is carried out by the only value that is injected within ES modules, the “import.meta” property which helps identify the URL which maps to the current module.

Experience with Front-end Technologies and MERN / MEAN Stack. Working on all Major UI Frameworks like React, Angular.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store