Merge pull request #23 from octogonz/main

Upgrade to Rush 5.141.2

common/config/rush/alert-scripts/rush-alert-node-upgrade.js

@@ -0,0 +1,6 @@
+module.exports.canShowAlert = function () {
+  console.log('Invoked script')
+
+  // (your logic goes here)
+  return true;
+};

common/config/rush/build-cache.json

@@ -34,6 +34,11 @@
    */
   // "cacheEntryNamePattern": "[projectName:normalize]-[phaseName:normalize]-[hash]"
 
+  /**
+   * (Optional) Salt to inject during calculation of the cache key. This can be used to invalidate the cache for all projects when the salt changes.
+   */
+  // "cacheHashSalt": "1",
+
   /**
    * Use this configuration with "cacheProvider"="azure-blob-storage"
    */
@@ -63,7 +68,17 @@
     /**
      * If set to true, allow writing to the cache. Defaults to false.
      */
-    // "isCacheWriteAllowed": true
+    // "isCacheWriteAllowed": true,
+
+    /**
+     * The Entra ID login flow to use. Defaults to 'AdoCodespacesAuth' on GitHub Codespaces, 'InteractiveBrowser' otherwise.
+     */
+    // "loginFlow": "InteractiveBrowser",
+
+    /**
+     * If set to true, reading the cache requires authentication. Defaults to false.
+     */
+    // "readRequiresAuthentication": true
   },
 
   /**

common/config/rush/experiments.json

@@ -82,10 +82,25 @@
    * 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
+  // "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
 }

common/config/rush/pnpm-config.json

@@ -261,6 +261,21 @@
     // "fsevents"
   ],
 
+  /**
+   * The `globalIgnoredOptionalDependencies` setting suppresses the installation of optional NPM
+   * dependencies specified in the list. This is useful when certain optional dependencies are
+   * not needed in your environment, such as platform-specific packages or dependencies that
+   * fail during installation but are not critical to your project.
+   * These settings are copied into the `pnpm.overrides` field of the `common/temp/package.json`
+   * file that is generated by Rush during installation, instructing PNPM to ignore the specified
+   * optional dependencies.
+   *
+   * PNPM documentation: https://pnpm.io/package_json#pnpmignoredoptionaldependencies
+   */
+  "globalIgnoredOptionalDependencies": [
+    // "fsevents"
+  ],
+
   /**
    * The `globalAllowedDeprecatedVersions` setting suppresses installation warnings for package
    * versions that the NPM registry reports as being deprecated.  This is useful if the

common/config/rush/rush-alerts.json

@@ -0,0 +1,113 @@
+/**
+ * This configuration file manages the Rush alerts feature.
+ * More documentation is available on the Rush website: https://rushjs.io
+ */
+{
+  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush-alerts.schema.json",
+
+  /**
+   * Settings such as `startTime` and `endTime` will use this timezone.
+   * If omitted, the default timezone is UTC (`+00:00`).
+   */
+  "timezone": "-08:00",
+
+  /**
+   * An array of alert messages and conditions for triggering them.
+   */
+  "alerts": [
+    {
+      /**
+       * The alertId is used to identify the alert.
+       */
+      "alertId": "node-js2",
+
+      /**
+       * When the alert is displayed, this title will appear at the top of the message box.
+       * It should be a single line of text, as concise as possible.
+       */
+      "title": "Node.js upgrade soon!!",
+
+      /**
+       * When the alert is displayed, this text appears in the message box.  To make the
+       * JSON file more readable, if the text is longer than one line, you can instead provide
+       * an array of strings that will be concatenated.  Your text may contain newline characters,
+       * but generally this is unnecessary because word-wrapping is automatically applied.
+       */
+      "message": [
+        "This Thursday, we will complete the Node.js version upgrade.  Any pipelines that",
+        " still have not upgraded will be temporarily disabled."
+      ],
+
+      /**
+       * (OPTIONAL) To avoid spamming users, the `title` and `message` settings should be kept
+       * as concise as possible.  If you need to provide more detail, use this setting to
+       * print a hyperlink to a web page with further guidance.
+       */
+      "detailsUrl": "https://contoso.com/team-wiki/2024-01-01-migration",
+
+      /**
+       * (OPTIONAL) If `startTime` is specified, then this alert will not be shown prior to
+       * that time.
+       *
+       * Keep in mind that the alert is not guaranteed to be shown at this time, or at all:
+       * Alerts are only displayed after a Rush command has triggered fetching of the
+       * latest rush-alerts.json configuration.  Also, display of alerts is throttled to
+       * avoid spamming the user with too many messages.  If you need to test your alert,
+       * set the environment variable `RUSH_ALERTS_DEBUG=1` to disable throttling.
+       *
+       * The `startTime` should be specified as `YYYY-MM-DD HH:MM` using 24 hour time format,
+       * or else `YYYY-MM-DD` in which case the time part will be `00:00` (start of that day).
+       * The time zone is obtained from the `timezone` setting above.
+       */
+      // "startTime": "2024-01-01 15:00",
+
+      /**
+       * (OPTIONAL) This alert will not be shown if the current time is later than `endTime`.
+       * The format is the same as `startTime`.
+       */
+      // "endTime": "2024-01-05",
+
+      /**
+       * (OPTIONAL) Specifies the maximum frequency at which this alert can be displayed within a defined time period.
+       * Options are:
+       *  "always" (default) - no limit on display frequency,
+       *  "monthly" - display up to once per month
+       *  "weekly" - display up to once per week
+       *  "daily" - display up to once per day
+       *  "hourly" - display up to once per hour
+       */
+      "maximumDisplayInterval": "hourly",
+
+      /**
+       * (OPTIONAL) Determines the order in which this alert is shown relative to other alerts, based on urgency.
+       * Options are:
+       *  "high" - displayed first
+       *  "normal" (default) - standard urgency
+       *  "low" - least urgency
+       */
+      "priority": "normal",
+
+      /**
+       * (OPTIONAL) The filename of a script that determines whether this alert can be shown,
+       * found in the "common/config/rush/alert-scripts" folder.  The script must define
+       * a CommonJS export named `canShowAlert` that returns a boolean value, for example:
+       *
+       * ```
+       * module.exports.canShowAlert = function () {
+       *   // (your logic goes here)
+       *   return true;
+       * }
+       * ```
+       *
+       * Rush will invoke this script with the working directory set to the monorepo root folder,
+       * with no guarantee that `rush install` has been run.  To ensure up-to-date alerts, Rush
+       * may fetch and checkout the "common/config/rush-alerts" folder in an unpredictable temporary
+       * path.  Therefore, your script should avoid importing dependencies from outside its folder,
+       * generally be kept as simple and reliable and quick as possible.  For more complex conditions,
+       * we suggest to design some other process that prepares a data file or environment variable
+       * that can be cheaply checked by your condition script.
+       */
+    //  "conditionScript": "rush-alert-node-upgrade.js"
+    }
+  ]
+}

