@rollup/plugin-commonjs

"auto"

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.

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/" -> "/".

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 plugin 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 whether it is an ES module. false

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. undefined

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. [ '.js' ]

Sometimes you have to leave require statements unconverted. Pass an array containing the IDs or a id => boolean function. []

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. false

If true then uses of global won't be dealt with by this plugin false

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 the try-catch clause.

- true: Default. 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 controls individual IDs.

true

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. undefined

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.

// 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. false

If false, skips source map generation for CommonJS modules. This will improve performance. true

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. "auto"

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. false