nitro-nightly 3.0.1-20260121-183047-b2b37883 → 3.0.1-20260122-173608-d4f5eafd

package/dist/_libs/pluginutils+plugin-commonjs.d.mts

@@ -1,236 +1,236 @@
 import { Plugin } from "rollup";
 
-//#region node_modules/.pnpm/@rollup+pluginutils@5.3.0_rollup@4.55.2/node_modules/@rollup/pluginutils/types/index.d.ts
+//#region node_modules/.pnpm/@rollup+pluginutils@5.3.0_rollup@4.55.3/node_modules/@rollup/pluginutils/types/index.d.ts
 /**
  * A valid `picomatch` glob pattern, or array of patterns.
  */
 type FilterPattern = ReadonlyArray<string | RegExp> | string | RegExp | null;
 //#endregion
-//#region node_modules/.pnpm/@rollup+plugin-commonjs@29.0.0_rollup@4.55.2/node_modules/@rollup/plugin-commonjs/types/index.d.ts
+//#region node_modules/.pnpm/@rollup+plugin-commonjs@29.0.0_rollup@4.55.3/node_modules/@rollup/plugin-commonjs/types/index.d.ts
 type RequireReturnsDefaultOption = boolean | 'auto' | 'preferred' | 'namespace';
 type DefaultIsModuleExportsOption = boolean | 'auto';
 interface RollupCommonJSOptions {
   /**
-     * 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`.
-     * @default undefined
-     */
+   * 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`.
+   * @default undefined
+   */
   include?: FilterPattern;
   /**
-     * 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.
-     * @default undefined
-     */
+   * 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.
+   * @default undefined
+   */
   exclude?: FilterPattern;
   /**
-     * 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' ]
-     */
+   * 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
-     */
+   * 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
-     */
+   * 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
-     */
+   * 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
-     */
+   * 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 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.
-     * @default "auto"
-     */
+   * 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.
+   * @default "auto"
+   */
   strictRequires?: boolean | FilterPattern;
   /**
-     * Sometimes you have to leave require statements unconverted. Pass an array
-     * containing the IDs or a `id => boolean` function.
-     * @default []
-     */
+   * 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 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.
-     *
-     * @default true
-     */
+   * 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.
+   *
+   * @default true
+   */
   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 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.
-     * @default false
-     */
+   * 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.
+   * @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
-     */
+   * 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?: RequireReturnsDefaultOption | ((id: string) => RequireReturnsDefaultOption);
   /**
-     * @default "auto"
-     */
+   * @default "auto"
+   */
   defaultIsModuleExports?: DefaultIsModuleExportsOption | ((id: string) => DefaultIsModuleExportsOption);
   /**
-     * 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/"` -> `"/"`.
-     */
+   * 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.
-     */
+   * 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;
   /**
-     * When enabled, external Node built-ins (e.g., `node:fs`) required from wrapped CommonJS modules
-     * will use `createRequire(import.meta.url)` instead of being hoisted as ESM imports. This prevents
-     * eager loading of Node built-ins at module initialization time.
-     *
-     * Note: This option adds a dependency on `node:module` in the output, which may not be available
-     * in some environments like edge runtimes (Cloudflare Workers, Vercel Edge Runtime).
-     *
-     * @default false
-     */
+   * When enabled, external Node built-ins (e.g., `node:fs`) required from wrapped CommonJS modules
+   * will use `createRequire(import.meta.url)` instead of being hoisted as ESM imports. This prevents
+   * eager loading of Node built-ins at module initialization time.
+   *
+   * Note: This option adds a dependency on `node:module` in the output, which may not be available
+   * in some environments like edge runtimes (Cloudflare Workers, Vercel Edge Runtime).
+   *
+   * @default false
+   */
   requireNodeBuiltins?: boolean;
 }
 /**