On November 21, 2019.11.21, Node.js released version 13.2.0 with some new features. One of the most exciting is the official cancellation of the experimental-modules startup parameter. This shows that Node.js officially supports ES Modules. Let’s take a look.

Stability Index shows that

“Stability Index” is a description of Api Stability Index. It contains three values:

  1. Stability: 0, not recommended. Indicates that the Api is not recommended and may issue a warning. Backward compatibility is not guaranteed.
  2. Stability: 1, experimental. Indicates that the Api already supports usability use. However, non-backward compatible changes or deletions may occur in any future release. It is not recommended to use this feature in production environments.
  • Stability: 2. Indicates that the test has been completed, basically will not change, can be used in the production environment.

Unflag –experimental-modules

As of version 13.2.0, Node has experimental support for ECMAScript modules enabled by default, meaning that startup parameters are not required. So how does NodeJS differentiate ESM from CommonJS? Here is a translation of the official document.

Node.js will treat the following as an ES module:

  • The file suffix is.mjs
  • When the file suffix is.js, or if there is no file suffix, look at the package.json file,The type field value in package.json is "module".
  • Add boot parameter — input-type=module
  • Use the pass character argument to--eval, such as$ node --eval 'import("http");

In other cases, it will be identified as CommonJS. Now that Node supports ESM and CommonJS, it is best to specify modules when using them.

For example, 🌰

import './legacy-file.cjs';
// Loaded as CommonJS since .cjs is always loaded as CommonJS.

import 'commonjs-package/src/index.mjs';
// Loaded as ES module since .mjs is always loaded as ES module.
Copy the code

In this case, different modules are handled according to the file suffix.

// package.json
{
  "type": "module"
}
Copy the code

Json in the current directory or in a parent directory that contains “type”: “module” is treated as ES Module.

// my-app.js, in an ES module package scope because there is a package.json
// file in the same folder with "type": "module".

import './startup/init.js';
// Loaded as ES module since ./startup contains no package.json file,
// and therefore inherits the ES module package scope from one level up.

import 'commonjs-package';
// Loaded as CommonJS since ./node_modules/commonjs-package/package.json
// lacks a "type" field or contains "type": "commonjs".

import './node_modules/commonjs-package/index.js';
// Loaded as CommonJS since ./node_modules/commonjs-package/package.json
// lacks a "type" field or contains "type": "commonjs".
Copy the code

As the comment above shows, if the current file directory does not contain package.json, the package.json file in its parent directory is looked at and the type of type is determined.

node --input-type=module --eval "import { sep } from 'path'; console.log(sep);"
echo "import { sep } from 'path'; console.log(sep);" | node --input-type=module
Copy the code

This is the case with passing character arguments to –eval and adding –input-type startup arguments.

Rapid experience

The official documentation for the current 13.2.0 ES Module is labeled Stability: 1, and you can install the new version to try it out. With the concerted efforts of the community, Stability: 2 will soon be released.

Local development often requires quick updates or switching between node versions. You can use NVM, N, etc. Another cross-platform local management solution is NVS. Here is an example of using NVS:

$ nvs add node/13.2. 0
$ nvs use 13.2. 0
$ node -v
13.2. 0
Copy the code

Give it a try

The last

  • Welcome to add my wechat (Winty230), pull you into the technology group, long-term exchange learning…
  • Welcome to pay attention to “front-end Q”, seriously learn front-end, do a professional technical people…