-
-
Notifications
You must be signed in to change notification settings - Fork 574
/
index.d.ts
233 lines (229 loc) · 10.8 KB
/
index.d.ts
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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
import type { FilterPattern } from '@rollup/pluginutils';
import type { Plugin } from 'rollup';
type RequireReturnsDefaultOption = boolean | 'auto' | 'preferred' | 'namespace';
type DefaultIsModuleExportsOption = boolean | 'auto';
interface RollupCommonJSOptions {
/**
* A picomatch pattern, or array of patterns, which specifies the files in
* the build the plugin should operate on. By default, all files with
* extension `".cjs"` or those in `extensions` are included, but you can
* narrow this list by only including specific files. These files will be
* analyzed and transpiled if either the analysis does not find ES module
* specific statements or `transformMixedEsModules` is `true`.
* @default undefined
*/
include?: FilterPattern;
/**
* A picomatch pattern, or array of patterns, which specifies the files in
* the build the plugin should _ignore_. By default, all files with
* extensions other than those in `extensions` or `".cjs"` are ignored, but you
* can exclude additional files. See also the `include` option.
* @default undefined
*/
exclude?: FilterPattern;
/**
* For extensionless imports, search for extensions other than .js in the
* order specified. Note that you need to make sure that non-JavaScript files
* are transpiled by another plugin first.
* @default [ '.js' ]
*/
extensions?: ReadonlyArray<string>;
/**
* If true then uses of `global` won't be dealt with by this plugin
* @default false
*/
ignoreGlobal?: boolean;
/**
* If false, skips source map generation for CommonJS modules. This will
* improve performance.
* @default true
*/
sourceMap?: boolean;
/**
* Some `require` calls cannot be resolved statically to be translated to
* imports.
* When this option is set to `false`, the generated code will either
* directly throw an error when such a call is encountered or, when
* `dynamicRequireTargets` is used, when such a call cannot be resolved with a
* configured dynamic require target.
* Setting this option to `true` will instead leave the `require` call in the
* code or use it as a fallback for `dynamicRequireTargets`.
* @default false
*/
ignoreDynamicRequires?: boolean;
/**
* Instructs the plugin whether to enable mixed module transformations. This
* is useful in scenarios with modules that contain a mix of ES `import`
* statements and CommonJS `require` expressions. Set to `true` if `require`
* calls should be transformed to imports in mixed modules, or `false` if the
* `require` expressions should survive the transformation. The latter can be
* important if the code contains environment detection, or you are coding
* for an environment with special treatment for `require` calls such as
* ElectronJS. See also the `ignore` option.
* @default false
*/
transformMixedEsModules?: boolean;
/**
* By default, this plugin will try to hoist `require` statements as imports
* to the top of each file. While this works well for many code bases and
* allows for very efficient ESM output, it does not perfectly capture
* CommonJS semantics as the order of side effects like log statements may
* change. But it is especially problematic when there are circular `require`
* calls between CommonJS modules as those often rely on the lazy execution of
* nested `require` calls.
*
* Setting this option to `true` will wrap all CommonJS files in functions
* which are executed when they are required for the first time, preserving
* NodeJS semantics. Note that this can have an impact on the size and
* performance of the generated code.
*
* The default value of `"auto"` will only wrap CommonJS files when they are
* part of a CommonJS dependency cycle, e.g. an index file that is required by
* many of its dependencies. All other CommonJS files are hoisted. This is the
* recommended setting for most code bases.
*
* `false` will entirely prevent wrapping and hoist all files. This may still
* work depending on the nature of cyclic dependencies but will often cause
* problems.
*
* You can also provide a picomatch pattern, or array of patterns, to only
* specify a subset of files which should be wrapped in functions for proper
* `require` semantics.
*
* `"debug"` works like `"auto"` but after bundling, it will display a warning
* containing a list of ids that have been wrapped which can be used as
* picomatch pattern for fine-tuning.
* @default "auto"
*/
strictRequires?: boolean | FilterPattern;
/**
* Sometimes you have to leave require statements unconverted. Pass an array
* containing the IDs or a `id => boolean` function.
* @default []
*/
ignore?: ReadonlyArray<string> | ((id: string) => boolean);
/**
* In most cases, where `require` calls are inside a `try-catch` clause,
* they should be left unconverted as it requires an optional dependency
* that may or may not be installed beside the rolled up package.
* Due to the conversion of `require` to a static `import` - the call is
* hoisted to the top of the file, outside of the `try-catch` clause.
*
* - `true`: All `require` calls inside a `try` will be left unconverted.
* - `false`: All `require` calls inside a `try` will be converted as if the
* `try-catch` clause is not there.
* - `remove`: Remove all `require` calls from inside any `try` block.
* - `string[]`: Pass an array containing the IDs to left unconverted.
* - `((id: string) => boolean|'remove')`: Pass a function that control
* individual IDs.
*
* @default false
*/
ignoreTryCatch?:
| boolean
| 'remove'
| ReadonlyArray<string>
| ((id: string) => boolean | 'remove');
/**
* Controls how to render imports from external dependencies. By default,
* this plugin assumes that all external dependencies are CommonJS. This
* means they are rendered as default imports to be compatible with e.g.
* NodeJS where ES modules can only import a default export from a CommonJS
* dependency.
*
* If you set `esmExternals` to `true`, this plugins assumes that all
* external dependencies are ES modules and respect the
* `requireReturnsDefault` option. If that option is not set, they will be
* rendered as namespace imports.
*
* You can also supply an array of ids to be treated as ES modules, or a
* function that will be passed each external id to determine if it is an ES
* module.
* @default false
*/
esmExternals?: boolean | ReadonlyArray<string> | ((id: string) => boolean);
/**
* Controls what is returned when requiring an ES module from a CommonJS file.
* When using the `esmExternals` option, this will also apply to external
* modules. By default, this plugin will render those imports as namespace
* imports i.e.
*
* ```js
* // input
* const foo = require('foo');
*
* // output
* import * as foo from 'foo';
* ```
*
* However there are some situations where this may not be desired.
* For these situations, you can change Rollup's behaviour either globally or
* per module. To change it globally, set the `requireReturnsDefault` option
* to one of the following values:
*
* - `false`: This is the default, requiring an ES module returns its
* namespace. This is the only option that will also add a marker
* `__esModule: true` to the namespace to support interop patterns in
* CommonJS modules that are transpiled ES modules.
* - `"namespace"`: Like `false`, requiring an ES module returns its
* namespace, but the plugin does not add the `__esModule` marker and thus
* creates more efficient code. For external dependencies when using
* `esmExternals: true`, no additional interop code is generated.
* - `"auto"`: This is complementary to how `output.exports: "auto"` works in
* Rollup: If a module has a default export and no named exports, requiring
* that module returns the default export. In all other cases, the namespace
* is returned. For external dependencies when using `esmExternals: true`, a
* corresponding interop helper is added.
* - `"preferred"`: If a module has a default export, requiring that module
* always returns the default export, no matter whether additional named
* exports exist. This is similar to how previous versions of this plugin
* worked. Again for external dependencies when using `esmExternals: true`,
* an interop helper is added.
* - `true`: This will always try to return the default export on require
* without checking if it actually exists. This can throw at build time if
* there is no default export. This is how external dependencies are handled
* when `esmExternals` is not used. The advantage over the other options is
* that, like `false`, this does not add an interop helper for external
* dependencies, keeping the code lean.
*
* To change this for individual modules, you can supply a function for
* `requireReturnsDefault` instead. This function will then be called once for
* each required ES module or external dependency with the corresponding id
* and allows you to return different values for different modules.
* @default false
*/
requireReturnsDefault?:
| RequireReturnsDefaultOption
| ((id: string) => RequireReturnsDefaultOption);
/**
* @default "auto"
*/
defaultIsModuleExports?:
| DefaultIsModuleExportsOption
| ((id: string) => DefaultIsModuleExportsOption);
/**
* Some modules contain dynamic `require` calls, or require modules that
* contain circular dependencies, which are not handled well by static
* imports. Including those modules as `dynamicRequireTargets` will simulate a
* CommonJS (NodeJS-like) environment for them with support for dynamic
* dependencies. It also enables `strictRequires` for those modules.
*
* Note: In extreme cases, this feature may result in some paths being
* rendered as absolute in the final bundle. The plugin tries to avoid
* exposing paths from the local machine, but if you are `dynamicRequirePaths`
* with paths that are far away from your project's folder, that may require
* replacing strings like `"/Users/John/Desktop/foo-project/"` -> `"/"`.
*/
dynamicRequireTargets?: string | ReadonlyArray<string>;
/**
* To avoid long paths when using the `dynamicRequireTargets` option, you can use this option to specify a directory
* that is a common parent for all files that use dynamic require statements. Using a directory higher up such as `/`
* may lead to unnecessarily long paths in the generated code and may expose directory names on your machine like your
* home directory name. By default it uses the current working directory.
*/
dynamicRequireRoot?: string;
}
/**
* Convert CommonJS modules to ES6, so they can be included in a Rollup bundle
*/
export default function commonjs(options?: RollupCommonJSOptions): Plugin;