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.
A minimatch 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.
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.
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.
If true then uses of global won't be dealt with by this plugin
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.A minimatch 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.
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.
If false, skips source map generation for CommonJS modules. This will improve performance.
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 minimatch 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
minimatch pattern for fine-tuning.
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.
"auto"