rush.json

@@ -16,7 +16,7 @@
    * path segment in the "$schema" field for all your Rush config files.  This will ensure
    * correct error-underlining and tab-completion for editors such as VS Code.
    */
-  "rushVersion": "5.129.7",
+  "rushVersion": "5.141.2",
 
   /**
    * The next field selects which package manager should be installed and determines its version.
@@ -65,6 +65,13 @@
    */
   // "suppressNodeLtsWarning": false,
 
+  /**
+   * Rush normally prints a warning if it detects that the current version is not one published to the
+   * public npmjs.org registry. If you need to block calls to the npm registry, you can use this setting to disable
+   * Rush's check.
+   */
+  // "suppressRushIsPublicVersionCheck": false,
+
   /**
    * Large monorepos can become intimidating for newcomers if project folder paths don't follow
    * a consistent and recognizable pattern.  When the system allows nested folder trees,
@@ -262,6 +269,37 @@
     "postRushx": []
   },
 
+  /**
+   * Installation variants allow you to maintain a parallel set of configuration files that can be
+   * used to build the entire monorepo with an alternate set of dependencies.  For example, suppose
+   * you upgrade all your projects to use a new release of an important framework, but during a transition period
+   * you intend to maintain compatibility with the old release.  In this situation, you probably want your
+   * CI validation to build the entire repo twice: once with the old release, and once with the new release.
+   *
+   * Rush "installation variants" correspond to sets of config files located under this folder:
+   *
+   *   common/config/rush/variants/<variant_name>
+   *
+   * The variant folder can contain an alternate common-versions.json file.  Its "preferredVersions" field can be used
+   * to select older versions of dependencies (within a loose SemVer range specified in your package.json files).
+   * To install a variant, run "rush install --variant <variant_name>".
+   *
+   * For more details and instructions, see this article:  https://rushjs.io/pages/advanced/installation_variants/
+   */
+   "variants": [
+    // {
+    //   /**
+    //    * The folder name for this variant.
+    //    */
+    //   "variantName": "old-sdk",
+    // 
+    //   /**
+    //    * An informative description
+    //    */
+    //   "description": "Build this repo using the previous release of the SDK"
+    // }
+  ],
+
   /**
    * Rush can collect anonymous telemetry about everyday developer activity such as
    * success/failure of installs, builds, and other operations.  You can use this to identify