listpage_cli 0.0.187

package/templates/common/config/rush/command-line.json

@@ -0,0 +1,407 @@
+/**
+ * This configuration file defines custom commands for the "rush" command-line.
+ * More documentation is available on the Rush website: https://rushjs.io
+ */
+{
+  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/command-line.schema.json",
+
+  /**
+   * Custom "commands" introduce new verbs for the command-line.  To see the help for these
+   * example commands, try "rush --help", "rush my-bulk-command --help", or
+   * "rush my-global-command --help".
+   */
+  "commands": [
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom command.
+    //    * Rush's "bulk" commands are invoked separately for each project.  By default, the command will run for
+    //    * every project in the repo, according to the dependency graph (similar to how "rush build" works).
+    //    * The set of projects can be restricted e.g. using the "--to" or "--from" parameters.
+    //    */
+    //   "commandKind": "bulk",
+    // 
+    //   /**
+    //    * (Required) The name that will be typed as part of the command line.  This is also the name
+    //    * of the "scripts" hook in the project's package.json file (if "shellCommand" is not specified).
+    //    *
+    //    * The name should be comprised of lower case words separated by hyphens or colons. The name should include an
+    //    * English verb (e.g. "deploy"). Use a hyphen to separate words (e.g. "upload-docs"). A group of related commands
+    //    * can be prefixed with a colon (e.g. "docs:generate", "docs:deploy", "docs:serve", etc).
+    //    *
+    //    * Note that if the "rebuild" command is overridden here, it becomes separated from the "build" command
+    //    * and will call the "rebuild" script instead of the "build" script.
+    //    */
+    //   "name": "my-bulk-command",
+    // 
+    //   /**
+    //    * (Required) A short summary of the custom command to be shown when printing command line
+    //    * help, e.g. "rush --help".
+    //    */
+    //   "summary": "Example bulk custom command",
+    // 
+    //   /**
+    //    * A detailed description of the command to be shown when printing command line
+    //    * help (e.g. "rush --help my-command").
+    //    * If omitted, the "summary" text will be shown instead.
+    //    *
+    //    * Whenever you introduce commands/parameters, taking a little time to write meaningful
+    //    * documentation can make a big difference for the developer experience in your repo.
+    //    */
+    //   "description": "This is an example custom command that runs separately for each project",
+    // 
+    //   /**
+    //    * By default, Rush operations acquire a lock file which prevents multiple commands from executing simultaneously
+    //    * in the same repo folder.  (For example, it would be a mistake to run "rush install" and "rush build" at the
+    //    * same time.)  If your command makes sense to run concurrently with other operations,
+    //    * set "safeForSimultaneousRushProcesses" to true to disable this protection.
+    //    *
+    //    * In particular, this is needed for custom scripts that invoke other Rush commands.
+    //    */
+    //   "safeForSimultaneousRushProcesses": false,
+    // 
+    //   /**
+    //    * (Optional) If the `shellCommand` field is set for a bulk command, Rush will invoke it for each
+    //    * selected project; otherwise, Rush will invoke the package.json `"scripts"` entry matching Rush command name.
+    //    *
+    //    * The string is the path to a script that will be invoked using the OS shell. The working directory will be
+    //    * the folder that contains rush.json.  If custom parameters are associated with this command, their
+    //    * values will be appended to the end of this string.
+    //    */
+    //   // "shellCommand": "node common/scripts/my-bulk-command.js",
+    // 
+    //   /**
+    //    * (Required) If true, then this command is safe to be run in parallel, i.e. executed
+    //    * simultaneously for multiple projects.  Similar to "rush build", regardless of parallelism
+    //    * projects will not start processing until their dependencies have completed processing.
+    //    */
+    //   "enableParallelism": false,
+    // 
+    //   /**
+    //    * Controls whether weighted operations can start when the total weight would exceed the limit
+    //    * but is currently below the limit. This setting only applies when "enableParallelism" is true
+    //    * and operations have a "weight" property configured in their rush-project.json "operationSettings".
+    //    * Choose true (the default) to favor parallelism.  Choose false to strictly stay under the limit.
+    //    */
+    //   "allowOversubscription": false,
+    // 
+    //   /**
+    //    * Normally projects will be processed according to their dependency order: a given project will not start
+    //    * processing the command until all of its dependencies have completed.  This restriction doesn't apply for
+    //    * certain operations, for example a "clean" task that deletes output files.  In this case
+    //    * you can set "ignoreDependencyOrder" to true to increase parallelism.
+    //    */
+    //   "ignoreDependencyOrder": false,
+    // 
+    //   /**
+    //    * Normally Rush requires that each project's package.json has a "scripts" entry matching
+    //    * the custom command name.  To disable this check, set "ignoreMissingScript" to true;
+    //    * projects with a missing definition will be skipped.
+    //    */
+    //   "ignoreMissingScript": false,
+    // 
+    //   /**
+    //    * When invoking shell scripts, Rush uses a heuristic to distinguish errors from warnings:
+    //    * - If the shell script returns a nonzero process exit code, Rush interprets this as "one or more errors".
+    //    * Error output is displayed in red, and it prevents Rush from attempting to process any downstream projects.
+    //    * - If the shell script returns a zero process exit code but writes something to its stderr stream,
+    //    * Rush interprets this as "one or more warnings". Warning output is printed in yellow, but does NOT prevent
+    //    * Rush from processing downstream projects.
+    //    *
+    //    * Thus, warnings do not interfere with local development, but they will cause a CI job to fail, because
+    //    * the Rush process itself returns a nonzero exit code if there are any warnings or errors. This is by design.
+    //    * In an active monorepo, we've found that if you allow any warnings in your main branch, it inadvertently
+    //    * teaches developers to ignore warnings, which quickly leads to a situation where so many "expected" warnings
+    //    * have accumulated that warnings no longer serve any useful purpose.
+    //    *
+    //    * Sometimes a poorly behaved task will write output to stderr even though its operation was successful.
+    //    * In that case, it's strongly recommended to fix the task.  However, as a workaround you can set
+    //    * allowWarningsInSuccessfulBuild=true, which causes Rush to return a nonzero exit code for errors only.
+    //    *
+    //    * Note: The default value is false. In Rush 5.7.x and earlier, the default value was true.
+    //    */
+    //   "allowWarningsInSuccessfulBuild": false,
+    // 
+    //   /**
+    //    * If true then this command will be incremental like the built-in "build" command
+    //    */
+    //   "incremental": false,
+    // 
+    //   /**
+    //    * (EXPERIMENTAL) Normally Rush terminates after the command finishes. If this option is set to "true" Rush
+    //    * will instead enter a loop where it watches the file system for changes to the selected projects. Whenever a
+    //    * change is detected, the command will be invoked again for the changed project and any selected projects that
+    //    * directly or indirectly depend on it.
+    //    *
+    //    * For details, refer to the website article "Using watch mode".
+    //    */
+    //   "watchForChanges": false,
+    // 
+    //   /**
+    //    * (EXPERIMENTAL) Disable cache for this action. This may be useful if this command affects state outside of
+    //    * projects' own folders.
+    //    */
+    //   "disableBuildCache": false
+    // },
+    // 
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom command.
+    //    * Rush's "global" commands are invoked once for the entire repo.
+    //    */
+    //   "commandKind": "global",
+    // 
+    //   "name": "my-global-command",
+    //   "summary": "Example global custom command",
+    //   "description": "This is an example custom command that runs once for the entire repo",
+    // 
+    //   "safeForSimultaneousRushProcesses": false,
+    // 
+    //   /**
+    //    * (Required) A script that will be invoked using the OS shell. The working directory will be
+    //    * the folder that contains rush.json.  If custom parameters are associated with this command, their
+    //    * values will be appended to the end of this string.
+    //    */
+    //   "shellCommand": "node common/scripts/my-global-command.js",
+    // 
+    //   /**
+    //    * If your "shellCommand" script depends on NPM packages, the recommended best practice is
+    //    * to make it into a regular Rush project that builds using your normal toolchain.  In cases where
+    //    * the command needs to work without first having to run "rush build", the recommended practice
+    //    * is to publish the project to an NPM registry and use common/scripts/install-run.js to launch it.
+    //    *
+    //    * Autoinstallers offer another possibility: They are folders under "common/autoinstallers" with
+    //    * a package.json file and shrinkwrap file. Rush will automatically invoke the package manager to
+    //    * install these dependencies before an associated command is invoked.  Autoinstallers have the
+    //    * advantage that they work even in a branch where "rush install" is broken, which makes them a
+    //    * good solution for Git hook scripts.  But they have the disadvantages of not being buildable
+    //    * projects, and of increasing the overall installation footprint for your monorepo.
+    //    *
+    //    * The "autoinstallerName" setting must not contain a path and must be a valid NPM package name.
+    //    * For example, the name "my-task" would map to "common/autoinstallers/my-task/package.json", and
+    //    * the "common/autoinstallers/my-task/node_modules/.bin" folder would be added to the shell PATH when
+    //    * invoking the "shellCommand".
+    //    */
+    //   // "autoinstallerName": "my-task"
+    // }
+  ],
+
+  /**
+   * Custom "parameters" introduce new parameters for specified Rush command-line commands.
+   * For example, you might define a "--production" parameter for the "rush build" command.
+   */
+  "parameters": [
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom parameter.
+    //    * A "flag" is a custom command-line parameter whose presence acts as an on/off switch.
+    //    */
+    //   "parameterKind": "flag",
+    // 
+    //   /**
+    //    * (Required) The long name of the parameter.  It must be lower-case and use dash delimiters.
+    //    */
+    //   "longName": "--my-flag",
+    // 
+    //   /**
+    //    * An optional alternative short name for the parameter.  It must be a dash followed by a single
+    //    * lower-case or upper-case letter, which is case-sensitive.
+    //    *
+    //    * NOTE: The Rush developers recommend that automation scripts should always use the long name
+    //    * to improve readability.  The short name is only intended as a convenience for humans.
+    //    * The alphabet letters run out quickly, and are difficult to memorize, so *only* use
+    //    * a short name if you expect the parameter to be needed very often in everyday operations.
+    //    */
+    //   "shortName": "-m",
+    // 
+    //   /**
+    //    * (Required) A long description to be shown in the command-line help.
+    //    *
+    //    * Whenever you introduce commands/parameters, taking a little time to write meaningful
+    //    * documentation can make a big difference for the developer experience in your repo.
+    //    */
+    //   "description": "A custom flag parameter that is passed to the scripts that are invoked when building projects",
+    // 
+    //   /**
+    //    * (Required) A list of custom commands and/or built-in Rush commands that this parameter may
+    //    * be used with.  The parameter will be appended to the shell command that Rush invokes.
+    //    */
+    //   "associatedCommands": ["build", "rebuild"]
+    // },
+    // 
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom parameter.
+    //    * A "string" is a custom command-line parameter whose argument is a single text string.
+    //    */
+    //   "parameterKind": "string",
+    //   "longName": "--my-string",
+    //   "description": "A custom string parameter for the \"my-global-command\" custom command",
+    // 
+    //   "associatedCommands": ["my-global-command"],
+    // 
+    //   "argumentName": "SOME_TEXT",
+    // 
+    //   /**
+    //    * If true, this parameter must be included with the command.  The default is false.
+    //    */
+    //   "required": false
+    // },
+    // 
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom parameter.
+    //    * A "choice" is a custom command-line parameter whose argument must be chosen from a list of
+    //    * allowable alternatives (similar to an enum).
+    //    */
+    //   "parameterKind": "choice",
+    //   "longName": "--my-choice",
+    //   "description": "A custom choice parameter for the \"my-global-command\" custom command",
+    // 
+    //   "associatedCommands": ["my-global-command"],
+    //   "required": false,
+    // 
+    //   /**
+    //    * If a "defaultValue" is specified, then if the Rush command line is invoked without
+    //    * this parameter, it will be automatically added with the "defaultValue" as the argument.
+    //    * The value must be one of the defined alternatives.
+    //    */
+    //   "defaultValue": "vanilla",
+    // 
+    //   /**
+    //    * (Required) A list of alternative argument values that can be chosen for this parameter.
+    //    */
+    //   "alternatives": [
+    //     {
+    //       /**
+    //        * A token that is one of the alternatives that can be used with the choice parameter,
+    //        * e.g. "vanilla" in "--flavor vanilla".
+    //        */
+    //       "name": "vanilla",
+    // 
+    //       /**
+    //        * A detailed description for the alternative that can be shown in the command-line help.
+    //        *
+    //        * Whenever you introduce commands/parameters, taking a little time to write meaningful
+    //        * documentation can make a big difference for the developer experience in your repo.
+    //        */
+    //       "description": "Use the vanilla flavor"
+    //     },
+    // 
+    //     {
+    //       "name": "chocolate",
+    //       "description": "Use the chocolate flavor"
+    //     },
+    // 
+    //     {
+    //       "name": "strawberry",
+    //       "description": "Use the strawberry flavor"
+    //     }
+    //   ]
+    // },
+    // 
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom parameter.
+    //    * An "integer" is a custom command-line parameter whose value is an integer number.
+    //    */
+    //   "parameterKind": "integer",
+    //   "longName": "--my-integer",
+    //   "description": "A custom integer parameter for the \"my-global-command\" custom command",
+    // 
+    //   "associatedCommands": ["my-global-command"],
+    //   "argumentName": "SOME_NUMBER",
+    //   "required": false
+    // },
+    // 
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom parameter.
+    //    * An "integerList" is a custom command-line parameter whose argument is an integer.
+    //    * The parameter can be specified multiple times to build a list.
+    //    *
+    //    * For example, if the parameter name is "--my-integer-list", then the custom command
+    //    * might be invoked as
+    //    * `rush my-global-command --my-integer-list 1 --my-integer-list 2 --my-integer-list 3`
+    //    * and the parsed array would be [1,2,3].
+    //    */
+    //   "parameterKind": "integerList",
+    //   "longName": "--my-integer-list",
+    //   "description": "A custom integer list parameter for the \"my-global-command\" custom command",
+    // 
+    //   "associatedCommands": ["my-global-command"],
+    //   "argumentName": "SOME_NUMBER",
+    //   "required": false
+    // },
+    // 
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom parameter.
+    //    * An "stringList" is a custom command-line parameter whose argument is a text string.
+    //    * The parameter can be specified multiple times to build a list.
+    //    *
+    //    * For example, if the parameter name is "--my-string-list", then the custom command
+    //    * might be invoked as
+    //    * `rush my-global-command --my-string-list A --my-string-list B --my-string-list C`
+    //    * and the parsed array would be [A,B,C].
+    //    */
+    //   "parameterKind": "stringList",
+    //   "longName": "--my-string-list",
+    //   "description": "A custom string list parameter for the \"my-global-command\" custom command",
+    // 
+    //   "associatedCommands": ["my-global-command"],
+    //   "argumentName": "SOME_TEXT",
+    //   "required": false
+    // },
+    // 
+    // {
+    //   /**
+    //    * (Required) Determines the type of custom parameter.
+    //    * A "choice" is a custom command-line parameter whose argument must be chosen from a list of
+    //    * allowable alternatives (similar to an enum).
+    //    * The parameter can be specified multiple times to build a list.
+    //    *
+    //    * For example, if the parameter name is "--my-choice-list", then the custom command
+    //    * might be invoked as
+    //    * `rush my-global-command --my-string-list vanilla --my-string-list chocolate`
+    //    * and the parsed array would be [vanilla,chocolate].
+    //    */
+    //   "parameterKind": "choiceList",
+    //   "longName": "--my-choice-list",
+    //   "description": "A custom choice list parameter for the \"my-global-command\" custom command",
+    // 
+    //   "associatedCommands": ["my-global-command"],
+    //   "required": false,
+    // 
+    //   /**
+    //    * (Required) A list of alternative argument values that can be chosen for this parameter.
+    //    */
+    //   "alternatives": [
+    //     {
+    //       /**
+    //        * A token that is one of the alternatives that can be used with the choice parameter,
+    //        * e.g. "vanilla" in "--flavor vanilla".
+    //        */
+    //       "name": "vanilla",
+    // 
+    //       /**
+    //        * A detailed description for the alternative that can be shown in the command-line help.
+    //        *
+    //        * Whenever you introduce commands/parameters, taking a little time to write meaningful
+    //        * documentation can make a big difference for the developer experience in your repo.
+    //        */
+    //       "description": "Use the vanilla flavor"
+    //     },
+    // 
+    //     {
+    //       "name": "chocolate",
+    //       "description": "Use the chocolate flavor"
+    //     },
+    // 
+    //     {
+    //       "name": "strawberry",
+    //       "description": "Use the strawberry flavor"
+    //     }
+    //   ]
+    // }
+  ]
+}

