|
1 | 1 | import { FilterPattern } from '@rollup/pluginutils'; |
2 | 2 | import { Plugin } from 'rollup'; |
3 | 3 |
|
| 4 | +type RequireReturnsDefaultOption = boolean | 'auto' | 'preferred'; |
| 5 | + |
4 | 6 | interface RollupCommonJSOptions { |
5 | 7 | /** |
6 | | - * non-CommonJS modules will be ignored, but you can also |
7 | | - * specifically include/exclude files |
| 8 | + * A minimatch pattern, or array of patterns, which specifies the files in |
| 9 | + * the build the plugin should operate on. By default, all files with |
| 10 | + * extension `".cjs"` or those in `extensions` are included, but you can narrow |
| 11 | + * this list by only including specific files. These files will be analyzed |
| 12 | + * and transpiled if either the analysis does not find ES module specific |
| 13 | + * statements or `transformMixedEsModules` is `true`. |
8 | 14 | * @default undefined |
9 | 15 | */ |
10 | 16 | include?: FilterPattern; |
11 | 17 | /** |
12 | | - * non-CommonJS modules will be ignored, but you can also |
13 | | - * specifically include/exclude files |
| 18 | + * A minimatch pattern, or array of patterns, which specifies the files in |
| 19 | + * the build the plugin should _ignore_. By default, all files with |
| 20 | + * extensions other than those in `extensions` or `".cjs"` are ignored, but you |
| 21 | + * can exclude additional files. See also the `include` option. |
14 | 22 | * @default undefined |
15 | 23 | */ |
16 | 24 | exclude?: FilterPattern; |
17 | 25 | /** |
18 | | - * search for files other than .js files (must already |
19 | | - * be transpiled by a previous plugin!) |
| 26 | + * For extensionless imports, search for extensions other than .js in the |
| 27 | + * order specified. Note that you need to make sure that non-JavaScript files |
| 28 | + * are transpiled by another plugin first. |
20 | 29 | * @default [ '.js' ] |
21 | 30 | */ |
22 | | - extensions?: ReadonlyArray<string | RegExp>; |
| 31 | + extensions?: ReadonlyArray<string>; |
23 | 32 | /** |
24 | | - * if true then uses of `global` won't be dealt with by this plugin |
| 33 | + * If true then uses of `global` won't be dealt with by this plugin |
25 | 34 | * @default false |
26 | 35 | */ |
27 | 36 | ignoreGlobal?: boolean; |
28 | 37 | /** |
29 | | - * if false then skip sourceMap generation for CommonJS modules |
| 38 | + * If false, skips source map generation for CommonJS modules. This will improve performance. |
30 | 39 | * @default true |
31 | 40 | */ |
32 | 41 | sourceMap?: boolean; |
33 | 42 | /** |
34 | | - * Instructs the plugin whether or not to enable mixed module transformations. This is useful in scenarios with mixed ES and CommonJS modules. Set to `true` if it's known that `require` calls should be transformed, or `false` if the code contains env detection and the `require` should survive a transformation. |
| 43 | + * Instructs the plugin whether to enable mixed module transformations. This |
| 44 | + * is useful in scenarios with modules that contain a mix of ES `import` |
| 45 | + * statements and CommonJS `require` expressions. Set to `true` if `require` |
| 46 | + * calls should be transformed to imports in mixed modules, or `false` if the |
| 47 | + * `require` expressions should survive the transformation. The latter can be |
| 48 | + * important if the code contains environment detection, or you are coding |
| 49 | + * for an environment with special treatment for `require` calls such as |
| 50 | + * ElectronJS. See also the `ignore` option. |
35 | 51 | * @default false |
36 | 52 | */ |
37 | 53 | transformMixedEsModules?: boolean; |
38 | 54 | /** |
39 | | - * sometimes you have to leave require statements |
40 | | - * unconverted. Pass an array containing the IDs |
41 | | - * or a `id => boolean` function. Only use this |
42 | | - * option if you know what you're doing! |
| 55 | + * Sometimes you have to leave require statements unconverted. Pass an array |
| 56 | + * containing the IDs or a `id => boolean` function. |
| 57 | + * @default [] |
| 58 | + */ |
| 59 | + ignore?: ReadonlyArray<string> | ((id: string) => boolean); |
| 60 | + /** |
| 61 | + * Controls how to render imports from external dependencies. By default, |
| 62 | + * this plugin assumes that all external dependencies are CommonJS. This |
| 63 | + * means they are rendered as default imports to be compatible with e.g. |
| 64 | + * NodeJS where ES modules can only import a default export from a CommonJS |
| 65 | + * dependency. |
| 66 | + * |
| 67 | + * If you set `esmExternals` to `true`, this plugins assumes that all |
| 68 | + * external dependencies are ES modules and respect the |
| 69 | + * `requireReturnsDefault` option. If that option is not set, they will be |
| 70 | + * rendered as namespace imports. |
| 71 | + * |
| 72 | + * You can also supply an array of ids to be treated as ES modules, or a |
| 73 | + * function that will be passed each external id to determine if it is an ES |
| 74 | + * module. |
| 75 | + * @default false |
| 76 | + */ |
| 77 | + esmExternals?: boolean | ReadonlyArray<string> | ((id: string) => boolean); |
| 78 | + /** |
| 79 | + * Controls what is returned when requiring an ES module from a CommonJS file. |
| 80 | + * When using the `esmExternals` option, this will also apply to external |
| 81 | + * modules. By default, this plugin will render those imports as namespace |
| 82 | + * imports. However there are some situations where this may not be desired. |
| 83 | + * For these situations, you can change Rollup's behaviour either globally or |
| 84 | + * per module. To change it globally, set the `requireReturnsDefault` option |
| 85 | + * to one of the following values: |
| 86 | + * |
| 87 | + * - `false`: This is the default, requiring an ES module returns its |
| 88 | + * namespace. For external dependencies when using `esmExternals: true`, no |
| 89 | + * additional interop code is generated. |
| 90 | + * - `"auto"`: This is complementary to how `output.exports: "auto"` works in |
| 91 | + * Rollup: If a module has a default export and no named exports, requiring |
| 92 | + * that module returns the default export. In all other cases, the namespace |
| 93 | + * is returned. For external dependencies when using `esmExternals: true`, a |
| 94 | + * corresponding interop helper is added. |
| 95 | + * - `"preferred"`: If a module has a default export, requiring that module |
| 96 | + * always returns the default export, no matter whether additional named |
| 97 | + * exports exist. This is similar to how previous versions of this plugin |
| 98 | + * worked. Again for external dependencies when using `esmExternals: true`, an |
| 99 | + * interop helper is added. |
| 100 | + * - `true`: This will always try to return the default export on require |
| 101 | + * without checking if it actually exists. This can throw at build time if |
| 102 | + * there is no default export. This is how external dependencies are handled |
| 103 | + * when `esmExternals` is not used. The advantage over the other options is |
| 104 | + * that, like `false`, this does not add an interop helper for external |
| 105 | + * dependencies, keeping the code lean. |
| 106 | + * |
| 107 | + * To change this for individual modules, you can supply a function for |
| 108 | + * `requireReturnsDefault` instead. This function will then be called once for |
| 109 | + * each required ES module or external dependency with the corresponding id |
| 110 | + * and allows you to return different values for different modules. |
| 111 | + * @default false |
43 | 112 | */ |
44 | | - ignore?: ReadonlyArray<string | ((id: string) => boolean)>; |
| 113 | + requireReturnsDefault?: |
| 114 | + | RequireReturnsDefaultOption |
| 115 | + | ((id: string) => RequireReturnsDefaultOption); |
45 | 116 | /** |
46 | | - * Some modules contain dynamic `require` calls, or require modules that contain |
47 | | - * circular dependencies, which are not handled well by static imports. |
48 | | - * Including those modules as `dynamicRequireTargets` will simulate a CommonJS (NodeJS-like) |
49 | | - * environment for them with support for dynamic and circular dependencies. |
| 117 | + * Some modules contain dynamic `require` calls, or require modules that |
| 118 | + * contain circular dependencies, which are not handled well by static |
| 119 | + * imports. Including those modules as `dynamicRequireTargets` will simulate a |
| 120 | + * CommonJS (NodeJS-like) environment for them with support for dynamic and |
| 121 | + * circular dependencies. |
50 | 122 | * |
51 | | - * Note: In extreme cases, this feature may result in some paths being rendered as |
52 | | - * absolute in the final bundle. The plugin tries to avoid exposing paths from |
53 | | - * the local machine, but if you are `dynamicRequirePaths` with paths that are |
54 | | - * far away from your project's folder, that may require replacing strings |
55 | | - * like `"/Users/John/Desktop/foo-project/"` -> `"/"`. |
| 123 | + * Note: In extreme cases, this feature may result in some paths being |
| 124 | + * rendered as absolute in the final bundle. The plugin tries to avoid |
| 125 | + * exposing paths from the local machine, but if you are `dynamicRequirePaths` |
| 126 | + * with paths that are far away from your project's folder, that may require |
| 127 | + * replacing strings like `"/Users/John/Desktop/foo-project/"` -> `"/"`. |
56 | 128 | */ |
57 | 129 | dynamicRequireTargets?: string | ReadonlyArray<string>; |
58 | 130 | } |
|
0 commit comments