1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
# @babel/plugin-transform-modules-commonjs
> This plugin transforms ES2015 modules to [CommonJS](http://wiki.commonjs.org/wiki/Modules/1.1).
## Example
**In**
```javascript
export default 42;
```
**Out**
```javascript
Object.defineProperty(exports, "__esModule", {
value: true
});
exports.default = 42;
```
## Installation
```sh
npm install --save-dev @babel/plugin-transform-modules-commonjs
```
## Usage
### Via `.babelrc` (Recommended)
**.babelrc**
```js
// without options
{
"plugins": ["@babel/plugin-transform-modules-commonjs"]
}
// with options
{
"plugins": [
["@babel/plugin-transform-modules-commonjs", {
"allowTopLevelThis": true
}]
]
}
```
### Via CLI
```sh
babel --plugins @babel/plugin-transform-modules-commonjs script.js
```
### Via Node API
```javascript
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.
```javascript
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.
```javascript
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.
```javascript
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.
```javascript
"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-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 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.
|