package/templates/common/config/rush/common-versions.json

@@ -0,0 +1,77 @@
+/**
+ * This configuration file specifies NPM dependency version selections that affect all projects
+ * in a Rush repo.  More documentation is available on the Rush website: https://rushjs.io
+ */
+{
+  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/common-versions.schema.json",
+
+  /**
+   * A table that specifies a "preferred version" for a given NPM package.  This feature is typically used
+   * to hold back an indirect dependency to a specific older version, or to reduce duplication of indirect dependencies.
+   *
+   * The "preferredVersions" value can be any SemVer range specifier (e.g. "~1.2.3").  Rush injects these values into
+   * the "dependencies" field of the top-level common/temp/package.json, which influences how the package manager
+   * will calculate versions.  The specific effect depends on your package manager.  Generally it will have no
+   * effect on an incompatible or already constrained SemVer range.  If you are using PNPM, similar effects can be
+   * achieved using the pnpmfile.js hook.  See the Rush documentation for more details.
+   *
+   * After modifying this field, it's recommended to run "rush update --full" so that the package manager
+   * will recalculate all version selections.
+   */
+  "preferredVersions": {
+    /**
+     * When someone asks for "^1.0.0" make sure they get "1.2.3" when working in this repo,
+     * instead of the latest version.
+     */
+    // "some-library": "1.2.3"
+  },
+
+  /**
+   * When set to true, for all projects in the repo, all dependencies will be automatically added as preferredVersions,
+   * except in cases where different projects specify different version ranges for a given dependency.  For older
+   * package managers, this tended to reduce duplication of indirect dependencies.  However, it can sometimes cause
+   * trouble for indirect dependencies with incompatible peerDependencies ranges.
+   *
+   * The default value is true.  If you're encountering installation errors related to peer dependencies,
+   * it's recommended to set this to false.
+   *
+   * After modifying this field, it's recommended to run "rush update --full" so that the package manager
+   * will recalculate all version selections.
+   */
+  // "implicitlyPreferredVersions": false,
+
+  /**
+   * If you would like the version specifiers for your dependencies to be consistent, then
+   * uncomment this line. This is effectively similar to running "rush check" before any
+   * of the following commands:
+   *
+   *   rush install, rush update, rush link, rush version, rush publish
+   *
+   * In some cases you may want this turned on, but need to allow certain packages to use a different
+   * version. In those cases, you will need to add an entry to the "allowedAlternativeVersions"
+   * section of the common-versions.json.
+   *
+   * In the case that subspaces is enabled, this setting will take effect at a subspace level.
+   */
+  // "ensureConsistentVersions": true,
+
+  /**
+   * The "rush check" command can be used to enforce that every project in the repo must specify
+   * the same SemVer range for a given dependency.  However, sometimes exceptions are needed.
+   * The allowedAlternativeVersions table allows you to list other SemVer ranges that will be
+   * accepted by "rush check" for a given dependency.
+   *
+   * IMPORTANT: THIS TABLE IS FOR *ADDITIONAL* VERSION RANGES THAT ARE ALTERNATIVES TO THE
+   * USUAL VERSION (WHICH IS INFERRED BY LOOKING AT ALL PROJECTS IN THE REPO).
+   * This design avoids unnecessary churn in this file.
+   */
+  "allowedAlternativeVersions": {
+    /**
+     * For example, allow some projects to use an older TypeScript compiler
+     * (in addition to whatever "usual" version is being used by other projects in the repo):
+     */
+    // "typescript": [
+    //   "~2.4.0"
+    // ]
+  }
+}

