DEV Community: Richard Terungwa Kombol

Notes on ES modules and CommonJS module systems: What you may or may not know about them.

Richard Terungwa Kombol — Thu, 14 Dec 2023 21:19:20 +0000

A module is a standalone software component implementing specific functionalities and is easily reusable in different applications.

A module can depend on the functionality provided by another module.
A module exports its functionality for other modules to consume.

Within a module, values that are not explicitly exported are private within the module and cannot be accessed by client modules.

Modules have become very critical in building modern and complex JavaScript applications as they help make code organization in large applications easier to reason about.

JavaScript module systems are standards that define how to write JavaScript modules.

Example module systems include:

CommonJS
ES modules
AMD (Asynchronous Module Definition)

One defining feature of all module systems is that they define how dependencies are loaded into a module that depends on it.

The CommonJS module system has a built-in mechanism to load modules. The require statement triggers this mechanism.

The ES module system has a built-in mechanism to load modules. The import statement triggers this mechanism.

The AMD system makes use of a range of loaders that must be AMD-compatible.
Some of these AMD-compatible loaders include LABjs, Steal.js, yepnope.js, $script.js, bdLoad, and RequireJS.

The process of loading dependencies into a JavaScript module involves:

fetching the JavaScript code from where it is located (OS file system for Node.js, remote server for browsers). This process is the loading phase.
Instantiating the loaded modules.
Evaluating or executing the modules.

The process of instantiating and evaluating modules is synchronous even for ES modules.

It is the process of fetching and loading the modules that could be asynchronous and synchronous depending on the environment.

The different environments have their implementation of the module loaders which are responsible for fetching these files/modules.

The ES module specification says how you should parse files into module records, and how you should instantiate and evaluate that module. However, it doesn’t say how to get the files in the first place.

For browsers, the HTML specification defines how the module loaders should be implemented.

For server environments like Node.js, and because OS file system calls don’t take that long compared to calls over the internet, the process of fetching and loading modules is synchronous.

For browser environments, where modules are fetched over the internet, and networks are generally slower and less predictable than OS file operations, the loading phase is asynchronous to prevent any piece of JavaScript code from delaying the browser's main thread.

In the ES module system, the phase responsible for loading a file is called the construction phase.

The construction phase has 3 steps:

Figure out where to download the file containing the module from (aka module resolution)
Fetch the file (by downloading it from a URL or loading it from the file system)
Parse the file into a module record

Module loading for CommonJS modules is synchronous because the dependencies below it are loaded, instantiated, and evaluated simultaneously, without any breaks in between.

The synchronous constraint for CommonJS modules expects that the module will not produce side effects.

module.exports are not expected to have side effects and thus cannot be set asynchronously.

The synchronous constraint CommonJS demands is the primary reason for synchronous APIs that can be used for initialization tasks.

Note that synchronous means the task blocks on the main thread, and must finish before the next task can be executed. Thus, these sync APIs used for initialization are blocking.

ES modules however do not have this constraint. A module can have side effects like making network connections etc.

Because ES modules can be async is the primary reason why the CommonJS module cannot be used to load an ES module as a dependency. But ES modules can load CommonJS modules.

If you want to load modules that can have side effects in a CommonJS module, there is a Dynamic import method that can help with this.

The Dynamic import method is a key component in code-splitting and lazy loading of JavaScript on demand. This is possible because of the asynchronous nature. The JavaScript code will only be available when it is needed and will not be bundled upfront with other parts that are actually needed.

Node.js Morsel for today: creating symbolic links to your packages locally using `npm link`

Richard Terungwa Kombol — Mon, 24 Jul 2023 13:07:39 +0000

What is a symbolic link?

Symbolic links are operating system operations that facilitate the creation of shortcuts to files or folders. The shortcuts help the user access the folder in places other than the original file location.

Node.js package managers provide the link command to help developers access the folder as packages locally as they would when published on the registry or from git.

How to create a symbolic link with an npm link?

As stated before, npm has a command called a link. For example, I have a project called @terk/color-utils, a library package, but I want to test this package on other projects locally before publishing it on the npm registry. The npm link helps with this.

Start with running the command npm link in the root of the @terk/color-utils folder.

