@babel/plugin-transform-modules-commonjs
This plugin transforms ECMAScript modules to CommonJS. Note that only the syntax of import/export statements (import "./mod.js"
) and import expressions (import('./mod.js')
) is transformed, as Babel is unaware of different resolution algorithms between implementations of ECMAScript modules and CommonJS.
Example
In
export default 42;
Out
Object.defineProperty(exports, "__esModule", {
value: true
});
exports.default = 42;
Installation
npm install --save-dev @babel/plugin-transform-modules-commonjs
Usage
With a configuration file (Recommended)
// without options
{
"plugins": ["@babel/plugin-transform-modules-commonjs"]
}
// with options
{
"plugins": [
["@babel/plugin-transform-modules-commonjs", {
"allowTopLevelThis": true
}]
]
}
Via CLI
babel --plugins @babel/plugin-transform-modules-commonjs script.js
Via Node API
require("@babel/core").transform("code", {
plugins: ["@babel/plugin-transform-modules-commonjs"]
});
Options
loose
boolean
, defaults to false
.
By default, when using exports with babel a non-enumerable __esModule
property is exported.
var foo = exports.foo = 5;
Object.defineProperty(exports, "__esModule", {
value: true
});
In environments that don't support this you can enable loose mode on @babel/plugin-transform-modules-commonjs
and instead of using Object.defineProperty
an assignment will be used instead.
var foo = exports.foo = 5;
exports.__esModule = true;
strict
boolean
, defaults to false
By default, when using exports with babel a non-enumerable __esModule
property is exported. In some cases this property is used to determine if the import is the default export or if it contains the default export.
var foo = exports.foo = 5;
Object.defineProperty(exports, "__esModule", {
value: true
});
In order to prevent the __esModule
property from being exported, you can set the strict
option to true
.
noInterop
boolean
, defaults to false
By default, when using exports with babel a non-enumerable __esModule
property is exported. This property is then used to determine if the import is the default export or if it contains the default export.
"use strict";
var _foo = _interopRequireDefault(require("foo"));
function _interopRequireDefault(obj) {
return obj && obj.__esModule ? obj : { default: obj };
}
In cases where the auto-unwrapping of default
is not needed, you can set the noInterop
option to true
to avoid the usage of the interopRequireDefault
helper (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 their imported bindings are used for the first time.
This can improve initial load time of your module because evaluating dependencies up front is sometimes entirely un-necessary. This is especially the 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-initfoo
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 means that there is no binding to later kick off initialization.
-
export * from "foo"
Re-exporting all names requires up-front execution because otherwise there is no way to know what names need to be exported.
You can read more about configuring plugin options here