@babel/plugin-transform-modules-commonjs

This plugin transforms ES2015 modules to CommonJS.

Example

In

  1. export default 42;

Out

  1. Object.defineProperty(exports, "__esModule", {
  2. value: true
  3. });
  4. exports.default = 42;

Installation

  1. npm install --save-dev @babel/plugin-transform-modules-commonjs

Usage

.babelrc

  1. // without options
  2. {
  3. "plugins": ["@babel/plugin-transform-modules-commonjs"]
  4. }
  5. // with options
  6. {
  7. "plugins": [
  8. ["@babel/plugin-transform-modules-commonjs", {
  9. "allowTopLevelThis": true
  10. }]
  11. ]
  12. }

Via CLI

  1. babel --plugins @babel/plugin-transform-modules-commonjs script.js

Via Node API

  1. require("@babel/core").transform("code", {
  2. plugins: ["@babel/plugin-transform-modules-commonjs"]
  3. });

Options

loose

boolean, defaults to false.

By default, when using exports with babel a non-enumerable __esModule propertyis exported.

  1. var foo = exports.foo = 5;
  2. Object.defineProperty(exports, "__esModule", {
  3. value: true
  4. });

In environments that don't support this you can enable loose mode on @babel/plugin-transform-modules-commonjsand instead of using Object.defineProperty an assignment will be used instead.

  1. var foo = exports.foo = 5;
  2. exports.__esModule = true;

strict

boolean, defaults to false

By default, when using exports with babel a non-enumerable _esModule propertyis exported. In some cases this property is used to determine if the import _is thedefault export or if it contains the default export.

  1. var foo = exports.foo = 5;
  2. Object.defineProperty(exports, "__esModule", {
  3. value: true
  4. });

In order to prevent the __esModule property from being exported, you can setthe strict option to true.

noInterop

boolean, defaults to false

By default, when using exports with babel a non-enumerable _esModule propertyis exported. This property is then used to determine if the import _is the defaultexport or if it contains the default export.

  1. "use strict";
  2. var _foo = _interopRequireDefault(require("foo"));
  3. function _interopRequireDefault(obj) {
  4. return obj && obj.__esModule ? obj : { default: obj };
  5. }

In cases where the auto-unwrapping of default is not needed, you can set thenoInterop option to true to avoid the usage of the interopRequireDefaulthelper (shown in inline form above).

lazy

boolean, Array<string>, or (string) => boolean, defaults to false

Changes Babel's compiled import statements to be lazily evaluated when theirimported bindings are used for the first time.

This can improve initial load time of your module because evaluatingdependencies up front is sometimes entirely un-necessary. This is especiallythe case when implementing a library module.

The value of lazy has a few possible effects:

  • false - No lazy initialization of any imported module.

  • true - Do not lazy-initialize local ./foo imports, but lazy-init foo dependencies.

Local paths are much more likely to have circular dependencies, which may break if loaded lazily,so they are not lazy by default, whereas dependencies between independent modules are rarely cyclical.

  • Array<string> - Lazy-initialize all imports with source matching one of the given strings.

  • (string) => boolean - Pass a callback that will be called to decide if a given source string should be lazy-loaded.

The two cases where imports can never be lazy are:

  • import "foo";

Side-effect imports are automatically non-lazy since their very existence meansthat there is no binding to later kick off initialization.

  • export * from "foo"

Re-exporting all names requires up-front execution because otherwise there is noway to know what names need to be exported.

You can read more about configuring plugin options here