Announcing a new --experimental-modules

Photo by Brett Sayles from Pexels

What’s in --experimental-modules

  • ES2015 import statements can reference JavaScript files that are themselves written using ES module syntax. Files can be referenced as relative URLs (‘./file.mjs’), absolute file:// URLs (‘file:///opt/app/file.mjs’), package names (‘es-module-package’) or paths within packages (‘es-module-package/lib/file.mjs’).
  • import statements that reference ES module files can specify both the default export (import _ from ‘es-module-package’), named exports (import { shuffle } from ‘es-module-package’) and namespace exports (import * as fs from ‘fs’). All Node.js built-in packages like fs and path support all three types of exports.
  • import statements that reference CommonJS files (all current JavaScript code written for Node.js, using require and module.exports) can use the CommonJS default export (import _ from ‘commonjs-package’) only. This is a work in progress and may change in the future.
  • export statements in ES module files can specify both default and named exports for import statements to reference.
  • Dynamic import() expressions can be used to import ES modules from either CommonJS or ES module files. Note that import() returns a promise.
  • import.meta.url provides the absolute URL of the current ES module file.
  • Loaders can be written to modify Node.js’s runtime behavior with respect to ES modules. This is still very much a work in progress.
  • Node.js can be run with an ES module file as a program’s initial entry point.
  • Files loaded as ES modules are loaded in strict mode, which in CommonJS requires adding ‘use strict’; to the top of every file.
  • Files ending in .mjs are explicitly treated as ES modules in import statements and when run via the node command.

import and export syntax in .js files

package.json “type” field

--input-type flag

.cjs extension

Explicit filenames


import for JavaScript only

ES module code in packages

Works in progress

  • Loaders features. Loaders are being further developed to support process isolation, multiple loaders, and multi-Realm support with lower-level hooks. The --loader API will still change considerably before this is unflagged.
  • Dual CommonJS/ES module packages. We want to provide a standard way for package authors to publish a package that can be both required into CommonJS or imported into an ES module.
  • Easier require. Using Module.createRequireFromPath() involves a lot of boilerplate. We hope to provide a simpler way to use require in ES module code.
  • Package path maps. We would like to support paths to files within packages. This would allow things like import sdk from ‘some-service/sdk’ to have ‘some-service/sdk’ map to something like ./src/sdk/public-api.mjs.
  • Automatic entry point module type detection. This would provide a way for running JavaScript code as either CommonJS or ES modules based on static analysis.




Node.js is a collaborative open source project dedicated to building and supporting the Node.js platform.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The confusing let, var, and const of javascript

An Easy and Fun Guide to Redux — Intro and Immutability

The Life Cycle of React..

How to download your Robinhood transaction history

Is Vanilla.js a Good Choice?

Using JAVASCRIPT (this) Keyword in a Function

Package Manager Battle

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Node.js is a collaborative open source project dedicated to building and supporting the Node.js platform.

More from Medium

Mastering React — Diving deep into React concepts — ContextAPI

React Security Vulnerabilities: How to Protect Your App and Fix Them

NEW useEvent hook may come in React 18.

React — A Front-end Development Open Source JavaScript Library.