mirror of
https://github.com/Sevichecc/Urara-Blog.git
synced 2025-05-03 03:29:30 +08:00
230 lines
11 KiB
Text
230 lines
11 KiB
Text
/**
|
|
* https://github.com/rollup/plugins/blob/master/packages/commonjs/types/index.d.ts
|
|
*
|
|
* This source code is licensed under the MIT license found in the
|
|
* LICENSE file at
|
|
* https://github.com/rollup/plugins/blob/master/LICENSE
|
|
*/
|
|
export interface RollupCommonJSOptions {
|
|
/**
|
|
* 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`.
|
|
* @default undefined
|
|
*/
|
|
include?: string | RegExp | readonly (string | RegExp)[]
|
|
/**
|
|
* 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.
|
|
* @default undefined
|
|
*/
|
|
exclude?: string | RegExp | readonly (string | RegExp)[]
|
|
/**
|
|
* 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 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.
|
|
* @default "auto"
|
|
*/
|
|
strictRequires?: boolean | string | RegExp | readonly (string | RegExp)[]
|
|
/**
|
|
* 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?:
|
|
| boolean
|
|
| 'auto'
|
|
| 'preferred'
|
|
| 'namespace'
|
|
| ((id: string) => boolean | 'auto' | 'preferred' | 'namespace')
|
|
|
|
/**
|
|
* @default "auto"
|
|
*/
|
|
defaultIsModuleExports?: boolean | 'auto' | ((id: string) => boolean | 'auto')
|
|
/**
|
|
* 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
|
|
}
|