You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(commonjs)!: default strictRequires to true (#1639)
* feat(commonjs)!: default strictRequires to true
* test: update fixtures
* test: update different values
* test: update some tests to use auto
* test: adapt assertion
While the error message has a different variable name, the point of
the test is that we get an error.
* test: correctly pass options in test
Unfortunately, I did not find a way to detect this case from the plugin
and show a warning.
* fix(commonjs): respect defaultIsModuleExports:false for ES imports from wrapped CommonJS
* test: adapt assertions for wrapped CommonJS
* docs: improve readme to explain about CommonJS entry points
* test: allow tests to specify an entry point for running the code
* test: refine late-entry tests
* fix(commonjs): treat moduleSideEffects as __PURE__ comments for wrapped modules
* fix(commonjs): treat moduleSideEffects as __PURE__ comments for proxied wrapped modules
---------
Co-authored-by: Lukas Taegert-Atkinson <[email protected]>
Copy file name to clipboardExpand all lines: packages/commonjs/README.md
+28-4
Original file line number
Diff line number
Diff line change
@@ -49,13 +49,13 @@ When used together with the node-resolve plugin
49
49
### `strictRequires`
50
50
51
51
Type: `"auto" | boolean | "debug" | string[]`<br>
52
-
Default: `"auto"`
52
+
Default: `true`
53
53
54
-
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 initialisation order of required modules will be different. The resultant side effects can include log statements being emitted in a different order, and some code that is dependent on the initialisation order of polyfills in require statements may not work. 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.
54
+
Historically, this plugin tried 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 initialisation order of required modules will be different. The resultant side effects can include log statements being emitted in a different order, and some code that is dependent on the initialisation order of polyfills in require statements may not work. 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.
55
55
56
-
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. This is the safest setting and should be used if the generated code does not work correctly with `"auto"`. Note that `strictRequires: true` can have a small impact on the size and performance of generated code, but less so if the code is minified.
56
+
The default value of`true` will wrap all CommonJS files in functions which are executed when they are required for the first time, preserving NodeJS semantics. This is the safest setting and should be used if the generated code does not work correctly with `"auto"`. Note that `strictRequires: true` can have a small impact on the size and performance of generated code, but less so if the code is minified.
57
57
58
-
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 some of its dependencies, or if they are only required in a potentially "conditional" way like from within an if-statement or a function. All other CommonJS files are hoisted. This is the recommended setting for most code bases. Note that the detection of conditional requires can be subject to race conditions if there are both conditional and unconditional requires of the same file, which in edge cases may result in inconsistencies between builds. If you think this is a problem for you, you can avoid this by using any value other than `"auto"` or `"debug"`.
58
+
Setting this option to`"auto"` will only wrap CommonJS files when they are part of a CommonJS dependency cycle, e.g. an index file that is required by some of its dependencies, or if they are only required in a potentially "conditional" way like from within an if-statement or a function. All other CommonJS files are hoisted. This is the recommended setting for most code bases. Note that the detection of conditional requires can be subject to race conditions if there are both conditional and unconditional requires of the same file, which in edge cases may result in inconsistencies between builds. If you think this is a problem for you, you can avoid this by using any value other than `"auto"` or `"debug"`.
59
59
60
60
`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.
61
61
@@ -386,6 +386,30 @@ For these situations, you can change Rollup's behaviour either globally or per m
386
386
387
387
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.
388
388
389
+
## Using CommonJS files as entry points
390
+
391
+
With this plugin, you can also use CommonJS files as entry points. This means, however, that when you are bundling to an ES module, your bundle will only have a default export. If you want named exports instead, you should use an ES module entry point instead that reexports from your CommonJS entry point, e.g.
392
+
393
+
```js
394
+
// main.cjs, the CommonJS entry
395
+
exports.foo='foo';
396
+
exports.bar='bar';
397
+
398
+
// main.mjs, the ES module entry
399
+
export { foo, bar } from'./main.cjs';
400
+
401
+
// rollup.config.mjs
402
+
exportdefault {
403
+
input:'main.mjs',
404
+
output: {
405
+
format:'es',
406
+
file:'bundle.mjs'
407
+
}
408
+
};
409
+
```
410
+
411
+
When bundling to CommonJS, i.e `output.format === 'cjs'`, make sure that you do not set `output.exports` to `'named'`. The default value of `'auto'` will usually work, but you can also set it explicitly to `'default'`. That makes sure that Rollup assigns the default export that was generated for your CommonJS entry point to `module.exports`, and semantics do not change.
412
+
389
413
## Using with @rollup/plugin-node-resolve
390
414
391
415
Since most CommonJS packages you are importing are probably dependencies in `node_modules`, you may need to use [@rollup/plugin-node-resolve](https://github.com/rollup/plugins/tree/master/packages/node-resolve):
0 commit comments