package/templates/common/config/rush/custom-tips.json

@@ -0,0 +1,29 @@
+/**
+ * This configuration file allows repo maintainers to configure extra details to be
+ * printed alongside certain Rush messages.  More documentation is available on the
+ * Rush website: https://rushjs.io
+ */
+{
+  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/custom-tips.schema.json",
+
+  /**
+   * Custom tips allow you to annotate Rush's console messages with advice tailored for
+   * your specific monorepo.
+   */
+  "customTips": [
+    // {
+    //   /**
+    //    * (REQUIRED) An identifier indicating a message that may be printed by Rush.
+    //    * If that message is printed, then this custom tip will be shown.
+    //    * The list of available tip identifiers can be found on this page:
+    //    * https://rushjs.io/pages/maintainer/custom_tips/
+    //    */
+    //   "tipId": "TIP_RUSH_INCONSISTENT_VERSIONS",
+    // 
+    //   /**
+    //    * (REQUIRED) The message text to be displayed for this tip.
+    //    */
+    //   "message": "For additional troubleshooting information, refer this wiki article:\n\nhttps://intranet.contoso.com/docs/pnpm-mismatch"
+    // }
+  ]
+}

package/templates/common/config/rush/experiments.json

@@ -0,0 +1,121 @@
+/**
+ * This configuration file allows repo maintainers to enable and disable experimental
+ * Rush features.  More documentation is available on the Rush website: https://rushjs.io
+ */
+{
+  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/experiments.schema.json",
+
+  /**
+   * By default, 'rush install' passes --no-prefer-frozen-lockfile to 'pnpm install'.
+   * Set this option to true to pass '--frozen-lockfile' instead for faster installs.
+   */
+  // "usePnpmFrozenLockfileForRushInstall": true,
+
+  /**
+   * By default, 'rush update' passes --no-prefer-frozen-lockfile to 'pnpm install'.
+   * Set this option to true to pass '--prefer-frozen-lockfile' instead to minimize shrinkwrap changes.
+   */
+  // "usePnpmPreferFrozenLockfileForRushUpdate": true,
+
+  /**
+   * By default, 'rush update' runs as a single operation.
+   * Set this option to true to instead update the lockfile with `--lockfile-only`, then perform a `--frozen-lockfile` install.
+   * Necessary when using the `afterAllResolved` hook in .pnpmfile.cjs.
+   */
+  // "usePnpmLockfileOnlyThenFrozenLockfileForRushUpdate": true,
+
+  /**
+   * If using the 'preventManualShrinkwrapChanges' option, restricts the hash to only include the layout of external dependencies.
+   * Used to allow links between workspace projects or the addition/removal of references to existing dependency versions to not
+   * cause hash changes.
+   */
+  // "omitImportersFromPreventManualShrinkwrapChanges": true,
+
+  /**
+   * If true, the chmod field in temporary project tar headers will not be normalized.
+   * This normalization can help ensure consistent tarball integrity across platforms.
+   */
+  // "noChmodFieldInTarHeaderNormalization": true,
+
+  /**
+   * If true, build caching will respect the allowWarningsInSuccessfulBuild flag and cache builds with warnings.
+   * This will not replay warnings from the cached build.
+   */
+  // "buildCacheWithAllowWarningsInSuccessfulBuild": true,
+
+  /**
+   * If true, build skipping will respect the allowWarningsInSuccessfulBuild flag and skip builds with warnings.
+   * This will not replay warnings from the skipped build.
+   */
+  // "buildSkipWithAllowWarningsInSuccessfulBuild": true,
+
+  /**
+   * If true, perform a clean install after when running `rush install` or `rush update` if the
+   * `.npmrc` file has changed since the last install.
+   */
+  // "cleanInstallAfterNpmrcChanges": true,
+
+  /**
+   * If true, print the outputs of shell commands defined in event hooks to the console.
+   */
+  // "printEventHooksOutputToConsole": true,
+
+  /**
+   * If true, Rush will not allow node_modules in the repo folder or in parent folders.
+   */
+  // "forbidPhantomResolvableNodeModulesFolders": true,
+
+  /**
+   * (UNDER DEVELOPMENT) For certain installation problems involving peer dependencies, PNPM cannot
+   * correctly satisfy versioning requirements without installing duplicate copies of a package inside the
+   * node_modules folder. This poses a problem for "workspace:*" dependencies, as they are normally
+   * installed by making a symlink to the local project source folder. PNPM's "injected dependencies"
+   * feature provides a model for copying the local project folder into node_modules, however copying
+   * must occur AFTER the dependency project is built and BEFORE the consuming project starts to build.
+   * The "pnpm-sync" tool manages this operation; see its documentation for details.
+   * Enable this experiment if you want "rush" and "rushx" commands to resync injected dependencies
+   * by invoking "pnpm-sync" during the build.
+   */
+  // "usePnpmSyncForInjectedDependencies": true,
+
+  /**
+   * If set to true, Rush will generate a `project-impact-graph.yaml` file in the repository root during `rush update`.
+   */
+  // "generateProjectImpactGraphDuringRushUpdate": true,
+
+  /**
+   * If true, when running in watch mode, Rush will check for phase scripts named `_phase:<name>:ipc` and run them instead
+   * of `_phase:<name>` if they exist. The created child process will be provided with an IPC channel and expected to persist
+   * across invocations.
+   */
+  // "useIPCScriptsInWatchMode": true,
+
+  /**
+   * (UNDER DEVELOPMENT) The Rush alerts feature provides a way to send announcements to engineers
+   * working in the monorepo, by printing directly in the user's shell window when they invoke Rush commands.
+   * This ensures that important notices will be seen by anyone doing active development, since people often
+   * ignore normal discussion group messages or don't know to subscribe.
+   */
+   // "rushAlerts": true,
+
+
+  /**
+   * When using cobuilds, this experiment allows uncacheable operations to benefit from cobuild orchestration without using the build cache.
+   */
+   // "allowCobuildWithoutCache": true,
+
+   /**
+   * By default, rush perform a full scan of the entire repository. For example, Rush runs `git status` to check for local file changes.
+   * When this toggle is enabled, Rush will only scan specific paths, significantly speeding up Git operations.
+   */
+  // "enableSubpathScan": true,
+
+  /**
+   * Rush has a policy that normally requires Rush projects to specify `workspace:*` in package.json when depending
+   * on other projects in the workspace, unless they are explicitly declared as `decoupledLocalDependencies`
+   * in rush.json.  Enabling this experiment will remove that requirement for dependencies belonging to a different
+   * subspace.  This is useful for large product groups who work in separate subspaces and generally prefer to consume
+   * each other's packages via the NPM registry.
+   */
+  // "exemptDecoupledDependenciesBetweenSubspaces": false
+}