This command with no arguments will create a symbolic link in the global node_modules folder .nvm/versions/node/v18.16.0/lib/node_modules/@terk/color-utils.

Something to note is that the folder name in the global node_module is the name on the package.json name property.

Verify that the link was created using npm ls -g.

Then proceed to the project that intends to use the package and run the command npm link @terk/color-utils in the project root folder.

This action installs the package from the global node_module into the project.

Node.js morsel for today: Understanding Node.js timers

Richard Terungwa Kombol — Tue, 18 Jul 2023 18:56:16 +0000

From the Node.js documentation, Node.js Timers are described as scheduling functions to be called at some future period of time.

Broadly, they refer to the setTimeout, setInterval and setImmediate functions. They are further broken into subgroups defined by the phase of the event loop their handle callbacks are executed.

What are `Handle` callbacks?

Handles represent long-lived objects capable of performing certain operations while active.

Invoking a timer creates a ref’ed handle by default. A ref’ed handle is an active handle with the callback not yet executed.

const immediateHandle = setImmediate(() => {
  console.log('SetImmediate Handle Callback')
});
// Log immediateHandle gives us the handle object
// Immediate {
//   _idleNext: null,
//   _idlePrev: null,
//   _onImmediate: [Function (anonymous)],
//   _argv: undefined,
//   _destroyed: false,
//   [Symbol(refed)]: true,
//   [Symbol(asyncId)]: 2,
//   [Symbol(triggerId)]: 1
// }

The immediateHandle logged out in the code snippet shows 2 properties that are important to the Event Loop.

_onImmediate: this is the callback that will be invoked. setTimeout has _onTimeout.
Symbol(refed): this shows that the handle is active. It becomes null when not active.

The timers Event Loop phase is where the callbacks of the handles created by the setTimeout and setInterval functions are called.

The check Event Loop phase is where the callbacks of the handles created by the setImmediate functions are called.

The _onImmediate callback is invoked on the next iteration of the Event Loop.

The _onTimeout callback is invoked when the current Event Loop's iteration concept of now is ahead of the scheduled time based on the setTimeout threshold.

CSS morsel for today: understanding CSS initial values using the unset keyword

Richard Terungwa Kombol — Tue, 18 Jul 2023 18:54:55 +0000

From its description in the MDN docs, the unset CSS keyword is described as a way to reset a CSS property to its inherited value if the property naturally inherits from its parent, and to its initial value if not.

To understand what this means, say, in a contrived scenario, we are using a CSS media query to render a CSS class that behaves differently on mobile and desktop screens.

.Socials__wrapper--mobile {
  display: flex;
  align-items: center;
  bottom: 0;
  right: 0;
  width: 100%;
  height: 3.4375rem;
  background-color: #fffdf9;
  z-index: 1;
}

The snippet above is meant to run on mobile screens. It is also the default styling for the class Socials__wrapper--mobile. But we want the Socials__wrapper--mobile to behave differently on desktop screens. We do not want certain property values to carry over to desktop styling. On the desktop, we don't want bottom, right, height, or width to be defined. We do this by setting these properties to unset in the media query as shown below.

@media only screen and (min-width: 1024px) {
  /* This should run on tablets and desktops.  */
  .Socials__wrapper--mobile {
    bottom: unset;
    right: unset;
    width: unset;
    height: unset;
    background-color: #fffdf9;
    z-index: 1;
  }
}

Note that the properties bottom, right, width, and height is referred to as non-inherited properties. This means that they don't automatically inherit their values from the encapsulating parent element like say a color property would. And because of this, assigning unset to them means the browser (also referred to as the user agent) assigns the default values defined in the CSS specifications to the properties.

The initial value for the box-model (width, height) and position (top, bottom, etc) properties as defined in the specification is auto. If we replace the unset keyword with auto we get the same effect.

@media only screen and (min-width: 1024px) {
  /* This should run on tablets and desktops.  */
  .Socials__wrapper--mobile {
    bottom: auto;
    right: auto;
    width: auto;
    height: auto;
    background-color: #fffdf9;
    z-index: 1;
  }
}

It is important that auto is the keyword to signify that the browser (user agent) needs to compute this property automatically taking into consideration the context and content. The context could be the behaviour of the parent element.