Merge pull request #2451 from gregbacchus/master

Fix spelling typos

apps/rush-lib/assets/rush-init/rush.json

@@ -100,7 +100,7 @@
      * If true, then `rush install` will use the PNPM workspaces feature to perform the
      * install.
      *
-     * This feature uses PNPM to peform the entire monorepo install. When using workspaces, Rush will
+     * This feature uses PNPM to perform the entire monorepo install. When using workspaces, Rush will
      * generate a "pnpm-workspace.yaml" file referencing all local projects to install. Rush will
      * also generate a "pnpmfile.js" which is used to provide preferred versions support. When install
      * is run, this pnpmfile will be used to replace dependency version ranges with a smaller subset
@@ -160,7 +160,7 @@
    *
    * The Rush developers recommend a "category folder" model, where buildable project folders
    * must always be exactly two levels below the repo root.  The parent folder acts as the category.
-   * This provides a basic facility for grouping related projects (e.g. "apps", "libaries",
+   * This provides a basic facility for grouping related projects (e.g. "apps", "libraries",
    * "tools", "prototypes") while still encouraging teams to organize their projects into
    * a unified taxonomy.  Limiting to 2 levels seems very restrictive at first, but if you have
    * 20 categories and 20 projects in each category, this scheme can easily accommodate hundreds
@@ -243,7 +243,7 @@
      * They are case-insensitive anchored JavaScript RegExps.  Example: ".*@example\.com"
      *
      * IMPORTANT: Because these are regular expressions encoded as JSON string literals,
-     * RegExp escapes need two backspashes, and ordinary periods should be "\\.".
+     * RegExp escapes need two backslashes, and ordinary periods should be "\\.".
      */
     /*[BEGIN "DEMO"]*/
     "allowedEmailRegExps": [
@@ -340,7 +340,7 @@
    * 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 compability with the old release.  In this situation, you probably want your
+   * 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/changes/@microsoft/rush/master_2021-01-28-02-28.json

@@ -0,0 +1,11 @@
+{
+  "changes": [
+    {
+      "packageName": "@microsoft/rush",
+      "comment": "Corrected spelling mistakes in rush.json",
+      "type": "none"
+    }
+  ],
+  "packageName": "@microsoft/rush",
+  "email": "[email protected]"
+}

rush.json

@@ -100,7 +100,7 @@
      * If true, then `rush install` will use the PNPM workspaces feature to perform the
      * install.
      *
-     * This feature uses PNPM to peform the entire monorepo install. When using workspaces, Rush will
+     * This feature uses PNPM to perform the entire monorepo install. When using workspaces, Rush will
      * generate a "pnpm-workspace.yaml" file referencing all local projects to install. Rush will
      * also generate a "pnpmfile.js" which is used to provide preferred versions support. When install
      * is run, this pnpmfile will be used to replace dependency version ranges with a smaller subset
@@ -160,7 +160,7 @@
    *
    * The Rush developers recommend a "category folder" model, where buildable project folders
    * must always be exactly two levels below the repo root.  The parent folder acts as the category.
-   * This provides a basic facility for grouping related projects (e.g. "apps", "libaries",
+   * This provides a basic facility for grouping related projects (e.g. "apps", "libraries",
    * "tools", "prototypes") while still encouraging teams to organize their projects into
    * a unified taxonomy.  Limiting to 2 levels seems very restrictive at first, but if you have
    * 20 categories and 20 projects in each category, this scheme can easily accommodate hundreds
@@ -239,7 +239,7 @@
      * They are case-insensitive anchored JavaScript RegExps.  Example: ".*@example\.com"
      *
      * IMPORTANT: Because these are regular expressions encoded as JSON string literals,
-     * RegExp escapes need two backspashes, and ordinary periods should be "\\.".
+     * RegExp escapes need two backlpashes, and ordinary periods should be "\\.".
      */
     "allowedEmailRegExps": ["[^@]+@users\\.noreply\\.github\\.com"],
 
@@ -322,7 +322,7 @@
    * 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 compability with the old release.  In this situation, you probably want your
+   * 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: