Let’s start by clarifying the difference between a module and a module system. A module is the actual piece of software, while a module system is the syntax and tools that let us define and use modules in our projects.

No matter the programming language or the platform, a good module system should help with some fundamental needs of software engineering:

• Organizing code: It should allow the code base to be split into multiple files. This keeps the code more organized and easier to understand, and enables independent development and testing of different parts.
• Code reuse and dependency management: A good module system should make it easy to share and reuse functionality across projects while handling dependencies in a straightforward way. Developers should be able to build on existing modules, including third-party ones, and users should be able to import a module together with everything it requires without friction.
• Encapsulation...

Not all programming languages come with a built-in module system, and JavaScript lacked this feature for a long time after its inception.

When writing JavaScript code for the browser, it is possible to split the code base into multiple files and then import them by using different <script> tags. For many years, this approach was good enough to build simple interactive websites, and JavaScript developers managed to get things done without having a fully-fledged module system.

Only when JavaScript browser applications became more advanced and frameworks like jQuery, Backbone, and AngularJS took over the ecosystem did the JavaScript community come up with several initiatives aimed at defining a module system that could be effectively adopted within JavaScript projects. The most successful ones were asynchronous module definition (AMD), popularized by RequireJS (nodejsdp.link/requirejs), and later universal module definition (UMD...

Before diving straight into ES modules, it’s worth taking a brief detour to explore a foundational JavaScript pattern, the revealing module pattern, a pattern that facilitates information hiding and will be useful in building a primitive module system. This background will not only deepen our appreciation of fully-fledged module systems like ES modules and CommonJS but also provide a great opportunity to see how these module systems can be implemented behind the scenes. As such, this pattern will become a foundational piece of knowledge that will help us to deeply understand ES modules.

As we said, modules are the bricks for structuring non-trivial applications and the main mechanism to enforce information hiding by keeping all the functions and variables that are not explicitly marked to be exported private.

One major issue with JavaScript in the browser is the lack of namespacing. Since every script runs in the global scope, both internal...

ES modules were introduced as part of the ES2015 specification with the goal of giving JavaScript an official module system suitable for different execution environments. The ES modules specification tries to retain some good ideas from previous existing module systems like CommonJS and AMD. The syntax is very simple and compact. There is support for cyclic dependencies and the possibility to load modules asynchronously.

Using ES modules in Node.js

As previously discussed, when ES modules were introduced in Node.js, CommonJS had already long been...

As we’ve already mentioned throughout this chapter, CommonJS is gradually being replaced by ES modules, and it’s now recommended to use ES modules for new projects and libraries. However, CommonJS is not officially deprecated, and given its long-standing role in the JavaScript ecosystem, it’s still important to have a basic understanding of it. This knowledge will enable you to work confidently with older code bases and libraries.

Let’s have a look at the basic syntax of CommonJS.

Two of the main concepts of the CommonJS specification are as follows:

• require, which is a function that allows you to import a module from the local filesystem.
• exports and module.exports, which are special variables that can be used to export public functionality from the current module.

A simple CommonJS module might look like this:

// math.cjs
'use strict'
function add(a, b) {
  return a + b
}
module.exports...

Let’s now discuss some important differences between ES modules and CommonJS and how the two module systems can work together when necessary.

Strict mode

As opposed to CommonJS, ES modules run implicitly in strict mode. This means that we don’t have to explicitly add the 'use strict' statements at the beginning of every file. Strict mode cannot be disabled; therefore, we cannot use undeclared variables or the with statement or have other features that are only available in non-strict mode. However, this is definitely a good thing, as strict mode is a safer execution mode.

Top-level await

Top-level await allows developers to use await at the top level of a module, simplifying asynchronous code without...

When using different module systems in TypeScript, it’s important to understand that TypeScript is a superset of JavaScript, designed to integrate smoothly with various ecosystems and platforms, including browsers, Node.js, and other JavaScript environments. As a compiler (or transpiler), TypeScript handles modules in two main contexts: how you structure your code with modules during development (input or detected modules) and the format of modules when your TypeScript code is compiled into JavaScript (output or emitted modules). TypeScript can even convert between different module systems, allowing you to write code using ES modules and compile it to CommonJS, for example.

The way TypeScript operates can vary from project to project and is determined by the tsconfig.json configuration file. This file offers a wide range of options with considerable flexibility, which can sometimes be overwhelming and make it difficult to achieve the desired...

In this chapter, we explored the need for modules in JavaScript and the evolution of module systems in Node.js, focusing on CommonJS and ES modules. We covered key concepts like named and default exports, static and dynamic imports, and the module resolution algorithm. We also discussed the implications of circular dependencies, module loading phases, and how modules can modify others.

We then looked at the differences between CommonJS and ES modules, including interoperability challenges, strict mode, and missing references. Additionally, we addressed the impact of monkey patching on type safety in TypeScript projects.

We examined how to import JSON files in both module systems and workarounds for their limitations. Finally, we discussed how to leverage ES modules when using TypeScript.

With this knowledge, you’re now equipped to use both ES modules and CommonJS effectively, laying the groundwork for the next chapter on asynchronous programming in JavaScript...