From CommonJS/Require to ES modules the easy way

Michael Richardson - Mar 9 '23 - - Dev Community

Introduction

When Node.js was first conceived, jQuery as a community; had embraced the AMD pattern and RequireJS in particular. Node.js was designed to run JavaScript code outside of a web browser, and as such, it needed a module system that was optimized for server-side development. CommonJS was the solution that was chosen because it fit the requirements of the Node.js ecosystem at the time.. CommonJS was the resulting solution and has been used in Node.js since v0.x.

Meanwhile, the browser has continued to evolve sought to address the need that RequireJS was filling. With ECMAScript 6 (ES6), ECMAScript modules (ESM) were introduced.

ESM is a newer module format that is part of the ECMAScript language specification, and it provides a standard way to define modules in JavaScript. ESM provides a number of benefits over CommonJS, including better performance, improved compatibility with tooling and bundlers, and better support for static analysis and tree-shaking.

Since the release of ECMAScript 6, many JavaScript environments have added support for ESM, including Node.js, web browsers, and many other runtimes.

FAQ First

1. What is CommonJS?

CommonJS module system is the default module system within the NodeJS ecosystem. CommonJS modules are the original way to package JavaScript code for Node.js. In terms of the loading paradigm for CommonJS, modules are loaded synchronously and are processed in the same order that the JavaScript runtime locates them. CommonJS provides require()

2. What are ES modules (ESM)?

The ES module usage format is the official standard to write JavaScript for maximum reusability and is what most web browsers natively support and Node.JS has fully supported since 12.x (experimental support as early as 9.x.)

3. What are major difference between CommonJS and ESM?

CommonJS is synchronous whereas ES is asynchronous
CommonJS supports only runtime resolution whereas ES supports both parse time and runtime
ESM support interoperability whereas CommonJS do not

CommonJS is the original standard in Node.js whereas ES recently achieved stable support and has been in in browsers for 5+ years
Common JS uses require() and ESM uses import export

4. What are the benefits of CommonJS?

CommonJS is the default standard and is supported in all Node.js versions. It is resolved at Runtime and has a wide amount of Dev support since it has been there since the beginning of Node.JS

5. Does Node.js use CommonJS?

Yes, CommonJS was the default Standard for module inclusion.

6. Does Node.js use ES Modules (ESM)?

Yes, ESM is fully supported since Node.js 12.x

7. Is CommonJS going away?

There is no sunset date on CommonJS, but it's not native to ecmascript as ESM is so it might be expected to be deprecated at some point in favor of ESM and, it is worth noting that many developers are now migrating to ESM, especially for new projects or where the benefits of ESM outweigh the costs of migration.

Commonjs/Requirejs/AMD pattern

function foo() {}

modules.exports = foo;
Enter fullscreen mode Exit fullscreen mode

Use

foo = require('foo');`
Enter fullscreen mode Exit fullscreen mode

ECMAscript modules (ESM/modules)

export function foo() {}
Enter fullscreen mode Exit fullscreen mode

Use

// An https url can also be provided
import { foo } from "foo.mjs";
Enter fullscreen mode Exit fullscreen mode

For some advanced tricks, check out Data URLs.

Package.json changes and file extensions

When using require('foo'); we are depending on CommonJS, which is well-established in Node.js since v0.1.0. As of node v9.x, it has been possible to enable an experimental flag to begin using ESM. As of Node.js v12.x, ESM are natively supported. The overall migration path from CommonJS to ESM can take multiple forms. To provide compatibility and keep longterm changes to a minimum, the following behaviors exist:

  • .js file extension is assumed to implement CommonJS
  • .mjs file extension is assumed to implement ESM
  • .cjs file extension is assumed to implement CommonJS
  • package.js can include { "type": "module" } to indicate .js file extension will contain ESM. With this, there is no longer a need to use the .mjs extension
  • Node can be run with --experimental-specifier-resolution=node to tell node to support CommonJS and ESM BOTH in .js files

ESLint

If you embrace ESlint (and you should), know that definitions must be based on es2021 (es12) or newer. Previous ecmascript versions require other approaches (like --experimental node.js flags.)

Bonus

Starting from Node.js 14.13.0 and higher, it's possible to import CommonJS modules using the ES module syntax (import/export). In other words, you can use the import statement to import objects from a CommonJS module that exports using module.exports.

For example, if you have a CommonJS module foo.js that exports an object like this:

module.exports = { a: 1, b: 2, c: 3 }`;
Enter fullscreen mode Exit fullscreen mode

You can import this object using the ES module syntax like this:

import foo from './foo.js'; 
console.log(foo.a); 
// Output: 1
Enter fullscreen mode Exit fullscreen mode

Note that you need to use a file extension of .mjs for the importing file (see above) if you're using ECMAScript modules. However, if you prefer to use the .js file extension for both CommonJS and ECMAScript modules, you can add "type": "module" to your package.json file OR run Node.js with --experimental-specifier-resolution=node

Extra Thanks

The FAQ and other bits where borrowed from:
https://www.knowledgehut.com/blog/web-development/commonjs-vs-es-modules

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player