DEV Community: Michael Richardson

From CommonJS/Require to ES modules the easy way

Michael Richardson — Thu, 09 Mar 2023 15:23:39 +0000

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;

Use

foo = require('foo');`

ECMAscript modules (ESM/modules)

export function foo() {}

Use

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

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 }`;

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

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

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

Reasons NOT to use ESlint sarcasm

Michael Richardson — Thu, 02 Feb 2023 18:45:00 +0000

Why would anyone NOT want to use ESLint, you ask? Well, let me tell you.

If you're looking to add chaos and confusion to your coding workflow, look no further than ESLint. This tool is designed to ensure that your code meets a certain set of standards and is free of any potential errors. But why would anyone want to use such a bothersome program? Here are just a few of the many reasons why you should avoid ESLint at all costs. Who needs organized and consistent code anyway? Who needs to save time by automatically catching syntax and formatting errors before they even reach the browser? And let's not forget about the joy of scrolling through hundreds of lines of messy, unreadable code. Who needs to be productive and efficient, right?

First of all, who has time to waste on pesky linting errors? It's much more fun to spend your valuable coding time debugging runtime issues. Not to mention, the rules that ESLint forces you to abide by are often arbitrary and outdated. Who wants to spend their days writing code that conforms to the stylistic preferences of others? Furthermore, the amount of time it takes to even set up ESLint can be a bit overwhelming. It might seem like a small task, but it can quickly become tedious and time-consuming.

Second, ESLint can be incredibly tedious to work with. It often requires you to spend hours hunting down small typos and other minor errors that could be easily overlooked. Not to mention, the linting rules can be difficult to decipher and often require you to make numerous adjustments to your code in order to comply. This can be incredibly time-consuming and ultimately leave you with code that doesn’t even meet the standards that ESLint was meant to enforce. Clearly, using ESLint is for the weak-hearted. It's for those who value productivity, consistency, and a well-organized codebase. But if you're like me, you'd much rather spend hours trying to decipher and fix code that could have been caught by a simple linter. So go ahead, do yourself a favor, and steer clear of the temptations of ESLint. Your code will thank you for it.

The final nail in the coffin is the fact that ESLint often introduces unexpected bugs into your code. Since the program is designed to catch coding errors, it can be difficult to figure out why an error is occurring, especially if you’re unfamiliar with the program. Furthermore, you can’t even trust ESLint to catch all of the errors in your code. This means that you may find yourself spending even more time troubleshooting and hunting down errors that the program missed. So, why bother using it in the first place? Furthermore, who needs the peace of mind that comes with knowing your code adheres to a standardized style guide, or the ability to easily catch potential bugs and security vulnerabilities before they become a problem? Who wants to work in a team where everyone follows the same code conventions, making collaboration smoother and conflicts less frequent?

In conclusion, ESLint is clearly not worth the headache. If you value your short-term sanity, you should avoid it. In the unlikely chance you like to sleep soundly, knowing your code is as solid as possible, you could look into it.

What's new with JavaScript in 2020 - Ecmascript 2020/ES11

Michael Richardson — Fri, 21 Oct 2022 04:00:00 +0000

Background

Before ecmaScript came Javascript. The creator Brendan Eich set out to create a language like, but simpler than Java. Javascript was originally created for Netscape and before it went down, a project was started to formalize the language and that became ecmascript. What we know today as Javascript, is really vendor-specific implementations of ecmascript.

Ecmascript didn't really gain traction until version 6 and it has continued to evolve since. Support for a given version is entirely dependent on the environment such as node vs browser, which browser, which version of that browser and such. Right now es version 13 also known as es2022 is stable, BUT support for it in Node isn't stable until version 17.9.1 (97% coverage). Since we are still on NodeJS 14, ecmaScript support is limited currently to es11 or es2020. When we make the move to Node 18.x, then we will have support for es version 13 aka es2022.

Hopefully you have some idea of the versions and timelines now, but why does it matter? Because each new ecmaScript version defines new features. As vendors improve support for that new version, they are exposed to developers in their products (like browsers and NodeJS). I show you all these now to give you an idea how many new features have released since es8/2017. I can't cover even a majority of them, but today I'm going to briefly highly some that may prove helpful in providing more stable code, code that's easier to read (and write tests for nod) or help you avoid anti-patterns or just write simpler code.

Nullish coalescing

A bit like using OR to return the first/left-most non-null, non-empty value; nullish coalescing returns the first/left-most non-null value, even if it's empty.

const response = {
    settings: {
        nullValue: null , height: 400, animationDuration: 0, headerText: '', showSplashScreen: false
    },
};
const undefinedValue = response.settings.undefinedValue ?? 'some other default' ; // result: 'some other default'
const nullValue = response.settings.nullValue ?? 'some other default' ; // result: 'some other default'
const headerText = response.settings.headerText ?? 'Hello, world!' ; // result: ''
const animationDuration = response.settings.animationDuration ?? 300; // result: 0
const showSplashScreen = response.settings.showSplashScreen ?? true ; // result: false
const x = '' || 'x'; // result: 'x'
const x = '' ?? 'x'; // result: ''

Optional Chaining

When looking for a property value that's deep in a tree-like structure, one often has to check whether intermediate nodes exist before you can check for the deeper value. Optional chaining simplifies this by using a question-mark before the dot-notation.

const user = {};

// Before:
var street = user.address.street; // Error: cannot read properties of undefined  var street = user.address && user.address.street; // undefined
// Now:
var street = user?.address?.street; // undefined

Logical assignment operator

This is a convenience operators, inspired by Ruby's. Javascript already has a dozen mathematical assignment operators, but we didn't have ones for the often used logical operators.

// Ok, but could trigger setter.
opts.foo = opts.foo ?? 'bar'
// No setter, but 'feels wrong' to write.
opts.baz ?? (opts.baz = 'qux');
// Setters are not needlessly called.
opts.foo ??= 'bar'
// No repetition of `opts.baz`.
opts.baz ??= 'qux';
// This always logs "setter called"
obj.x += 1;
assert.equal(obj.x, 1);
// Logical operators do not call setters unnecessarily
// This will not log.
obj.x ||= 2;
assert.equal(obj.x, 1);
// But setters are called if the operator does not short circuit
// "setter called"
obj.x &&= 3;
assert.equal(obj.x, 3)

Object rest/spread

ECMAScript 6 introduces rest elements for ARRAY destructuring assignment and spread elements for ARRAY literals. With es11, we get rest properties for OBJECT destructuring assignment and spread properties for OBJECT literals.

let { x, y, ...z } = { x: 1, y: 2,  a: 3, b: 4  };
x; // 1
y; // 2
z; // { a: 3, b: 4 }
let n = { x, y, ...z };
n; // { x: 1, y: 2,  a: 3, b: 4  }

Conclusion

ECMAScript is constantly evolving and the more current your environment (latest Node.js, browser, or other client), the more features you'll have access to. Be sure to keep an eye on which version of eslint you want to target by watching resources like https://node.green/ and https://caniuse.com/?search=es11.