From 1f329d492238455a06b0b9a640454158bf68625b Mon Sep 17 00:00:00 2001 From: Pete Gonzalez <4673363+octogonz@users.noreply.github.com> Date: Tue, 31 Oct 2023 12:00:30 -0700 Subject: [PATCH] Deploy website - based on 0cea759ff27b654094bf0902fd9248c04cca7647 --- 404.html | 4 ++-- assets/js/5aaad5b7.728171b9.js | 1 + assets/js/5aaad5b7.c5d210b5.js | 1 - assets/js/90ddd12c.1b808413.js | 1 - assets/js/90ddd12c.2fd03b54.js | 1 + assets/js/a6ae31b5.a0d943ef.js | 1 + assets/js/a6ae31b5.e0eb258f.js | 1 - assets/js/ad372154.1595ca27.js | 1 - assets/js/ad372154.d004cc6a.js | 1 + ...162f9.49447d6b.js => b93162f9.4c6e3096.js} | 2 +- assets/js/d98d853d.3513af17.js | 1 - assets/js/d98d853d.d10f8d08.js | 1 + ...n.b1e683a4.js => runtime~main.f06fdba5.js} | 2 +- index.html | 4 ++-- link/pnpm-issue-5132/index.html | 4 ++-- link/upgrading/index.html | 4 ++-- pages/advanced/api/index.html | 4 ++-- pages/advanced/compatibility_db/index.html | 4 ++-- pages/advanced/config_files/index.html | 4 ++-- pages/advanced/incremental_builds/index.html | 4 ++-- .../advanced/installation_variants/index.html | 4 ++-- pages/advanced/npm_doppelgangers/index.html | 4 ++-- pages/advanced/phantom_deps/index.html | 4 ++-- pages/advanced/pinned_versions/index.html | 4 ++-- pages/advanced/preferred_versions/index.html | 4 ++-- .../rush_files_and_folders/index.html | 4 ++-- pages/advanced/watch_mode/index.html | 4 ++-- pages/best_practices/change_logs/index.html | 4 ++-- pages/commands/rush-pnpm/index.html | 4 ++-- pages/commands/rush_add/index.html | 4 ++-- pages/commands/rush_build/index.html | 4 ++-- pages/commands/rush_change/index.html | 4 ++-- pages/commands/rush_check/index.html | 4 ++-- pages/commands/rush_deploy/index.html | 4 ++-- .../rush_init-autoinstaller/index.html | 4 ++-- pages/commands/rush_init-deploy/index.html | 4 ++-- pages/commands/rush_init/index.html | 4 ++-- pages/commands/rush_install/index.html | 4 ++-- pages/commands/rush_link/index.html | 4 ++-- pages/commands/rush_list/index.html | 4 ++-- pages/commands/rush_publish/index.html | 4 ++-- pages/commands/rush_purge/index.html | 4 ++-- pages/commands/rush_rebuild/index.html | 4 ++-- pages/commands/rush_remove/index.html | 4 ++-- pages/commands/rush_scan/index.html | 4 ++-- pages/commands/rush_setup/index.html | 4 ++-- pages/commands/rush_tab-complete/index.html | 4 ++-- pages/commands/rush_unlink/index.html | 4 ++-- .../rush_update-autoinstaller/index.html | 4 ++-- .../rush_update-cloud-credentials/index.html | 4 ++-- pages/commands/rush_update/index.html | 4 ++-- .../rush_upgrade-interactive/index.html | 4 ++-- pages/commands/rush_version/index.html | 4 ++-- pages/commands/rushx/index.html | 4 ++-- pages/configs/artifactory_json/index.html | 4 ++-- pages/configs/build-cache_json/index.html | 6 +++--- pages/configs/cobuild_json/index.html | 4 ++-- pages/configs/command-line_json/index.html | 4 ++-- pages/configs/command_line_json/index.html | 4 ++-- pages/configs/common-versions_json/index.html | 4 ++-- pages/configs/common_versions_json/index.html | 4 ++-- pages/configs/custom-tips_json/index.html | 4 ++-- pages/configs/deploy_json/index.html | 4 ++-- pages/configs/environment_vars/index.html | 19 ++++++++++++------- pages/configs/experiments_json/index.html | 6 +++--- pages/configs/npmrc-publish/index.html | 4 ++-- pages/configs/npmrc/index.html | 4 ++-- pages/configs/pnpm-config_json/index.html | 6 +++--- pages/configs/pnpmfile_cjs/index.html | 4 ++-- .../rush-plugin-manifest_json/index.html | 4 ++-- pages/configs/rush-plugins_json/index.html | 4 ++-- pages/configs/rush-project_json/index.html | 4 ++-- pages/configs/rush_json/index.html | 6 +++--- .../configs/version-policies_json/index.html | 4 ++-- .../configs/version_policies_json/index.html | 4 ++-- pages/contributing/index.html | 4 ++-- pages/developer/everyday_commands/index.html | 4 ++-- .../modifying_package_json/index.html | 4 ++-- pages/developer/new_developer/index.html | 4 ++-- pages/developer/other_commands/index.html | 4 ++-- pages/developer/project_tags/index.html | 4 ++-- pages/developer/selecting_subsets/index.html | 4 ++-- pages/developer/tab_completion/index.html | 4 ++-- pages/extensibility/api/index.html | 4 ++-- .../extensibility/creating_plugins/index.html | 4 ++-- pages/help/faq/index.html | 4 ++-- pages/help/support/index.html | 4 ++-- pages/intro/get_started/index.html | 4 ++-- pages/intro/welcome/index.html | 4 ++-- pages/intro/why_mono/index.html | 4 ++-- pages/maintainer/add_to_repo/index.html | 4 ++-- pages/maintainer/autoinstallers/index.html | 4 ++-- pages/maintainer/build_cache/index.html | 9 ++++----- pages/maintainer/cobuilds/index.html | 4 ++-- pages/maintainer/custom_commands/index.html | 4 ++-- pages/maintainer/custom_tips/index.html | 4 ++-- pages/maintainer/deploying/index.html | 4 ++-- .../maintainer/enabling_ci_builds/index.html | 4 ++-- pages/maintainer/enabling_prettier/index.html | 4 ++-- pages/maintainer/git_hooks/index.html | 4 ++-- pages/maintainer/npm_registry_auth/index.html | 4 ++-- pages/maintainer/package_managers/index.html | 4 ++-- pages/maintainer/phased_builds/index.html | 4 ++-- pages/maintainer/publishing/index.html | 4 ++-- .../recommended_settings/index.html | 4 ++-- pages/maintainer/setup_new_repo/index.html | 4 ++-- pages/maintainer/setup_policies/index.html | 4 ++-- .../maintainer/using_rush_plugins/index.html | 4 ++-- pages/news/index.html | 4 ++-- search/index.html | 4 ++-- zh-cn/404.html | 4 ++-- ...c47f5.27cb9e29.js => a5cc47f5.0c6954d0.js} | 2 +- ...n.253e28f8.js => runtime~main.47a3a2ca.js} | 2 +- zh-cn/index.html | 4 ++-- zh-cn/link/pnpm-issue-5132/index.html | 4 ++-- zh-cn/link/upgrading/index.html | 4 ++-- zh-cn/pages/advanced/api/index.html | 4 ++-- .../advanced/compatibility_db/index.html | 4 ++-- zh-cn/pages/advanced/config_files/index.html | 4 ++-- .../advanced/incremental_builds/index.html | 4 ++-- .../advanced/installation_variants/index.html | 4 ++-- .../advanced/npm_doppelgangers/index.html | 4 ++-- zh-cn/pages/advanced/phantom_deps/index.html | 4 ++-- .../pages/advanced/pinned_versions/index.html | 4 ++-- .../advanced/preferred_versions/index.html | 4 ++-- .../rush_files_and_folders/index.html | 4 ++-- zh-cn/pages/advanced/watch_mode/index.html | 4 ++-- .../best_practices/change_logs/index.html | 4 ++-- zh-cn/pages/commands/rush-pnpm/index.html | 4 ++-- zh-cn/pages/commands/rush_add/index.html | 4 ++-- zh-cn/pages/commands/rush_build/index.html | 4 ++-- zh-cn/pages/commands/rush_change/index.html | 4 ++-- zh-cn/pages/commands/rush_check/index.html | 4 ++-- zh-cn/pages/commands/rush_deploy/index.html | 4 ++-- .../rush_init-autoinstaller/index.html | 4 ++-- .../commands/rush_init-deploy/index.html | 4 ++-- zh-cn/pages/commands/rush_init/index.html | 4 ++-- zh-cn/pages/commands/rush_install/index.html | 4 ++-- zh-cn/pages/commands/rush_link/index.html | 4 ++-- zh-cn/pages/commands/rush_list/index.html | 4 ++-- zh-cn/pages/commands/rush_publish/index.html | 4 ++-- zh-cn/pages/commands/rush_purge/index.html | 4 ++-- zh-cn/pages/commands/rush_rebuild/index.html | 4 ++-- zh-cn/pages/commands/rush_remove/index.html | 4 ++-- zh-cn/pages/commands/rush_scan/index.html | 4 ++-- zh-cn/pages/commands/rush_setup/index.html | 4 ++-- .../commands/rush_tab-complete/index.html | 4 ++-- zh-cn/pages/commands/rush_unlink/index.html | 4 ++-- .../rush_update-autoinstaller/index.html | 4 ++-- .../rush_update-cloud-credentials/index.html | 4 ++-- zh-cn/pages/commands/rush_update/index.html | 4 ++-- .../rush_upgrade-interactive/index.html | 4 ++-- zh-cn/pages/commands/rush_version/index.html | 4 ++-- zh-cn/pages/commands/rushx/index.html | 4 ++-- .../pages/configs/artifactory_json/index.html | 4 ++-- .../pages/configs/build-cache_json/index.html | 4 ++-- zh-cn/pages/configs/cobuild_json/index.html | 4 ++-- .../configs/command-line_json/index.html | 4 ++-- .../configs/command_line_json/index.html | 4 ++-- .../configs/common-versions_json/index.html | 4 ++-- .../configs/common_versions_json/index.html | 4 ++-- .../pages/configs/custom-tips_json/index.html | 4 ++-- zh-cn/pages/configs/deploy_json/index.html | 4 ++-- .../pages/configs/environment_vars/index.html | 4 ++-- .../pages/configs/experiments_json/index.html | 4 ++-- zh-cn/pages/configs/npmrc-publish/index.html | 4 ++-- zh-cn/pages/configs/npmrc/index.html | 4 ++-- .../pages/configs/pnpm-config_json/index.html | 4 ++-- zh-cn/pages/configs/pnpmfile_cjs/index.html | 4 ++-- .../rush-plugin-manifest_json/index.html | 4 ++-- .../configs/rush-plugins_json/index.html | 4 ++-- .../configs/rush-project_json/index.html | 4 ++-- zh-cn/pages/configs/rush_json/index.html | 4 ++-- .../configs/version-policies_json/index.html | 4 ++-- .../configs/version_policies_json/index.html | 4 ++-- zh-cn/pages/contributing/index.html | 4 ++-- .../developer/everyday_commands/index.html | 4 ++-- .../modifying_package_json/index.html | 4 ++-- .../pages/developer/new_developer/index.html | 4 ++-- .../pages/developer/other_commands/index.html | 4 ++-- zh-cn/pages/developer/project_tags/index.html | 4 ++-- .../developer/selecting_subsets/index.html | 4 ++-- .../pages/developer/tab_completion/index.html | 4 ++-- zh-cn/pages/extensibility/api/index.html | 4 ++-- .../extensibility/creating_plugins/index.html | 4 ++-- zh-cn/pages/help/faq/index.html | 4 ++-- zh-cn/pages/help/support/index.html | 4 ++-- zh-cn/pages/intro/get_started/index.html | 4 ++-- zh-cn/pages/intro/welcome/index.html | 6 +++--- zh-cn/pages/intro/why_mono/index.html | 4 ++-- zh-cn/pages/maintainer/add_to_repo/index.html | 4 ++-- .../maintainer/autoinstallers/index.html | 4 ++-- zh-cn/pages/maintainer/build_cache/index.html | 4 ++-- zh-cn/pages/maintainer/cobuilds/index.html | 4 ++-- .../maintainer/custom_commands/index.html | 4 ++-- zh-cn/pages/maintainer/custom_tips/index.html | 4 ++-- zh-cn/pages/maintainer/deploying/index.html | 4 ++-- .../maintainer/enabling_ci_builds/index.html | 4 ++-- .../maintainer/enabling_prettier/index.html | 4 ++-- zh-cn/pages/maintainer/git_hooks/index.html | 4 ++-- .../maintainer/npm_registry_auth/index.html | 4 ++-- .../maintainer/package_managers/index.html | 4 ++-- .../pages/maintainer/phased_builds/index.html | 4 ++-- zh-cn/pages/maintainer/publishing/index.html | 4 ++-- .../recommended_settings/index.html | 4 ++-- .../maintainer/setup_new_repo/index.html | 4 ++-- .../maintainer/setup_policies/index.html | 4 ++-- .../maintainer/using_rush_plugins/index.html | 4 ++-- zh-cn/pages/news/index.html | 4 ++-- zh-cn/search/index.html | 4 ++-- 210 files changed, 418 insertions(+), 414 deletions(-) create mode 100644 assets/js/5aaad5b7.728171b9.js delete mode 100644 assets/js/5aaad5b7.c5d210b5.js delete mode 100644 assets/js/90ddd12c.1b808413.js create mode 100644 assets/js/90ddd12c.2fd03b54.js create mode 100644 assets/js/a6ae31b5.a0d943ef.js delete mode 100644 assets/js/a6ae31b5.e0eb258f.js delete mode 100644 assets/js/ad372154.1595ca27.js create mode 100644 assets/js/ad372154.d004cc6a.js rename assets/js/{b93162f9.49447d6b.js => b93162f9.4c6e3096.js} (59%) delete mode 100644 assets/js/d98d853d.3513af17.js create mode 100644 assets/js/d98d853d.d10f8d08.js rename assets/js/{runtime~main.b1e683a4.js => runtime~main.f06fdba5.js} (94%) rename zh-cn/assets/js/{a5cc47f5.27cb9e29.js => a5cc47f5.0c6954d0.js} (99%) rename zh-cn/assets/js/{runtime~main.253e28f8.js => runtime~main.47a3a2ca.js} (99%) diff --git a/404.html b/404.html index cb2870af..031d1d38 100644 --- a/404.html +++ b/404.html @@ -6,13 +6,13 @@ Page Not Found | Rush - +
Rush StackShopBlogEvents
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/assets/js/5aaad5b7.728171b9.js b/assets/js/5aaad5b7.728171b9.js new file mode 100644 index 00000000..91f02c58 --- /dev/null +++ b/assets/js/5aaad5b7.728171b9.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[5584],{158:(e,n,t)=>{t.d(n,{Zo:()=>h,kt:()=>m});var o=t(6393);function s(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function r(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);n&&(o=o.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,o)}return t}function a(e){for(var n=1;n=0||(s[t]=e[t]);return s}(e,n);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(s[t]=e[t])}return s}var l=o.createContext({}),c=function(e){var n=o.useContext(l),t=n;return e&&(t="function"==typeof e?e(n):a(a({},n),e)),t},h=function(e){var n=c(e.components);return o.createElement(l.Provider,{value:n},e.children)},u="mdxType",p={inlineCode:"code",wrapper:function(e){var n=e.children;return o.createElement(o.Fragment,{},n)}},d=o.forwardRef((function(e,n){var t=e.components,s=e.mdxType,r=e.originalType,l=e.parentName,h=i(e,["components","mdxType","originalType","parentName"]),u=c(t),d=s,m=u["".concat(l,".").concat(d)]||u[d]||p[d]||r;return t?o.createElement(m,a(a({ref:n},h),{},{components:t})):o.createElement(m,a({ref:n},h))}));function m(e,n){var t=arguments,s=n&&n.mdxType;if("string"==typeof e||s){var r=t.length,a=new Array(r);a[0]=d;var i={};for(var l in n)hasOwnProperty.call(n,l)&&(i[l]=n[l]);i.originalType=e,i[u]="string"==typeof e?e:s,a[1]=i;for(var c=2;c{t.r(n),t.d(n,{assets:()=>h,contentTitle:()=>l,default:()=>m,frontMatter:()=>i,metadata:()=>c,toc:()=>u});var o=t(9122),s=t(2501),r=(t(6393),t(158)),a=["components"],i={title:"rush.json"},l=void 0,c={unversionedId:"pages/configs/rush_json",id:"pages/configs/rush_json",title:"rush.json",description:"This is the template that rush init",source:"@site/docs/pages/configs/rush_json.md",sourceDirName:"pages/configs",slug:"/pages/configs/rush_json",permalink:"/pages/configs/rush_json",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/rush_json.md",tags:[],version:"current",frontMatter:{title:"rush.json"},sidebar:"docsSidebar",previous:{title:"pnpm-config.json",permalink:"/pages/configs/pnpm-config_json"},next:{title:"rush-plugin-manifest.json (experimental)",permalink:"/pages/configs/rush-plugin-manifest_json"}},h={},u=[],p={toc:u},d="wrapper";function m(e){var n=e.components,t=(0,s.Z)(e,a);return(0,r.kt)(d,(0,o.Z)({},p,t,{components:n,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"This is the template that ",(0,r.kt)("a",{parentName:"p",href:"/pages/commands/rush_init"},"rush init"),"\ngenerates for ",(0,r.kt)("strong",{parentName:"p"},"rush.json")," (in the repo root folder):"),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},"<","repo root",">","rush.json")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-js"},'/**\n * This is the main configuration file for Rush.\n * For full documentation, please see https://rushjs.io\n */\n{\n "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",\n\n /**\n * (Required) This specifies the version of the Rush engine to be used in this repo.\n * Rush\'s "version selector" feature ensures that the globally installed tool will\n * behave like this release, regardless of which version is installed globally.\n *\n * The common/scripts/install-run-rush.js automation script also uses this version.\n *\n * NOTE: If you upgrade to a new major version of Rush, you should replace the "v5"\n * path segment in the "$schema" field for all your Rush config files. This will ensure\n * correct error-underlining and tab-completion for editors such as VS Code.\n */\n "rushVersion": "5.110.0",\n\n /**\n * The next field selects which package manager should be installed and determines its version.\n * Rush installs its own local copy of the package manager to ensure that your build process\n * is fully isolated from whatever tools are present in the local environment.\n *\n * Specify one of: "pnpmVersion", "npmVersion", or "yarnVersion". See the Rush documentation\n * for details about these alternatives.\n */\n "pnpmVersion": "7.33.5",\n\n // "npmVersion": "6.14.15",\n // "yarnVersion": "1.9.4",\n\n /**\n * Older releases of the Node.js engine may be missing features required by your system.\n * Other releases may have bugs. In particular, the "latest" version will not be a\n * Long Term Support (LTS) version and is likely to have regressions.\n *\n * Specify a SemVer range to ensure developers use a Node.js version that is appropriate\n * for your repo.\n *\n * LTS schedule: https://nodejs.org/en/about/releases/\n * LTS versions: https://nodejs.org/en/download/releases/\n */\n "nodeSupportedVersionRange": ">=14.15.0 <15.0.0 || >=16.13.0 <17.0.0 || >=18.15.0 <19.0.0",\n\n /**\n * If the version check above fails, Rush will display a message showing the current\n * node version and the supported version range. You can use this setting to provide\n * additional instructions that will display below the warning, if there\'s a specific\n * tool or script you\'d like the user to use to get in line with the expected version.\n */\n // "nodeSupportedVersionInstructions": "Run \'nvs use\' to switch to the expected node version.",\n\n /**\n * Odd-numbered major versions of Node.js are experimental. Even-numbered releases\n * spend six months in a stabilization period before the first Long Term Support (LTS) version.\n * For example, 8.9.0 was the first LTS version of Node.js 8. Pre-LTS versions are not recommended\n * for production usage because they frequently have bugs. They may cause Rush itself\n * to malfunction.\n *\n * Rush normally prints a warning if it detects a pre-LTS Node.js version. If you are testing\n * pre-LTS versions in preparation for supporting the first LTS version, you can use this setting\n * to disable Rush\'s warning.\n */\n // "suppressNodeLtsWarning": false,\n\n /**\n * If you would like the version specifiers for your dependencies to be consistent, then\n * uncomment this line. This is effectively similar to running "rush check" before any\n * of the following commands:\n *\n * rush install, rush update, rush link, rush version, rush publish\n *\n * In some cases you may want this turned on, but need to allow certain packages to use a different\n * version. In those cases, you will need to add an entry to the "allowedAlternativeVersions"\n * section of the common-versions.json.\n */\n // "ensureConsistentVersions": true,\n\n /**\n * Large monorepos can become intimidating for newcomers if project folder paths don\'t follow\n * a consistent and recognizable pattern. When the system allows nested folder trees,\n * we\'ve found that teams will often use subfolders to create islands that isolate\n * their work from others ("shipping the org"). This hinders collaboration and code sharing.\n *\n * The Rush developers recommend a "category folder" model, where buildable project folders\n * must always be exactly two levels below the repo root. The parent folder acts as the category.\n * This provides a basic facility for grouping related projects (e.g. "apps", "libraries",\n * "tools", "prototypes") while still encouraging teams to organize their projects into\n * a unified taxonomy. Limiting to 2 levels seems very restrictive at first, but if you have\n * 20 categories and 20 projects in each category, this scheme can easily accommodate hundreds\n * of projects. In practice, you will find that the folder hierarchy needs to be rebalanced\n * occasionally, but if that\'s painful, it\'s a warning sign that your development style may\n * discourage refactoring. Reorganizing the categories should be an enlightening discussion\n * that brings people together, and maybe also identifies poor coding practices (e.g. file\n * references that reach into other project\'s folders without using Node.js module resolution).\n *\n * The defaults are projectFolderMinDepth=1 and projectFolderMaxDepth=2.\n *\n * To remove these restrictions, you could set projectFolderMinDepth=1\n * and set projectFolderMaxDepth to a large number.\n */\n // "projectFolderMinDepth": 2,\n // "projectFolderMaxDepth": 2,\n\n /**\n * Today the npmjs.com registry enforces fairly strict naming rules for packages, but in the early\n * days there was no standard and hardly any enforcement. A few large legacy projects are still using\n * nonstandard package names, and private registries sometimes allow it. Set "allowMostlyStandardPackageNames"\n * to true to relax Rush\'s enforcement of package names. This allows upper case letters and in the future may\n * relax other rules, however we want to minimize these exceptions. Many popular tools use certain punctuation\n * characters as delimiters, based on the assumption that they will never appear in a package name; thus if we relax\n * the rules too much it is likely to cause very confusing malfunctions.\n *\n * The default value is false.\n */\n // "allowMostlyStandardPackageNames": true,\n\n /**\n * This feature helps you to review and approve new packages before they are introduced\n * to your monorepo. For example, you may be concerned about licensing, code quality,\n * performance, or simply accumulating too many libraries with overlapping functionality.\n * The approvals are tracked in two config files "browser-approved-packages.json"\n * and "nonbrowser-approved-packages.json". See the Rush documentation for details.\n */\n // "approvedPackagesPolicy": {\n // /**\n // * The review categories allow you to say for example "This library is approved for usage\n // * in prototypes, but not in production code."\n // *\n // * Each project can be associated with one review category, by assigning the "reviewCategory" field\n // * in the "projects" section of rush.json. The approval is then recorded in the files\n // * "common/config/rush/browser-approved-packages.json" and "nonbrowser-approved-packages.json"\n // * which are automatically generated during "rush update".\n // *\n // * Designate categories with whatever granularity is appropriate for your review process,\n // * or you could just have a single category called "default".\n // */\n // "reviewCategories": [\n // // Some example categories:\n // "production", // projects that ship to production\n // "tools", // non-shipping projects that are part of the developer toolchain\n // "prototypes" // experiments that should mostly be ignored by the review process\n // ],\n //\n // /**\n // * A list of NPM package scopes that will be excluded from review.\n // * We recommend to exclude TypeScript typings (the "@types" scope), because\n // * if the underlying package was already approved, this would imply that the typings\n // * are also approved.\n // */\n // // "ignoredNpmScopes": ["@types"]\n // },\n\n /**\n * If you use Git as your version control system, this section has some additional\n * optional features you can use.\n */\n "gitPolicy": {\n /**\n * Work at a big company? Tired of finding Git commits at work with unprofessional Git\n * emails such as "beer-lover@my-college.edu"? Rush can validate people\'s Git email address\n * before they get started.\n *\n * Define a list of regular expressions describing allowable e-mail patterns for Git commits.\n * They are case-insensitive anchored JavaScript RegExps. Example: ".*@example\\.com"\n *\n * IMPORTANT: Because these are regular expressions encoded as JSON string literals,\n * RegExp escapes need two backslashes, and ordinary periods should be "\\\\.".\n */\n // "allowedEmailRegExps": [\n // "[^@]+@users\\\\.noreply\\\\.github\\\\.com",\n // "rush-bot@example\\\\.org"\n // ],\n\n /**\n * When Rush reports that the address is malformed, the notice can include an example\n * of a recommended email. Make sure it conforms to one of the allowedEmailRegExps\n * expressions.\n */\n // "sampleEmail": "example@users.noreply.github.com",\n\n /**\n * The commit message to use when committing changes during \'rush publish\'.\n *\n * For example, if you want to prevent these commits from triggering a CI build,\n * you might configure your system\'s trigger to look for a special string such as "[skip-ci]"\n * in the commit message, and then customize Rush\'s message to contain that string.\n */\n // "versionBumpCommitMessage": "Bump versions [skip ci]",\n\n /**\n * The commit message to use when committing changes during \'rush version\'.\n *\n * For example, if you want to prevent these commits from triggering a CI build,\n * you might configure your system\'s trigger to look for a special string such as "[skip-ci]"\n * in the commit message, and then customize Rush\'s message to contain that string.\n */\n // "changeLogUpdateCommitMessage": "Update changelogs [skip ci]",\n\n /**\n * The commit message to use when commiting changefiles during \'rush change --commit\'\n *\n * If no commit message is set it will default to \'Rush change\'\n */\n // "changefilesCommitMessage": "Rush change"\n },\n\n "repository": {\n /**\n * The URL of this Git repository, used by "rush change" to determine the base branch for your PR.\n *\n * The "rush change" command needs to determine which files are affected by your PR diff.\n * If you merged or cherry-picked commits from the main branch into your PR branch, those commits\n * should be excluded from this diff (since they belong to some other PR). In order to do that,\n * Rush needs to know where to find the base branch for your PR. This information cannot be\n * determined from Git alone, since the "pull request" feature is not a Git concept. Ideally\n * Rush would use a vendor-specific protocol to query the information from GitHub, Azure DevOps, etc.\n * But to keep things simple, "rush change" simply assumes that your PR is against the "main" branch\n * of the Git remote indicated by the repository.url setting in rush.json. If you are working in\n * a GitHub "fork" of the real repo, this setting will be different from the repository URL of your\n * your PR branch, and in this situation "rush change" will also automatically invoke "git fetch"\n * to retrieve the latest activity for the remote main branch.\n */\n // "url": "https://github.com/microsoft/rush-example",\n\n /**\n * The default branch name. This tells "rush change" which remote branch to compare against.\n * The default value is "main"\n */\n // "defaultBranch": "main",\n\n /**\n * The default remote. This tells "rush change" which remote to compare against if the remote URL is\n * not set or if a remote matching the provided remote URL is not found.\n */\n // "defaultRemote": "origin"\n },\n\n /**\n * Event hooks are customized script actions that Rush executes when specific events occur\n */\n "eventHooks": {\n /**\n * A list of shell commands to run before "rush install" or "rush update" starts installation\n */\n "preRushInstall": [\n // "common/scripts/pre-rush-install.js"\n ],\n\n /**\n * A list of shell commands to run after "rush install" or "rush update" finishes installation\n */\n "postRushInstall": [],\n\n /**\n * A list of shell commands to run before "rush build" or "rush rebuild" starts building\n */\n "preRushBuild": [],\n\n /**\n * A list of shell commands to run after "rush build" or "rush rebuild" finishes building\n */\n "postRushBuild": [],\n\n /**\n * A list of shell commands to run before the "rushx" command starts\n */\n "preRushx": [],\n\n /**\n * A list of shell commands to run after the "rushx" command finishes\n */\n "postRushx": []\n },\n\n /**\n * Installation variants allow you to maintain a parallel set of configuration files that can be\n * used to build the entire monorepo with an alternate set of dependencies. For example, suppose\n * you upgrade all your projects to use a new release of an important framework, but during a transition period\n * you intend to maintain compatibility with the old release. In this situation, you probably want your\n * CI validation to build the entire repo twice: once with the old release, and once with the new release.\n *\n * Rush "installation variants" correspond to sets of config files located under this folder:\n *\n * common/config/rush/variants/\n *\n * The variant folder can contain an alternate common-versions.json file. Its "preferredVersions" field can be used\n * to select older versions of dependencies (within a loose SemVer range specified in your package.json files).\n * To install a variant, run "rush install --variant ".\n *\n * For more details and instructions, see this article: https://rushjs.io/pages/advanced/installation_variants/\n */\n "variants": [\n // {\n // /**\n // * The folder name for this variant.\n // */\n // "variantName": "old-sdk",\n //\n // /**\n // * An informative description\n // */\n // "description": "Build this repo using the previous release of the SDK"\n // }\n ],\n\n /**\n * Rush can collect anonymous telemetry about everyday developer activity such as\n * success/failure of installs, builds, and other operations. You can use this to identify\n * problems with your toolchain or Rush itself. THIS TELEMETRY IS NOT SHARED WITH MICROSOFT.\n * It is written into JSON files in the common/temp folder. It\'s up to you to write scripts\n * that read these JSON files and do something with them. These scripts are typically registered\n * in the "eventHooks" section.\n */\n // "telemetryEnabled": false,\n\n /**\n * Allows creation of hotfix changes. This feature is experimental so it is disabled by default.\n * If this is set, \'rush change\' only allows a \'hotfix\' change type to be specified. This change type\n * will be used when publishing subsequent changes from the monorepo.\n */\n // "hotfixChangeEnabled": false,\n\n /**\n * This is an optional, but recommended, list of allowed tags that can be applied to Rush projects\n * using the "tags" setting in this file. This list is useful for preventing mistakes such as misspelling,\n * and it also provides a centralized place to document your tags. If "allowedProjectTags" list is\n * not specified, then any valid tag is allowed. A tag name must be one or more words\n * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,\n * ".", and "@" characters.\n */\n // "allowedProjectTags": [ "tools", "frontend-team", "1.0.0-release" ],\n\n /**\n * (Required) This is the inventory of projects to be managed by Rush.\n *\n * Rush does not automatically scan for projects using wildcards, for a few reasons:\n * 1. Depth-first scans are expensive, particularly when tools need to repeatedly collect the list.\n * 2. On a caching CI machine, scans can accidentally pick up files left behind from a previous build.\n * 3. It\'s useful to have a centralized inventory of all projects and their important metadata.\n */\n "projects": [\n // {\n // /**\n // * The NPM package name of the project (must match package.json)\n // */\n // "packageName": "my-app",\n //\n // /**\n // * The path to the project folder, relative to the rush.json config file.\n // */\n // "projectFolder": "apps/my-app",\n //\n // /**\n // * An optional category for usage in the "browser-approved-packages.json"\n // * and "nonbrowser-approved-packages.json" files. The value must be one of the\n // * strings from the "reviewCategories" defined above.\n // */\n // "reviewCategory": "production",\n //\n // /**\n // * A list of Rush project names that are to be installed from NPM\n // * instead of linking to the local project.\n // *\n // * If a project\'s package.json specifies a dependency that is another Rush project\n // * in the monorepo workspace, normally Rush will locally link its folder instead of\n // * installing from NPM. If you are using PNPM workspaces, this is indicated by\n // * a SemVer range such as "workspace:^1.2.3". To prevent mistakes, Rush reports\n // * an error if the "workspace:" protocol is missing.\n // *\n // * Locally linking ensures that regressions are caught as early as possible and is\n // * a key benefit of monorepos. However there are occasional situations where\n // * installing from NPM is needed. A classic example is a cyclic dependency.\n // * Imagine three Rush projects: "my-toolchain" depends on "my-tester", which depends\n // * on "my-library". Suppose that we add "my-toolchain" to the "devDependencies"\n // * of "my-library" so it can be built by our toolchain. This cycle creates\n // * a problem -- Rush can\'t build a project using a not-yet-built dependency.\n // * We can solve it by adding "my-toolchain" to the "decoupledLocalDependencies"\n // * of "my-library", so it builds using the last published release. Choose carefully\n // * which package to decouple; some choices are much easier to manage than others.\n // *\n // * (In older Rush releases, this setting was called "cyclicDependencyProjects".)\n // */\n // "decoupledLocalDependencies": [\n // // "my-toolchain"\n // ],\n //\n // /**\n // * If true, then this project will be ignored by the "rush check" command.\n // * The default value is false.\n // */\n // // "skipRushCheck": false,\n //\n // /**\n // * A flag indicating that changes to this project will be published to npm, which affects\n // * the Rush change and publish workflows. The default value is false.\n // * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.\n // */\n // // "shouldPublish": false,\n //\n // /**\n // * Facilitates postprocessing of a project\'s files prior to publishing.\n // *\n // * If specified, the "publishFolder" is the relative path to a subfolder of the project folder.\n // * The "rush publish" command will publish the subfolder instead of the project folder. The subfolder\n // * must contain its own package.json file, which is typically a build output.\n // */\n // // "publishFolder": "temp/publish",\n //\n // /**\n // * An optional version policy associated with the project. Version policies are defined\n // * in "version-policies.json" file. See the "rush publish" documentation for more info.\n // * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.\n // */\n // // "versionPolicyName": "",\n //\n // /**\n // * An optional set of custom tags that can be used to select this project. For example,\n // * adding "my-custom-tag" will allow this project to be selected by the\n // * command "rush list --only tag:my-custom-tag". The tag name must be one or more words\n // * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,\n // * ".", and "@" characters.\n // */\n // // "tags": [ "1.0.0-release", "frontend-team" ]\n // },\n //\n // {\n // "packageName": "my-controls",\n // "projectFolder": "libraries/my-controls",\n // "reviewCategory": "production",\n // "tags": [ "frontend-team" ]\n // },\n //\n // {\n // "packageName": "my-toolchain",\n // "projectFolder": "tools/my-toolchain",\n // "reviewCategory": "tools",\n // "tags": [ "tools" ]\n // }\n ]\n}\n')))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/5aaad5b7.c5d210b5.js b/assets/js/5aaad5b7.c5d210b5.js deleted file mode 100644 index 0d51cddd..00000000 --- a/assets/js/5aaad5b7.c5d210b5.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[5584],{158:(e,n,t)=>{t.d(n,{Zo:()=>h,kt:()=>m});var o=t(6393);function s(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function a(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);n&&(o=o.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,o)}return t}function r(e){for(var n=1;n=0||(s[t]=e[t]);return s}(e,n);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(s[t]=e[t])}return s}var l=o.createContext({}),c=function(e){var n=o.useContext(l),t=n;return e&&(t="function"==typeof e?e(n):r(r({},n),e)),t},h=function(e){var n=c(e.components);return o.createElement(l.Provider,{value:n},e.children)},u="mdxType",p={inlineCode:"code",wrapper:function(e){var n=e.children;return o.createElement(o.Fragment,{},n)}},d=o.forwardRef((function(e,n){var t=e.components,s=e.mdxType,a=e.originalType,l=e.parentName,h=i(e,["components","mdxType","originalType","parentName"]),u=c(t),d=s,m=u["".concat(l,".").concat(d)]||u[d]||p[d]||a;return t?o.createElement(m,r(r({ref:n},h),{},{components:t})):o.createElement(m,r({ref:n},h))}));function m(e,n){var t=arguments,s=n&&n.mdxType;if("string"==typeof e||s){var a=t.length,r=new Array(a);r[0]=d;var i={};for(var l in n)hasOwnProperty.call(n,l)&&(i[l]=n[l]);i.originalType=e,i[u]="string"==typeof e?e:s,r[1]=i;for(var c=2;c{t.r(n),t.d(n,{assets:()=>h,contentTitle:()=>l,default:()=>m,frontMatter:()=>i,metadata:()=>c,toc:()=>u});var o=t(9122),s=t(2501),a=(t(6393),t(158)),r=["components"],i={title:"rush.json"},l=void 0,c={unversionedId:"pages/configs/rush_json",id:"pages/configs/rush_json",title:"rush.json",description:"This is the template that rush init",source:"@site/docs/pages/configs/rush_json.md",sourceDirName:"pages/configs",slug:"/pages/configs/rush_json",permalink:"/pages/configs/rush_json",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/rush_json.md",tags:[],version:"current",frontMatter:{title:"rush.json"},sidebar:"docsSidebar",previous:{title:"pnpm-config.json",permalink:"/pages/configs/pnpm-config_json"},next:{title:"rush-plugin-manifest.json (experimental)",permalink:"/pages/configs/rush-plugin-manifest_json"}},h={},u=[],p={toc:u},d="wrapper";function m(e){var n=e.components,t=(0,s.Z)(e,r);return(0,a.kt)(d,(0,o.Z)({},p,t,{components:n,mdxType:"MDXLayout"}),(0,a.kt)("p",null,"This is the template that ",(0,a.kt)("a",{parentName:"p",href:"/pages/commands/rush_init"},"rush init"),"\ngenerates for ",(0,a.kt)("strong",{parentName:"p"},"rush.json")," (in the repo root folder):"),(0,a.kt)("p",null,(0,a.kt)("strong",{parentName:"p"},"<","repo root",">","rush.json")),(0,a.kt)("pre",null,(0,a.kt)("code",{parentName:"pre",className:"language-js"},'/**\n * This is the main configuration file for Rush.\n * For full documentation, please see https://rushjs.io\n */\n{\n "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",\n\n /**\n * (Required) This specifies the version of the Rush engine to be used in this repo.\n * Rush\'s "version selector" feature ensures that the globally installed tool will\n * behave like this release, regardless of which version is installed globally.\n *\n * The common/scripts/install-run-rush.js automation script also uses this version.\n *\n * NOTE: If you upgrade to a new major version of Rush, you should replace the "v5"\n * path segment in the "$schema" field for all your Rush config files. This will ensure\n * correct error-underlining and tab-completion for editors such as VS Code.\n */\n "rushVersion": "5.82.1",\n\n /**\n * The next field selects which package manager should be installed and determines its version.\n * Rush installs its own local copy of the package manager to ensure that your build process\n * is fully isolated from whatever tools are present in the local environment.\n *\n * Specify one of: "pnpmVersion", "npmVersion", or "yarnVersion". See the Rush documentation\n * for details about these alternatives.\n */\n "pnpmVersion": "6.7.1",\n\n // "npmVersion": "6.14.15",\n // "yarnVersion": "1.9.4",\n\n /**\n * Older releases of the Node.js engine may be missing features required by your system.\n * Other releases may have bugs. In particular, the "latest" version will not be a\n * Long Term Support (LTS) version and is likely to have regressions.\n *\n * Specify a SemVer range to ensure developers use a Node.js version that is appropriate\n * for your repo.\n *\n * LTS schedule: https://nodejs.org/en/about/releases/\n * LTS versions: https://nodejs.org/en/download/releases/\n */\n "nodeSupportedVersionRange": ">=12.13.0 <13.0.0 || >=14.15.0 <15.0.0 || >=16.13.0 <17.0.0",\n\n /**\n * Odd-numbered major versions of Node.js are experimental. Even-numbered releases\n * spend six months in a stabilization period before the first Long Term Support (LTS) version.\n * For example, 8.9.0 was the first LTS version of Node.js 8. Pre-LTS versions are not recommended\n * for production usage because they frequently have bugs. They may cause Rush itself\n * to malfunction.\n *\n * Rush normally prints a warning if it detects a pre-LTS Node.js version. If you are testing\n * pre-LTS versions in preparation for supporting the first LTS version, you can use this setting\n * to disable Rush\'s warning.\n */\n // "suppressNodeLtsWarning": false,\n\n /**\n * If you would like the version specifiers for your dependencies to be consistent, then\n * uncomment this line. This is effectively similar to running "rush check" before any\n * of the following commands:\n *\n * rush install, rush update, rush link, rush version, rush publish\n *\n * In some cases you may want this turned on, but need to allow certain packages to use a different\n * version. In those cases, you will need to add an entry to the "allowedAlternativeVersions"\n * section of the common-versions.json.\n */\n // "ensureConsistentVersions": true,\n\n /**\n * Large monorepos can become intimidating for newcomers if project folder paths don\'t follow\n * a consistent and recognizable pattern. When the system allows nested folder trees,\n * we\'ve found that teams will often use subfolders to create islands that isolate\n * their work from others ("shipping the org"). This hinders collaboration and code sharing.\n *\n * The Rush developers recommend a "category folder" model, where buildable project folders\n * must always be exactly two levels below the repo root. The parent folder acts as the category.\n * This provides a basic facility for grouping related projects (e.g. "apps", "libraries",\n * "tools", "prototypes") while still encouraging teams to organize their projects into\n * a unified taxonomy. Limiting to 2 levels seems very restrictive at first, but if you have\n * 20 categories and 20 projects in each category, this scheme can easily accommodate hundreds\n * of projects. In practice, you will find that the folder hierarchy needs to be rebalanced\n * occasionally, but if that\'s painful, it\'s a warning sign that your development style may\n * discourage refactoring. Reorganizing the categories should be an enlightening discussion\n * that brings people together, and maybe also identifies poor coding practices (e.g. file\n * references that reach into other project\'s folders without using Node.js module resolution).\n *\n * The defaults are projectFolderMinDepth=1 and projectFolderMaxDepth=2.\n *\n * To remove these restrictions, you could set projectFolderMinDepth=1\n * and set projectFolderMaxDepth to a large number.\n */\n // "projectFolderMinDepth": 2,\n // "projectFolderMaxDepth": 2,\n\n /**\n * Today the npmjs.com registry enforces fairly strict naming rules for packages, but in the early\n * days there was no standard and hardly any enforcement. A few large legacy projects are still using\n * nonstandard package names, and private registries sometimes allow it. Set "allowMostlyStandardPackageNames"\n * to true to relax Rush\'s enforcement of package names. This allows upper case letters and in the future may\n * relax other rules, however we want to minimize these exceptions. Many popular tools use certain punctuation\n * characters as delimiters, based on the assumption that they will never appear in a package name; thus if we relax\n * the rules too much it is likely to cause very confusing malfunctions.\n *\n * The default value is false.\n */\n // "allowMostlyStandardPackageNames": true,\n\n /**\n * This feature helps you to review and approve new packages before they are introduced\n * to your monorepo. For example, you may be concerned about licensing, code quality,\n * performance, or simply accumulating too many libraries with overlapping functionality.\n * The approvals are tracked in two config files "browser-approved-packages.json"\n * and "nonbrowser-approved-packages.json". See the Rush documentation for details.\n */\n // "approvedPackagesPolicy": {\n // /**\n // * The review categories allow you to say for example "This library is approved for usage\n // * in prototypes, but not in production code."\n // *\n // * Each project can be associated with one review category, by assigning the "reviewCategory" field\n // * in the "projects" section of rush.json. The approval is then recorded in the files\n // * "common/config/rush/browser-approved-packages.json" and "nonbrowser-approved-packages.json"\n // * which are automatically generated during "rush update".\n // *\n // * Designate categories with whatever granularity is appropriate for your review process,\n // * or you could just have a single category called "default".\n // */\n // "reviewCategories": [\n // // Some example categories:\n // "production", // projects that ship to production\n // "tools", // non-shipping projects that are part of the developer toolchain\n // "prototypes" // experiments that should mostly be ignored by the review process\n // ],\n //\n // /**\n // * A list of NPM package scopes that will be excluded from review.\n // * We recommend to exclude TypeScript typings (the "@types" scope), because\n // * if the underlying package was already approved, this would imply that the typings\n // * are also approved.\n // */\n // // "ignoredNpmScopes": ["@types"]\n // },\n\n /**\n * If you use Git as your version control system, this section has some additional\n * optional features you can use.\n */\n "gitPolicy": {\n /**\n * Work at a big company? Tired of finding Git commits at work with unprofessional Git\n * emails such as "beer-lover@my-college.edu"? Rush can validate people\'s Git email address\n * before they get started.\n *\n * Define a list of regular expressions describing allowable e-mail patterns for Git commits.\n * They are case-insensitive anchored JavaScript RegExps. Example: ".*@example\\.com"\n *\n * IMPORTANT: Because these are regular expressions encoded as JSON string literals,\n * RegExp escapes need two backslashes, and ordinary periods should be "\\\\.".\n */\n // "allowedEmailRegExps": [\n // "[^@]+@users\\\\.noreply\\\\.github\\\\.com",\n // "rush-bot@example\\\\.org"\n // ],\n\n /**\n * When Rush reports that the address is malformed, the notice can include an example\n * of a recommended email. Make sure it conforms to one of the allowedEmailRegExps\n * expressions.\n */\n // "sampleEmail": "example@users.noreply.github.com",\n\n /**\n * The commit message to use when committing changes during \'rush publish\'.\n *\n * For example, if you want to prevent these commits from triggering a CI build,\n * you might configure your system\'s trigger to look for a special string such as "[skip-ci]"\n * in the commit message, and then customize Rush\'s message to contain that string.\n */\n // "versionBumpCommitMessage": "Bump versions [skip ci]",\n\n /**\n * The commit message to use when committing changes during \'rush version\'.\n *\n * For example, if you want to prevent these commits from triggering a CI build,\n * you might configure your system\'s trigger to look for a special string such as "[skip-ci]"\n * in the commit message, and then customize Rush\'s message to contain that string.\n */\n // "changeLogUpdateCommitMessage": "Update changelogs [skip ci]",\n\n /**\n * The commit message to use when commiting changefiles during \'rush change --commit\'\n *\n * If no commit message is set it will default to \'Rush change\'\n */\n // "changefilesCommitMessage": "Rush change"\n },\n\n "repository": {\n /**\n * The URL of this Git repository, used by "rush change" to determine the base branch for your PR.\n *\n * The "rush change" command needs to determine which files are affected by your PR diff.\n * If you merged or cherry-picked commits from the main branch into your PR branch, those commits\n * should be excluded from this diff (since they belong to some other PR). In order to do that,\n * Rush needs to know where to find the base branch for your PR. This information cannot be\n * determined from Git alone, since the "pull request" feature is not a Git concept. Ideally\n * Rush would use a vendor-specific protocol to query the information from GitHub, Azure DevOps, etc.\n * But to keep things simple, "rush change" simply assumes that your PR is against the "main" branch\n * of the Git remote indicated by the repository.url setting in rush.json. If you are working in\n * a GitHub "fork" of the real repo, this setting will be different from the repository URL of your\n * your PR branch, and in this situation "rush change" will also automatically invoke "git fetch"\n * to retrieve the latest activity for the remote main branch.\n */\n // "url": "https://github.com/microsoft/rush-example",\n\n /**\n * The default branch name. This tells "rush change" which remote branch to compare against.\n * The default value is "main"\n */\n // "defaultBranch": "main",\n\n /**\n * The default remote. This tells "rush change" which remote to compare against if the remote URL is\n * not set or if a remote matching the provided remote URL is not found.\n */\n // "defaultRemote": "origin"\n },\n\n /**\n * Event hooks are customized script actions that Rush executes when specific events occur\n */\n "eventHooks": {\n /**\n * The list of shell commands to run before the Rush installation starts\n */\n "preRushInstall": [\n // "common/scripts/pre-rush-install.js"\n ],\n\n /**\n * The list of shell commands to run after the Rush installation finishes\n */\n "postRushInstall": [],\n\n /**\n * The list of shell commands to run before the Rush build command starts\n */\n "preRushBuild": [],\n\n /**\n * The list of shell commands to run after the Rush build command finishes\n */\n "postRushBuild": []\n },\n\n /**\n * Installation variants allow you to maintain a parallel set of configuration files that can be\n * used to build the entire monorepo with an alternate set of dependencies. For example, suppose\n * you upgrade all your projects to use a new release of an important framework, but during a transition period\n * you intend to maintain compatibility with the old release. In this situation, you probably want your\n * CI validation to build the entire repo twice: once with the old release, and once with the new release.\n *\n * Rush "installation variants" correspond to sets of config files located under this folder:\n *\n * common/config/rush/variants/\n *\n * The variant folder can contain an alternate common-versions.json file. Its "preferredVersions" field can be used\n * to select older versions of dependencies (within a loose SemVer range specified in your package.json files).\n * To install a variant, run "rush install --variant ".\n *\n * For more details and instructions, see this article: https://rushjs.io/pages/advanced/installation_variants/\n */\n "variants": [\n // {\n // /**\n // * The folder name for this variant.\n // */\n // "variantName": "old-sdk",\n //\n // /**\n // * An informative description\n // */\n // "description": "Build this repo using the previous release of the SDK"\n // }\n ],\n\n /**\n * Rush can collect anonymous telemetry about everyday developer activity such as\n * success/failure of installs, builds, and other operations. You can use this to identify\n * problems with your toolchain or Rush itself. THIS TELEMETRY IS NOT SHARED WITH MICROSOFT.\n * It is written into JSON files in the common/temp folder. It\'s up to you to write scripts\n * that read these JSON files and do something with them. These scripts are typically registered\n * in the "eventHooks" section.\n */\n // "telemetryEnabled": false,\n\n /**\n * Allows creation of hotfix changes. This feature is experimental so it is disabled by default.\n * If this is set, \'rush change\' only allows a \'hotfix\' change type to be specified. This change type\n * will be used when publishing subsequent changes from the monorepo.\n */\n // "hotfixChangeEnabled": false,\n\n /**\n * This is an optional, but recommended, list of allowed tags that can be applied to Rush projects\n * using the "tags" setting in this file. This list is useful for preventing mistakes such as misspelling,\n * and it also provides a centralized place to document your tags. If "allowedProjectTags" list is\n * not specified, then any valid tag is allowed. A tag name must be one or more words\n * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,\n * ".", and "@" characters.\n */\n // "allowedProjectTags": [ "tools", "frontend-team", "1.0.0-release" ],\n\n /**\n * (Required) This is the inventory of projects to be managed by Rush.\n *\n * Rush does not automatically scan for projects using wildcards, for a few reasons:\n * 1. Depth-first scans are expensive, particularly when tools need to repeatedly collect the list.\n * 2. On a caching CI machine, scans can accidentally pick up files left behind from a previous build.\n * 3. It\'s useful to have a centralized inventory of all projects and their important metadata.\n */\n "projects": [\n // {\n // /**\n // * The NPM package name of the project (must match package.json)\n // */\n // "packageName": "my-app",\n //\n // /**\n // * The path to the project folder, relative to the rush.json config file.\n // */\n // "projectFolder": "apps/my-app",\n //\n // /**\n // * An optional category for usage in the "browser-approved-packages.json"\n // * and "nonbrowser-approved-packages.json" files. The value must be one of the\n // * strings from the "reviewCategories" defined above.\n // */\n // "reviewCategory": "production",\n //\n // /**\n // * A list of Rush project names that are to be installed from NPM\n // * instead of linking to the local project.\n // *\n // * If a project\'s package.json specifies a dependency that is another Rush project\n // * in the monorepo workspace, normally Rush will locally link its folder instead of\n // * installing from NPM. If you are using PNPM workspaces, this is indicated by\n // * a SemVer range such as "workspace:^1.2.3". To prevent mistakes, Rush reports\n // * an error if the "workspace:" protocol is missing.\n // *\n // * Locally linking ensures that regressions are caught as early as possible and is\n // * a key benefit of monorepos. However there are occasional situations where\n // * installing from NPM is needed. A classic example is a cyclic dependency.\n // * Imagine three Rush projects: "my-toolchain" depends on "my-tester", which depends\n // * on "my-library". Suppose that we add "my-toolchain" to the "devDependencies"\n // * of "my-library" so it can be built by our toolchain. This cycle creates\n // * a problem -- Rush can\'t build a project using a not-yet-built dependency.\n // * We can solve it by adding "my-toolchain" to the "decoupledLocalDependencies"\n // * of "my-library", so it builds using the last published release. Choose carefully\n // * which package to decouple; some choices are much easier to manage than others.\n // *\n // * (In older Rush releases, this setting was called "cyclicDependencyProjects".)\n // */\n // "decoupledLocalDependencies": [\n // // "my-toolchain"\n // ],\n //\n // /**\n // * If true, then this project will be ignored by the "rush check" command.\n // * The default value is false.\n // */\n // // "skipRushCheck": false,\n //\n // /**\n // * A flag indicating that changes to this project will be published to npm, which affects\n // * the Rush change and publish workflows. The default value is false.\n // * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.\n // */\n // // "shouldPublish": false,\n //\n // /**\n // * Facilitates postprocessing of a project\'s files prior to publishing.\n // *\n // * If specified, the "publishFolder" is the relative path to a subfolder of the project folder.\n // * The "rush publish" command will publish the subfolder instead of the project folder. The subfolder\n // * must contain its own package.json file, which is typically a build output.\n // */\n // // "publishFolder": "temp/publish",\n //\n // /**\n // * An optional version policy associated with the project. Version policies are defined\n // * in "version-policies.json" file. See the "rush publish" documentation for more info.\n // * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.\n // */\n // // "versionPolicyName": "",\n //\n // /**\n // * An optional set of custom tags that can be used to select this project. For example,\n // * adding "my-custom-tag" will allow this project to be selected by the\n // * command "rush list --only tag:my-custom-tag". The tag name must be one or more words\n // * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,\n // * ".", and "@" characters.\n // */\n // // "tags": [ "1.0.0-release", "frontend-team" ]\n // },\n //\n // {\n // "packageName": "my-controls",\n // "projectFolder": "libraries/my-controls",\n // "reviewCategory": "production",\n // "tags": [ "frontend-team" ]\n // },\n //\n // {\n // "packageName": "my-toolchain",\n // "projectFolder": "tools/my-toolchain",\n // "reviewCategory": "tools",\n // "tags": [ "tools" ]\n // }\n ]\n}\n')))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/90ddd12c.1b808413.js b/assets/js/90ddd12c.1b808413.js deleted file mode 100644 index 7da17c71..00000000 --- a/assets/js/90ddd12c.1b808413.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[514],{158:(e,t,n)=>{n.d(t,{Zo:()=>p,kt:()=>_});var i=n(6393);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function r(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);t&&(i=i.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,i)}return n}function l(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);for(i=0;i=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var s=i.createContext({}),u=function(e){var t=i.useContext(s),n=t;return e&&(n="function"==typeof e?e(t):l(l({},t),e)),n},p=function(e){var t=u(e.components);return i.createElement(s.Provider,{value:t},e.children)},d="mdxType",h={inlineCode:"code",wrapper:function(e){var t=e.children;return i.createElement(i.Fragment,{},t)}},c=i.forwardRef((function(e,t){var n=e.components,a=e.mdxType,r=e.originalType,s=e.parentName,p=o(e,["components","mdxType","originalType","parentName"]),d=u(n),c=a,_=d["".concat(s,".").concat(c)]||d[c]||h[c]||r;return n?i.createElement(_,l(l({ref:t},p),{},{components:n})):i.createElement(_,l({ref:t},p))}));function _(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var r=n.length,l=new Array(r);l[0]=c;var o={};for(var s in t)hasOwnProperty.call(t,s)&&(o[s]=t[s]);o.originalType=e,o[d]="string"==typeof e?e:a,l[1]=o;for(var u=2;u{n.r(t),n.d(t,{assets:()=>p,contentTitle:()=>s,default:()=>_,frontMatter:()=>o,metadata:()=>u,toc:()=>d});var i=n(9122),a=n(2501),r=(n(6393),n(158)),l=["components"],o={title:"Environment variables"},s=void 0,u={unversionedId:"pages/configs/environment_vars",id:"pages/configs/environment_vars",title:"Environment variables",description:"The Rush tool's behavior can be customized using the shell environment variables described below:",source:"@site/docs/pages/configs/environment_vars.md",sourceDirName:"pages/configs",slug:"/pages/configs/environment_vars",permalink:"/pages/configs/environment_vars",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/environment_vars.md",tags:[],version:"current",frontMatter:{title:"Environment variables"},sidebar:"docsSidebar",previous:{title:"rush version",permalink:"/pages/commands/rush_version"},next:{title:".npmrc",permalink:"/pages/configs/npmrc"}},p={},d=[{value:"RUSH_ABSOLUTE_SYMLINKS",id:"rush_absolute_symlinks",level:2},{value:"RUSH_ALLOW_UNSUPPORTED_NODEJS",id:"rush_allow_unsupported_nodejs",level:2},{value:"RUSH_ALLOW_WARNINGS_IN_SUCCESSFUL_BUILD",id:"rush_allow_warnings_in_successful_build",level:2},{value:"RUSH_BUILD_CACHE_CREDENTIAL (EXPERIMENTAL)",id:"rush_build_cache_credential-experimental",level:2},{value:"RUSH_BUILD_CACHE_ENABLED (EXPERIMENTAL)",id:"rush_build_cache_enabled-experimental",level:2},{value:"RUSH_BUILD_CACHE_WRITE_ALLOWED (EXPERIMENTAL)",id:"rush_build_cache_write_allowed-experimental",level:2},{value:"RUSH_COBUILD_CONTEXT_ID (EXPERIMENTAL)",id:"rush_cobuild_context_id-experimental",level:2},{value:"RUSH_COBUILD_LEAF_PROJECT_LOG_ONLY_ALLOWED (EXPERIMENTAL)",id:"rush_cobuild_leaf_project_log_only_allowed-experimental",level:2},{value:"RUSH_COBUILD_RUNNER_ID (EXPERIMENTAL)",id:"rush_cobuild_runner_id-experimental",level:2},{value:"RUSH_DEPLOY_TARGET_FOLDER",id:"rush_deploy_target_folder",level:2},{value:"RUSH_GIT_BINARY_PATH",id:"rush_git_binary_path",level:2},{value:"RUSH_TAR_BINARY_PATH",id:"rush_tar_binary_path",level:2},{value:"RUSH_GLOBAL_FOLDER",id:"rush_global_folder",level:2},{value:"RUSH_INVOKED_FOLDER",id:"rush_invoked_folder",level:2},{value:"RUSH_PARALLELISM",id:"rush_parallelism",level:2},{value:"RUSH_PNPM_STORE_PATH",id:"rush_pnpm_store_path",level:2},{value:"RUSH_PREVIEW_VERSION",id:"rush_preview_version",level:2},{value:"RUSH_TEMP_FOLDER",id:"rush_temp_folder",level:2},{value:"RUSH_VARIANT",id:"rush_variant",level:2}],h={toc:d},c="wrapper";function _(e){var t=e.components,n=(0,a.Z)(e,l);return(0,r.kt)(c,(0,i.Z)({},h,n,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"The Rush tool's behavior can be customized using the shell environment variables described below:"),(0,r.kt)("h2",{id:"rush_absolute_symlinks"},"RUSH_ABSOLUTE_SYMLINKS"),(0,r.kt)("p",null,"If this variable is set to ",(0,r.kt)("inlineCode",{parentName:"p"},"1"),", Rush will create symlinks with absolute paths instead\nof relative paths. This can be necessary when a repository is moved during a build or\nif parts of a repository are moved into a sandbox."),(0,r.kt)("h2",{id:"rush_allow_unsupported_nodejs"},"RUSH_ALLOW_UNSUPPORTED_NODEJS"),(0,r.kt)("p",null,"If this variable is set to ",(0,r.kt)("inlineCode",{parentName:"p"},"1"),", Rush will not fail the build when running a version\nof Node that does not match the criteria specified in the ",(0,r.kt)("inlineCode",{parentName:"p"},"nodeSupportedVersionRange"),"\nfield from ",(0,r.kt)("strong",{parentName:"p"},"rush.json"),"."),(0,r.kt)("h2",{id:"rush_allow_warnings_in_successful_build"},"RUSH_ALLOW_WARNINGS_IN_SUCCESSFUL_BUILD"),(0,r.kt)("p",null,"Setting this environment variable overrides the value of ",(0,r.kt)("inlineCode",{parentName:"p"},"allowWarningsInSuccessfulBuild"),"\nin the ",(0,r.kt)("strong",{parentName:"p"},"command-line.json")," configuration file. Specify ",(0,r.kt)("inlineCode",{parentName:"p"},"1")," to allow warnings in a successful build,\nor ",(0,r.kt)("inlineCode",{parentName:"p"},"0")," to disallow them. (See the comments in the\n",(0,r.kt)("a",{parentName:"p",href:"/pages/configs/command-line_json"},"command-line.json"),"\nfile for more information)."),(0,r.kt)("h2",{id:"rush_build_cache_credential-experimental"},"RUSH_BUILD_CACHE_CREDENTIAL (EXPERIMENTAL)"),(0,r.kt)("p",null,"This environment variable is used by the experimental\n",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/build_cache"},"build cache"),"\nfeature."),(0,r.kt)("p",null,"Provides a credential for accessing the remote build cache, if configured. This credential overrides\nany cached credentials."),(0,r.kt)("p",null,"Setting this environment variable overrides whatever credential has been saved in the\nlocal cloud cache credentials using ",(0,r.kt)("inlineCode",{parentName:"p"},"rush update-cloud-credentials"),"."),(0,r.kt)("p",null,"If Azure Blob Storage is used to store cache entries, this must be a SAS token serialized as query parameters.\nSee ",(0,r.kt)("a",{parentName:"p",href:"https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview"},"this article")," for details\nabout SAS tokens."),(0,r.kt)("h2",{id:"rush_build_cache_enabled-experimental"},"RUSH_BUILD_CACHE_ENABLED (EXPERIMENTAL)"),(0,r.kt)("p",null,"This environment variable is used by the experimental\n",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/build_cache"},"build cache"),"\nfeature."),(0,r.kt)("p",null,"Setting this environment variable overrides the value of ",(0,r.kt)("inlineCode",{parentName:"p"},"buildCacheEnabled")," in the\n",(0,r.kt)("a",{parentName:"p",href:"/pages/configs/build-cache_json"},"build-cache.json"),"\nconfiguration file. Specify ",(0,r.kt)("inlineCode",{parentName:"p"},"1")," to enable the build cache or ",(0,r.kt)("inlineCode",{parentName:"p"},"0")," to disable it."),(0,r.kt)("p",null,"If set to ",(0,r.kt)("inlineCode",{parentName:"p"},"0"),", this is equivalent to passing the ",(0,r.kt)("inlineCode",{parentName:"p"},"--disable-build-cache")," flag."),(0,r.kt)("p",null,"If there is no build cache configured, then this environment variable is ignored."),(0,r.kt)("h2",{id:"rush_build_cache_write_allowed-experimental"},"RUSH_BUILD_CACHE_WRITE_ALLOWED (EXPERIMENTAL)"),(0,r.kt)("p",null,"This environment variable is used by the experimental\n",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/build_cache"},"build cache"),"\nfeature."),(0,r.kt)("p",null,"Overrides the value of ",(0,r.kt)("inlineCode",{parentName:"p"},"isCacheWriteAllowed")," in the ",(0,r.kt)("inlineCode",{parentName:"p"},"build-cache.json")," configuration file. The value of this\nenvironment variable must be ",(0,r.kt)("inlineCode",{parentName:"p"},"1")," (for true) or ",(0,r.kt)("inlineCode",{parentName:"p"},"0")," (for false). If there is no build cache configured, then\nthis environment variable is ignored."),(0,r.kt)("h2",{id:"rush_cobuild_context_id-experimental"},"RUSH_COBUILD_CONTEXT_ID (EXPERIMENTAL)"),(0,r.kt)("p",null,"Cobuild pipelines must define this environment variable; without it, Rush will perform a regular build without\nany cobuild logic. See the ",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/cobuilds"},"Cobuilds")," documentation for details."),(0,r.kt)("h2",{id:"rush_cobuild_leaf_project_log_only_allowed-experimental"},"RUSH_COBUILD_LEAF_PROJECT_LOG_ONLY_ALLOWED (EXPERIMENTAL)"),(0,r.kt)("p",null,'This is useful when you are using the cobuild feature but the Rush build cache is not able for\n"leaf" projects in the dependency graph. (For example, common libraries have build cache enabled,\nbut the apps the consume these libraries do now.) Normally, because we can\'t obtain such projects\nfrom the cache, all cobuild machines are forced to build that project. This is inefficient if our\ngoal is to validate whether the project builds successfully, not to deploy it.'),(0,r.kt)("p",null,"Setting ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_COBUILD_LEAF_PROJECT_LOG_ONLY_ALLOWED")," to ",(0,r.kt)("inlineCode",{parentName:"p"},"1"),' will cause Rush to use a special\n"log files only" caching for leaf projects with build cache disabled. The log files are cached\nand will be displayed on other cobuild machines, but the project contents are cached or restored.\nSee the ',(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/cobuilds"},"Cobuilds")," documentation for details."),(0,r.kt)("h2",{id:"rush_cobuild_runner_id-experimental"},"RUSH_COBUILD_RUNNER_ID (EXPERIMENTAL)"),(0,r.kt)("p",null,"This environment variable to uniquely identifies each cobuild machine. If this variable is not defined,\nRush will generate a random identifier on each run.\nSee the ",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/cobuilds"},"Cobuilds")," documentation for details."),(0,r.kt)("h2",{id:"rush_deploy_target_folder"},"RUSH_DEPLOY_TARGET_FOLDER"),(0,r.kt)("p",null,"This environment variable can be used to specify the ",(0,r.kt)("inlineCode",{parentName:"p"},"--target-folder")," parameter\nfor the ",(0,r.kt)("a",{parentName:"p",href:"/pages/commands/rush_deploy"},"rush deploy")," command."),(0,r.kt)("h2",{id:"rush_git_binary_path"},"RUSH_GIT_BINARY_PATH"),(0,r.kt)("p",null,"Explicitly specifies the path for the Git binary that is invoked by certain Rush operations."),(0,r.kt)("h2",{id:"rush_tar_binary_path"},"RUSH_TAR_BINARY_PATH"),(0,r.kt)("p",null,"Explicitly specifies the path for the ",(0,r.kt)("inlineCode",{parentName:"p"},"tar")," binary that is invoked by certain Rush operations."),(0,r.kt)("h2",{id:"rush_global_folder"},"RUSH_GLOBAL_FOLDER"),(0,r.kt)("p",null,"Overrides the location of the ",(0,r.kt)("inlineCode",{parentName:"p"},"~/.rush")," global folder where Rush stores temporary files."),(0,r.kt)("p",null,"Most of the temporary files created by Rush are stored separately for each monorepo working folder,\nto avoid issues of concurrency and compatibility between tool versions. However, a small set\nof files (e.g. installations of the ",(0,r.kt)("inlineCode",{parentName:"p"},"@microsoft/rush-lib")," engine and the package manager) are stored\nin a global folder to speed up installations. The default location is ",(0,r.kt)("inlineCode",{parentName:"p"},"~/.rush")," on POSIX-like\noperating systems or ",(0,r.kt)("inlineCode",{parentName:"p"},"C:\\Users\\YourName")," on Windows."),(0,r.kt)("p",null,"Use ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_GLOBAL_FOLDER")," to specify a different folder path. This is useful for example if a Windows\ngroup policy forbids executing scripts installed in a user's home directory."),(0,r.kt)("p",null,"(POSIX is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc.)"),(0,r.kt)("h2",{id:"rush_invoked_folder"},"RUSH_INVOKED_FOLDER"),(0,r.kt)("p",null,"When Rush executes shell scripts, it sometimes changes the working directory to be a project folder or\nthe repository root folder. The original working directory (where the Rush command was invoked) is assigned\nto the the child process's ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_INVOKED_FOLDER")," environment variable, in case it is needed by the script."),(0,r.kt)("p",null,"The ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_INVOKED_FOLDER")," variable is the same idea as the ",(0,r.kt)("inlineCode",{parentName:"p"},"INIT_CWD")," variable that package managers\nassign when they execute lifecycle scripts."),(0,r.kt)("h2",{id:"rush_parallelism"},"RUSH_PARALLELISM"),(0,r.kt)("p",null,"Specifies the maximum number of concurrent processes to launch during a build.\nFor more information, see the command-line help for the ",(0,r.kt)("inlineCode",{parentName:"p"},"--parallelism")," parameter for\n",(0,r.kt)("a",{parentName:"p",href:"/pages/commands/rush_build"},"rush build"),"."),(0,r.kt)("h2",{id:"rush_pnpm_store_path"},"RUSH_PNPM_STORE_PATH"),(0,r.kt)("p",null,"When using PNPM as the package manager, this variable can be used to configure the path that\nPNPM will use as the store directory."),(0,r.kt)("p",null,"If a relative path is used, then the store path will be resolved relative to the process's\ncurrent working directory. An absolute path is recommended."),(0,r.kt)("h2",{id:"rush_preview_version"},"RUSH_PREVIEW_VERSION"),(0,r.kt)("p",null,"This variable overrides the version of Rush that will be installed by\nthe version selector. The default value is determined by the ",(0,r.kt)("inlineCode",{parentName:"p"},"rushVersion"),"\nfield from ",(0,r.kt)("strong",{parentName:"p"},"rush.json"),"."),(0,r.kt)("p",null,"For example, if you want to try out a different release of Rush before upgrading your repo, you can assign\nthe variable like this:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},'# This is Bash\'s syntax; for Windows shell, change "export" to be "set"\nexport RUSH_PREVIEW_VERSION=5.0.0-dev.25\n\nrush install\n')),(0,r.kt)("h2",{id:"rush_temp_folder"},"RUSH_TEMP_FOLDER"),(0,r.kt)("p",null,"This variable overrides the temporary folder used by Rush.\nThe default value is ",(0,r.kt)("strong",{parentName:"p"},"common/temp")," under the repository root."),(0,r.kt)("p",null,"This environment variable is not compatible with workspace installs (",(0,r.kt)("inlineCode",{parentName:"p"},"useWorkspaces")," = true).\nIf attempting to move the PNPM store path, see the ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_PNPM_STORE_PATH")," environment variable."),(0,r.kt)("h2",{id:"rush_variant"},"RUSH_VARIANT"),(0,r.kt)("p",null,"This variable selects a specific installation variant for Rush to use when installing\nand linking package dependencies."),(0,r.kt)("p",null,"For more information about this feature, see\n",(0,r.kt)("a",{parentName:"p",href:"/pages/advanced/installation_variants"},"Installation Variants"),"."))}_.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/90ddd12c.2fd03b54.js b/assets/js/90ddd12c.2fd03b54.js new file mode 100644 index 00000000..ce14d135 --- /dev/null +++ b/assets/js/90ddd12c.2fd03b54.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[514],{158:(e,t,n)=>{n.d(t,{Zo:()=>p,kt:()=>_});var i=n(6393);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function r(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);t&&(i=i.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,i)}return n}function o(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);for(i=0;i=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var s=i.createContext({}),u=function(e){var t=i.useContext(s),n=t;return e&&(n="function"==typeof e?e(t):o(o({},t),e)),n},p=function(e){var t=u(e.components);return i.createElement(s.Provider,{value:t},e.children)},d="mdxType",h={inlineCode:"code",wrapper:function(e){var t=e.children;return i.createElement(i.Fragment,{},t)}},c=i.forwardRef((function(e,t){var n=e.components,a=e.mdxType,r=e.originalType,s=e.parentName,p=l(e,["components","mdxType","originalType","parentName"]),d=u(n),c=a,_=d["".concat(s,".").concat(c)]||d[c]||h[c]||r;return n?i.createElement(_,o(o({ref:t},p),{},{components:n})):i.createElement(_,o({ref:t},p))}));function _(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var r=n.length,o=new Array(r);o[0]=c;var l={};for(var s in t)hasOwnProperty.call(t,s)&&(l[s]=t[s]);l.originalType=e,l[d]="string"==typeof e?e:a,o[1]=l;for(var u=2;u{n.r(t),n.d(t,{assets:()=>p,contentTitle:()=>s,default:()=>_,frontMatter:()=>l,metadata:()=>u,toc:()=>d});var i=n(9122),a=n(2501),r=(n(6393),n(158)),o=["components"],l={title:"Environment variables"},s=void 0,u={unversionedId:"pages/configs/environment_vars",id:"pages/configs/environment_vars",title:"Environment variables",description:"The Rush tool's behavior can be customized using the shell environment variables described below:",source:"@site/docs/pages/configs/environment_vars.md",sourceDirName:"pages/configs",slug:"/pages/configs/environment_vars",permalink:"/pages/configs/environment_vars",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/environment_vars.md",tags:[],version:"current",frontMatter:{title:"Environment variables"},sidebar:"docsSidebar",previous:{title:"rush version",permalink:"/pages/commands/rush_version"},next:{title:".npmrc",permalink:"/pages/configs/npmrc"}},p={},d=[{value:"RUSH_ABSOLUTE_SYMLINKS",id:"rush_absolute_symlinks",level:2},{value:"RUSH_ALLOW_UNSUPPORTED_NODEJS",id:"rush_allow_unsupported_nodejs",level:2},{value:"RUSH_ALLOW_WARNINGS_IN_SUCCESSFUL_BUILD",id:"rush_allow_warnings_in_successful_build",level:2},{value:"RUSH_BUILD_CACHE_CREDENTIAL",id:"rush_build_cache_credential",level:2},{value:"RUSH_BUILD_CACHE_ENABLED",id:"rush_build_cache_enabled",level:2},{value:"RUSH_BUILD_CACHE_WRITE_ALLOWED",id:"rush_build_cache_write_allowed",level:2},{value:"RUSH_COBUILD_CONTEXT_ID (EXPERIMENTAL)",id:"rush_cobuild_context_id-experimental",level:2},{value:"RUSH_COBUILD_LEAF_PROJECT_LOG_ONLY_ALLOWED (EXPERIMENTAL)",id:"rush_cobuild_leaf_project_log_only_allowed-experimental",level:2},{value:"RUSH_COBUILD_RUNNER_ID (EXPERIMENTAL)",id:"rush_cobuild_runner_id-experimental",level:2},{value:"RUSH_DEPLOY_TARGET_FOLDER",id:"rush_deploy_target_folder",level:2},{value:"RUSH_GIT_BINARY_PATH",id:"rush_git_binary_path",level:2},{value:"RUSH_TAR_BINARY_PATH",id:"rush_tar_binary_path",level:2},{value:"RUSH_GLOBAL_FOLDER",id:"rush_global_folder",level:2},{value:"RUSH_INVOKED_ARGS",id:"rush_invoked_args",level:2},{value:"RUSH_INVOKED_FOLDER",id:"rush_invoked_folder",level:2},{value:"RUSH_PARALLELISM",id:"rush_parallelism",level:2},{value:"RUSH_PNPM_STORE_PATH",id:"rush_pnpm_store_path",level:2},{value:"RUSH_PREVIEW_VERSION",id:"rush_preview_version",level:2},{value:"RUSH_TEMP_FOLDER",id:"rush_temp_folder",level:2},{value:"RUSH_VARIANT",id:"rush_variant",level:2},{value:"RUSH_PNPM_VERIFY_STORE_INTEGRITY",id:"rush_pnpm_verify_store_integrity",level:2}],h={toc:d},c="wrapper";function _(e){var t=e.components,n=(0,a.Z)(e,o);return(0,r.kt)(c,(0,i.Z)({},h,n,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"The Rush tool's behavior can be customized using the shell environment variables described below:"),(0,r.kt)("h2",{id:"rush_absolute_symlinks"},"RUSH_ABSOLUTE_SYMLINKS"),(0,r.kt)("p",null,"If this variable is set to ",(0,r.kt)("inlineCode",{parentName:"p"},"1"),", Rush will create symlinks with absolute paths instead\nof relative paths. This can be necessary when a repository is moved during a build or\nif parts of a repository are moved into a sandbox."),(0,r.kt)("h2",{id:"rush_allow_unsupported_nodejs"},"RUSH_ALLOW_UNSUPPORTED_NODEJS"),(0,r.kt)("p",null,"If this variable is set to ",(0,r.kt)("inlineCode",{parentName:"p"},"1"),", Rush will not fail the build when running a version\nof Node that does not match the criteria specified in the ",(0,r.kt)("inlineCode",{parentName:"p"},"nodeSupportedVersionRange"),"\nfield from ",(0,r.kt)("strong",{parentName:"p"},"rush.json"),"."),(0,r.kt)("h2",{id:"rush_allow_warnings_in_successful_build"},"RUSH_ALLOW_WARNINGS_IN_SUCCESSFUL_BUILD"),(0,r.kt)("p",null,"Setting this environment variable overrides the value of ",(0,r.kt)("inlineCode",{parentName:"p"},"allowWarningsInSuccessfulBuild"),"\nin the ",(0,r.kt)("strong",{parentName:"p"},"command-line.json")," configuration file. Specify ",(0,r.kt)("inlineCode",{parentName:"p"},"1")," to allow warnings in a successful build,\nor ",(0,r.kt)("inlineCode",{parentName:"p"},"0")," to disallow them. (See the comments in the\n",(0,r.kt)("a",{parentName:"p",href:"/pages/configs/command-line_json"},"command-line.json"),"\nfile for more information)."),(0,r.kt)("h2",{id:"rush_build_cache_credential"},"RUSH_BUILD_CACHE_CREDENTIAL"),(0,r.kt)("p",null,"This environment variable is used by the\n",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/build_cache"},"build cache"),"\nfeature."),(0,r.kt)("p",null,"Provides a credential for accessing the remote build cache, if configured. This credential overrides\nany cached credentials."),(0,r.kt)("p",null,"Setting this environment variable overrides whatever credential has been saved in the\nlocal cloud cache credentials using ",(0,r.kt)("inlineCode",{parentName:"p"},"rush update-cloud-credentials"),"."),(0,r.kt)("p",null,"If Azure Blob Storage is used to store cache entries, this must be a SAS token serialized as query parameters.\nSee ",(0,r.kt)("a",{parentName:"p",href:"https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview"},"this article")," for details\nabout SAS tokens."),(0,r.kt)("h2",{id:"rush_build_cache_enabled"},"RUSH_BUILD_CACHE_ENABLED"),(0,r.kt)("p",null,"This environment variable is used by the\n",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/build_cache"},"build cache"),"\nfeature."),(0,r.kt)("p",null,"Setting this environment variable overrides the value of ",(0,r.kt)("inlineCode",{parentName:"p"},"buildCacheEnabled")," in the\n",(0,r.kt)("a",{parentName:"p",href:"/pages/configs/build-cache_json"},"build-cache.json"),"\nconfiguration file. Specify ",(0,r.kt)("inlineCode",{parentName:"p"},"1")," to enable the build cache or ",(0,r.kt)("inlineCode",{parentName:"p"},"0")," to disable it."),(0,r.kt)("p",null,"If set to ",(0,r.kt)("inlineCode",{parentName:"p"},"0"),", this is equivalent to passing the ",(0,r.kt)("inlineCode",{parentName:"p"},"--disable-build-cache")," flag."),(0,r.kt)("p",null,"If there is no build cache configured, then this environment variable is ignored."),(0,r.kt)("h2",{id:"rush_build_cache_write_allowed"},"RUSH_BUILD_CACHE_WRITE_ALLOWED"),(0,r.kt)("p",null,"This environment variable is used by the\n",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/build_cache"},"build cache"),"\nfeature."),(0,r.kt)("p",null,"Overrides the value of ",(0,r.kt)("inlineCode",{parentName:"p"},"isCacheWriteAllowed")," in the ",(0,r.kt)("inlineCode",{parentName:"p"},"build-cache.json")," configuration file. The value of this\nenvironment variable must be ",(0,r.kt)("inlineCode",{parentName:"p"},"1")," (for true) or ",(0,r.kt)("inlineCode",{parentName:"p"},"0")," (for false). If there is no build cache configured, then\nthis environment variable is ignored."),(0,r.kt)("h2",{id:"rush_cobuild_context_id-experimental"},"RUSH_COBUILD_CONTEXT_ID (EXPERIMENTAL)"),(0,r.kt)("p",null,"Cobuild pipelines must define this environment variable; without it, Rush will perform a regular build without\nany cobuild logic. See the ",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/cobuilds"},"Cobuilds")," documentation for details."),(0,r.kt)("h2",{id:"rush_cobuild_leaf_project_log_only_allowed-experimental"},"RUSH_COBUILD_LEAF_PROJECT_LOG_ONLY_ALLOWED (EXPERIMENTAL)"),(0,r.kt)("p",null,'This is useful when you are using the cobuild feature but the Rush build cache is not able for\n"leaf" projects in the dependency graph. (For example, common libraries have build cache enabled,\nbut the apps the consume these libraries do now.) Normally, because we can\'t obtain such projects\nfrom the cache, all cobuild machines are forced to build that project. This is inefficient if our\ngoal is to validate whether the project builds successfully, not to deploy it.'),(0,r.kt)("p",null,"Setting ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_COBUILD_LEAF_PROJECT_LOG_ONLY_ALLOWED")," to ",(0,r.kt)("inlineCode",{parentName:"p"},"1"),' will cause Rush to use a special\n"log files only" caching for leaf projects with build cache disabled. The log files are cached\nand will be displayed on other cobuild machines, but the project contents are cached or restored.\nSee the ',(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/cobuilds"},"Cobuilds")," documentation for details."),(0,r.kt)("h2",{id:"rush_cobuild_runner_id-experimental"},"RUSH_COBUILD_RUNNER_ID (EXPERIMENTAL)"),(0,r.kt)("p",null,"This environment variable to uniquely identifies each cobuild machine. If this variable is not defined,\nRush will generate a random identifier on each run.\nSee the ",(0,r.kt)("a",{parentName:"p",href:"/pages/maintainer/cobuilds"},"Cobuilds")," documentation for details."),(0,r.kt)("h2",{id:"rush_deploy_target_folder"},"RUSH_DEPLOY_TARGET_FOLDER"),(0,r.kt)("p",null,"This environment variable can be used to specify the ",(0,r.kt)("inlineCode",{parentName:"p"},"--target-folder")," parameter\nfor the ",(0,r.kt)("a",{parentName:"p",href:"/pages/commands/rush_deploy"},"rush deploy")," command."),(0,r.kt)("h2",{id:"rush_git_binary_path"},"RUSH_GIT_BINARY_PATH"),(0,r.kt)("p",null,"Explicitly specifies the path for the Git binary that is invoked by certain Rush operations."),(0,r.kt)("h2",{id:"rush_tar_binary_path"},"RUSH_TAR_BINARY_PATH"),(0,r.kt)("p",null,"Explicitly specifies the path for the ",(0,r.kt)("inlineCode",{parentName:"p"},"tar")," binary that is invoked by certain Rush operations."),(0,r.kt)("h2",{id:"rush_global_folder"},"RUSH_GLOBAL_FOLDER"),(0,r.kt)("p",null,"Overrides the location of the ",(0,r.kt)("inlineCode",{parentName:"p"},"~/.rush")," global folder where Rush stores temporary files."),(0,r.kt)("p",null,"Most of the temporary files created by Rush are stored separately for each monorepo working folder,\nto avoid issues of concurrency and compatibility between tool versions. However, a small set\nof files (e.g. installations of the ",(0,r.kt)("inlineCode",{parentName:"p"},"@microsoft/rush-lib")," engine and the package manager) are stored\nin a global folder to speed up installations. The default location is ",(0,r.kt)("inlineCode",{parentName:"p"},"~/.rush")," on POSIX-like\noperating systems or ",(0,r.kt)("inlineCode",{parentName:"p"},"C:\\Users\\YourName")," on Windows."),(0,r.kt)("p",null,"Use ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_GLOBAL_FOLDER")," to specify a different folder path. This is useful for example if a Windows\ngroup policy forbids executing scripts installed in a user's home directory."),(0,r.kt)("p",null,"(POSIX is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc.)"),(0,r.kt)("h2",{id:"rush_invoked_args"},"RUSH_INVOKED_ARGS"),(0,r.kt)("p",null,"When running a hook script, this environment variable communicates the original arguments\npassed to the ",(0,r.kt)("inlineCode",{parentName:"p"},"rush")," or ",(0,r.kt)("inlineCode",{parentName:"p"},"rushx")," command."),(0,r.kt)("p",null,"Unlike ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_INVOKED_FOLDER"),", the ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_INVOKED_ARGS")," variable is only available for hook scripts.\nOther lifecycle scripts should not make assumptions about Rush's command line syntax\nif Rush did not explicitly pass along command-line parameters to their process."),(0,r.kt)("h2",{id:"rush_invoked_folder"},"RUSH_INVOKED_FOLDER"),(0,r.kt)("p",null,"When Rush executes shell scripts, it sometimes changes the working directory to be a project folder or\nthe repository root folder. The original working directory (where the Rush command was invoked) is assigned\nto the the child process's ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_INVOKED_FOLDER")," environment variable, in case it is needed by the script."),(0,r.kt)("p",null,"The ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_INVOKED_FOLDER")," variable is the same idea as the ",(0,r.kt)("inlineCode",{parentName:"p"},"INIT_CWD")," variable that package managers\nassign when they execute lifecycle scripts."),(0,r.kt)("h2",{id:"rush_parallelism"},"RUSH_PARALLELISM"),(0,r.kt)("p",null,"Specifies the maximum number of concurrent processes to launch during a build.\nFor more information, see the command-line help for the ",(0,r.kt)("inlineCode",{parentName:"p"},"--parallelism")," parameter for\n",(0,r.kt)("a",{parentName:"p",href:"/pages/commands/rush_build"},"rush build"),"."),(0,r.kt)("h2",{id:"rush_pnpm_store_path"},"RUSH_PNPM_STORE_PATH"),(0,r.kt)("p",null,"When using PNPM as the package manager, this variable can be used to configure the path that\nPNPM will use as the store directory."),(0,r.kt)("p",null,"If a relative path is used, then the store path will be resolved relative to the process's\ncurrent working directory. An absolute path is recommended."),(0,r.kt)("h2",{id:"rush_preview_version"},"RUSH_PREVIEW_VERSION"),(0,r.kt)("p",null,"This variable overrides the version of Rush that will be installed by\nthe version selector. The default value is determined by the ",(0,r.kt)("inlineCode",{parentName:"p"},"rushVersion"),"\nfield from ",(0,r.kt)("strong",{parentName:"p"},"rush.json"),"."),(0,r.kt)("p",null,"For example, if you want to try out a different release of Rush before upgrading your repo, you can assign\nthe variable like this:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},'# This is Bash\'s syntax; for Windows shell, change "export" to be "set"\nexport RUSH_PREVIEW_VERSION=5.0.0-dev.25\n\nrush install\n')),(0,r.kt)("h2",{id:"rush_temp_folder"},"RUSH_TEMP_FOLDER"),(0,r.kt)("p",null,"This variable overrides the temporary folder used by Rush.\nThe default value is ",(0,r.kt)("strong",{parentName:"p"},"common/temp")," under the repository root."),(0,r.kt)("p",null,"This environment variable is not compatible with workspace installs (",(0,r.kt)("inlineCode",{parentName:"p"},"useWorkspaces")," = true).\nIf attempting to move the PNPM store path, see the ",(0,r.kt)("inlineCode",{parentName:"p"},"RUSH_PNPM_STORE_PATH")," environment variable."),(0,r.kt)("h2",{id:"rush_variant"},"RUSH_VARIANT"),(0,r.kt)("p",null,"This variable selects a specific installation variant for Rush to use when installing\nand linking package dependencies."),(0,r.kt)("p",null,"For more information about this feature, see\n",(0,r.kt)("a",{parentName:"p",href:"/pages/advanced/installation_variants"},"Installation Variants"),"."),(0,r.kt)("h2",{id:"rush_pnpm_verify_store_integrity"},"RUSH_PNPM_VERIFY_STORE_INTEGRITY"),(0,r.kt)("p",null,"When using PNPM as the package manager, this variable can be used to control whether or not PNPM\nvalidates the integrity of the PNPM store during installation. The value of this environment variable must be\n",(0,r.kt)("inlineCode",{parentName:"p"},"1")," (for true) or ",(0,r.kt)("inlineCode",{parentName:"p"},"0")," (for false). If not specified, defaults to the value in ",(0,r.kt)("strong",{parentName:"p"},".npmrc"),"."))}_.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/a6ae31b5.a0d943ef.js b/assets/js/a6ae31b5.a0d943ef.js new file mode 100644 index 00000000..09defa89 --- /dev/null +++ b/assets/js/a6ae31b5.a0d943ef.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[4973],{158:(e,n,t)=>{t.d(n,{Zo:()=>c,kt:()=>m});var s=t(6393);function i(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function o(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var s=Object.getOwnPropertySymbols(e);n&&(s=s.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,s)}return t}function a(e){for(var n=1;n=0||(i[t]=e[t]);return i}(e,n);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(s=0;s=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(i[t]=e[t])}return i}var p=s.createContext({}),l=function(e){var n=s.useContext(p),t=n;return e&&(t="function"==typeof e?e(n):a(a({},n),e)),t},c=function(e){var n=l(e.components);return s.createElement(p.Provider,{value:n},e.children)},d="mdxType",h={inlineCode:"code",wrapper:function(e){var n=e.children;return s.createElement(s.Fragment,{},n)}},u=s.forwardRef((function(e,n){var t=e.components,i=e.mdxType,o=e.originalType,p=e.parentName,c=r(e,["components","mdxType","originalType","parentName"]),d=l(t),u=i,m=d["".concat(p,".").concat(u)]||d[u]||h[u]||o;return t?s.createElement(m,a(a({ref:n},c),{},{components:t})):s.createElement(m,a({ref:n},c))}));function m(e,n){var t=arguments,i=n&&n.mdxType;if("string"==typeof e||i){var o=t.length,a=new Array(o);a[0]=u;var r={};for(var p in n)hasOwnProperty.call(n,p)&&(r[p]=n[p]);r.originalType=e,r[d]="string"==typeof e?e:i,a[1]=r;for(var l=2;l{t.r(n),t.d(n,{assets:()=>c,contentTitle:()=>p,default:()=>m,frontMatter:()=>r,metadata:()=>l,toc:()=>d});var s=t(9122),i=t(2501),o=(t(6393),t(158)),a=["components"],r={title:"pnpm-config.json"},p=void 0,l={unversionedId:"pages/configs/pnpm-config_json",id:"pages/configs/pnpm-config_json",title:"pnpm-config.json",description:"NOTE: This config file was introduced with Rush 5.79.0. Prior to that release,",source:"@site/docs/pages/configs/pnpm-config_json.md",sourceDirName:"pages/configs",slug:"/pages/configs/pnpm-config_json",permalink:"/pages/configs/pnpm-config_json",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/pnpm-config_json.md",tags:[],version:"current",frontMatter:{title:"pnpm-config.json"},sidebar:"docsSidebar",previous:{title:"experiments.json",permalink:"/pages/configs/experiments_json"},next:{title:"rush.json",permalink:"/pages/configs/rush_json"}},c={},d=[],h={toc:d},u="wrapper";function m(e){var n=e.components,t=(0,i.Z)(e,a);return(0,o.kt)(u,(0,s.Z)({},h,t,{components:n,mdxType:"MDXLayout"}),(0,o.kt)("blockquote",null,(0,o.kt)("p",{parentName:"blockquote"},"NOTE: This config file was introduced with Rush 5.79.0. Prior to that release,\nPNPM settings were instead stored in the ",(0,o.kt)("inlineCode",{parentName:"p"},'"pnpmOptions"')," section of ",(0,o.kt)("strong",{parentName:"p"},"rush.json"),".\nFor backwards compatibility, Rush 5 still accepts the ",(0,o.kt)("inlineCode",{parentName:"p"},'"pnpmOptions"')," section.\nIf you are upgrading an old monorepo, in order to access these new PNPM settings,\nyou must manually delete the ",(0,o.kt)("inlineCode",{parentName:"p"},'"pnpmOptions"')," setting from ",(0,o.kt)("strong",{parentName:"p"},"rush.json")," and\ncreate the ",(0,o.kt)("strong",{parentName:"p"},"pnpm-config.json")," file.")),(0,o.kt)("p",null,"This is the template that ",(0,o.kt)("a",{parentName:"p",href:"/pages/commands/rush_init"},"rush init"),"\ngenerates for ",(0,o.kt)("strong",{parentName:"p"},"pnpm-config.json"),":"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"common/config/rush/pnpm-config.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'/**\n * This configuration file provides settings specific to the PNPM package manager.\n * More documentation is available on the Rush website: https://rushjs.io\n */\n{\n "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/pnpm-config.schema.json",\n\n /**\n * If true, then `rush install` and `rush update` will use the PNPM workspaces feature\n * to perform the install, instead of the old model where Rush generated the symlinks\n * for each projects\'s node_modules folder.\n *\n * When using workspaces, Rush will generate a `common/temp/pnpm-workspace.yaml` file referencing\n * all local projects to install. Rush will also generate a `.pnpmfile.cjs` shim which implements\n * Rush-specific features such as preferred versions. The user\'s `common/config/rush/.pnpmfile.cjs`\n * is invoked by the shim.\n *\n * This option is strongly recommended. The default value is false.\n */\n "useWorkspaces": true,\n\n /**\n * This setting determines how PNPM chooses version numbers during `rush update`.\n * For example, suppose `lib-x@3.0.0` depends on `"lib-y": "^1.2.3"` whose latest major\n * releases are `1.8.9` and `2.3.4`. The resolution mode `lowest-direct` might choose\n * `lib-y@1.2.3`, wheres `highest` will choose 1.8.9, and `time-based` will pick the\n * highest compatible version at the time when `lib-x@3.0.0` itself was published (ensuring\n * that the version could have been tested by the maintainer of "lib-x"). For local workspace\n * projects, `time-based` instead works like `lowest-direct`, avoiding upgrades unless\n * they are explicitly requested. Although `time-based` is the most robust option, it may be\n * slightly slower with registries such as npmjs.com that have not implemented an optimization.\n *\n * IMPORTANT: Be aware that PNPM 8.0.0 initially defaulted to `lowest-direct` instead of\n * `highest`, but PNPM reverted this decision in 8.6.12 because it caused confusion for users.\n * Rush version 5.106.0 and newer avoids this confusion by consistently defaulting to\n * `highest` when `resolutionMode` is not explicitly set in pnpm-config.json or .npmrc,\n * regardless of your PNPM version.\n *\n * PNPM documentation: https://pnpm.io/npmrc#resolution-mode\n *\n * Possible values are: `highest`, `time-based`, and `lowest-direct`.\n * The default is `highest`.\n */\n // "resolutionMode": "time-based",\n\n /**\n * This setting determines whether PNPM will automatically install (non-optional)\n * missing peer dependencies instead of reporting an error. Doing so conveniently\n * avoids the need to specify peer versions in package.json, but in a large monorepo\n * this often creates worse problems. The reason is that peer dependency behavior\n * is inherently complicated, and it is easier to troubleshoot consequences of an explicit\n * version than an invisible heuristic. The original NPM RFC discussion pointed out\n * some other problems with this feature: https://github.com/npm/rfcs/pull/43\n\n * IMPORTANT: Without Rush, the setting defaults to true for PNPM 8 and newer; however,\n * as of Rush version 5.109.0 the default is always false unless `autoInstallPeers`\n * is specified in pnpm-config.json or .npmrc, regardless of your PNPM version.\n\n * PNPM documentation: https://pnpm.io/npmrc#auto-install-peers\n\n * The default value is false.\n */\n // "autoInstallPeers": false,\n\n /**\n * If true, then Rush will add the `--strict-peer-dependencies` command-line parameter when\n * invoking PNPM. This causes `rush update` to fail if there are unsatisfied peer dependencies,\n * which is an invalid state that can cause build failures or incompatible dependency versions.\n * (For historical reasons, JavaScript package managers generally do not treat this invalid\n * state as an error.)\n *\n * PNPM documentation: https://pnpm.io/npmrc#strict-peer-dependencies\n *\n * The default value is false to avoid legacy compatibility issues.\n * It is strongly recommended to set `strictPeerDependencies=true`.\n */\n // "strictPeerDependencies": true,\n\n /**\n * Environment variables that will be provided to PNPM.\n */\n // "environmentVariables": {\n // "NODE_OPTIONS": {\n // "value": "--max-old-space-size=4096",\n // "override": false\n // }\n // },\n\n /**\n * Specifies the location of the PNPM store. There are two possible values:\n *\n * - `local` - use the `pnpm-store` folder in the current configured temp folder:\n * `common/temp/pnpm-store` by default.\n * - `global` - use PNPM\'s global store, which has the benefit of being shared\n * across multiple repo folders, but the disadvantage of less isolation for builds\n * (for example, bugs or incompatibilities when two repos use different releases of PNPM)\n *\n * In both cases, the store path can be overridden by the environment variable `RUSH_PNPM_STORE_PATH`.\n *\n * The default value is `local`.\n */\n // "pnpmStore": "global",\n\n /**\n * If true, then `rush install` will report an error if manual modifications\n * were made to the PNPM shrinkwrap file without running `rush update` afterwards.\n *\n * This feature protects against accidental inconsistencies that may be introduced\n * if the PNPM shrinkwrap file (`pnpm-lock.yaml`) is manually edited. When this\n * feature is enabled, `rush update` will append a hash to the file as a YAML comment,\n * and then `rush update` and `rush install` will validate the hash. Note that this\n * does not prohibit manual modifications, but merely requires `rush update` be run\n * afterwards, ensuring that PNPM can report or repair any potential inconsistencies.\n *\n * To temporarily disable this validation when invoking `rush install`, use the\n * `--bypass-policy` command-line parameter.\n *\n * The default value is false.\n */\n // "preventManualShrinkwrapChanges": true,\n\n /**\n * The "globalOverrides" setting provides a simple mechanism for overriding version selections\n * for all dependencies of all projects in the monorepo workspace. The settings are copied\n * into the `pnpm.overrides` field of the `common/temp/package.json` file that is generated\n * by Rush during installation.\n *\n * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by\n * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,\n * and `globalOverrides` has lowest precedence.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmoverrides\n */\n "globalOverrides": {\n // "example1": "^1.0.0",\n // "example2": "npm:@company/example2@^1.0.0"\n },\n\n /**\n * The `globalPeerDependencyRules` setting provides various settings for suppressing validation errors\n * that are reported during installation with `strictPeerDependencies=true`. The settings are copied\n * into the `pnpm.peerDependencyRules` field of the `common/temp/package.json` file that is generated\n * by Rush during installation.\n *\n * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by\n * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,\n * and `globalOverrides` has lowest precedence.\n *\n * https://pnpm.io/package_json#pnpmpeerdependencyrules\n */\n "globalPeerDependencyRules": {\n // "ignoreMissing": ["@eslint/*"],\n // "allowedVersions": { "react": "17" },\n // "allowAny": ["@babel/*"]\n },\n\n /**\n * The `globalPackageExtension` setting provides a way to patch arbitrary package.json fields\n * for any PNPM dependency of the monorepo. The settings are copied into the `pnpm.packageExtensions`\n * field of the `common/temp/package.json` file that is generated by Rush during installation.\n * The `globalPackageExtension` setting has similar capabilities as `.pnpmfile.cjs` but without\n * the downsides of an executable script (nondeterminism, unreliable caching, performance concerns).\n *\n * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by\n * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,\n * and `globalOverrides` has lowest precedence.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmpackageextensions\n */\n "globalPackageExtensions": {\n // "fork-ts-checker-webpack-plugin": {\n // "dependencies": {\n // "@babel/core": "1"\n // },\n // "peerDependencies": {\n // "eslint": ">= 6"\n // },\n // "peerDependenciesMeta": {\n // "eslint": {\n // "optional": true\n // }\n // }\n // }\n },\n\n /**\n * The `globalNeverBuiltDependencies` setting suppresses the `preinstall`, `install`, and `postinstall`\n * lifecycle events for the specified NPM dependencies. This is useful for scripts with poor practices\n * such as downloading large binaries without retries or attempting to invoke OS tools such as\n * a C++ compiler. (PNPM\'s terminology refers to these lifecycle events as "building" a package;\n * it has nothing to do with build system operations such as `rush build` or `rushx build`.)\n * The settings are copied into the `pnpm.neverBuiltDependencies` field of the `common/temp/package.json`\n * file that is generated by Rush during installation.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmneverbuiltdependencies\n */\n "globalNeverBuiltDependencies": [\n // "fsevents"\n ],\n\n /**\n * The `globalAllowedDeprecatedVersions` setting suppresses installation warnings for package\n * versions that the NPM registry reports as being deprecated. This is useful if the\n * deprecated package is an indirect dependency of an external package that has not released a fix.\n * The settings are copied into the `pnpm.allowedDeprecatedVersions` field of the `common/temp/package.json`\n * file that is generated by Rush during installation.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmalloweddeprecatedversions\n *\n * If you are working to eliminate a deprecated version, it\'s better to specify `allowedDeprecatedVersions`\n * in the package.json file for individual Rush projects.\n */\n "globalAllowedDeprecatedVersions": {\n // "request": "*"\n },\n\n\n /**\n * (THIS FIELD IS MACHINE GENERATED) The "globalPatchedDependencies" field is updated automatically\n * by the `rush-pnpm patch-commit` command. It is a dictionary, where the key is an NPM package name\n * and exact version, and the value is a relative path to the associated patch file.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmpatcheddependencies\n */\n "globalPatchedDependencies": { },\n\n /**\n * (USE AT YOUR OWN RISK) This is a free-form property bag that will be copied into\n * the `common/temp/package.json` file that is generated by Rush during installation.\n * This provides a way to experiment with new PNPM features. These settings will override\n * any other Rush configuration associated with a given JSON field except for `.pnpmfile.cjs`.\n *\n * USAGE OF THIS SETTING IS NOT SUPPORTED BY THE RUSH MAINTAINERS AND MAY CAUSE RUSH\n * TO MALFUNCTION. If you encounter a missing PNPM setting that you believe should\n * be supported, please create a GitHub issue or PR. Note that Rush does not aim to\n * support every possible PNPM setting, but rather to promote a battle-tested installation\n * strategy that is known to provide a good experience for large teams with lots of projects.\n */\n "unsupportedPackageJsonSettings": {\n // "dependencies": {\n // "not-a-good-practice": "*"\n // },\n // "scripts": {\n // "do-something": "echo Also not a good practice"\n // },\n // "pnpm": { "futurePnpmFeature": true }\n }\n}\n')))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/a6ae31b5.e0eb258f.js b/assets/js/a6ae31b5.e0eb258f.js deleted file mode 100644 index fbf31936..00000000 --- a/assets/js/a6ae31b5.e0eb258f.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[4973],{158:(e,n,t)=>{t.d(n,{Zo:()=>c,kt:()=>m});var s=t(6393);function i(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function o(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var s=Object.getOwnPropertySymbols(e);n&&(s=s.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,s)}return t}function a(e){for(var n=1;n=0||(i[t]=e[t]);return i}(e,n);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(s=0;s=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(i[t]=e[t])}return i}var p=s.createContext({}),l=function(e){var n=s.useContext(p),t=n;return e&&(t="function"==typeof e?e(n):a(a({},n),e)),t},c=function(e){var n=l(e.components);return s.createElement(p.Provider,{value:n},e.children)},d="mdxType",h={inlineCode:"code",wrapper:function(e){var n=e.children;return s.createElement(s.Fragment,{},n)}},u=s.forwardRef((function(e,n){var t=e.components,i=e.mdxType,o=e.originalType,p=e.parentName,c=r(e,["components","mdxType","originalType","parentName"]),d=l(t),u=i,m=d["".concat(p,".").concat(u)]||d[u]||h[u]||o;return t?s.createElement(m,a(a({ref:n},c),{},{components:t})):s.createElement(m,a({ref:n},c))}));function m(e,n){var t=arguments,i=n&&n.mdxType;if("string"==typeof e||i){var o=t.length,a=new Array(o);a[0]=u;var r={};for(var p in n)hasOwnProperty.call(n,p)&&(r[p]=n[p]);r.originalType=e,r[d]="string"==typeof e?e:i,a[1]=r;for(var l=2;l{t.r(n),t.d(n,{assets:()=>c,contentTitle:()=>p,default:()=>m,frontMatter:()=>r,metadata:()=>l,toc:()=>d});var s=t(9122),i=t(2501),o=(t(6393),t(158)),a=["components"],r={title:"pnpm-config.json"},p=void 0,l={unversionedId:"pages/configs/pnpm-config_json",id:"pages/configs/pnpm-config_json",title:"pnpm-config.json",description:"NOTE: This config file was introduced with Rush 5.79.0. Prior to that release,",source:"@site/docs/pages/configs/pnpm-config_json.md",sourceDirName:"pages/configs",slug:"/pages/configs/pnpm-config_json",permalink:"/pages/configs/pnpm-config_json",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/pnpm-config_json.md",tags:[],version:"current",frontMatter:{title:"pnpm-config.json"},sidebar:"docsSidebar",previous:{title:"experiments.json",permalink:"/pages/configs/experiments_json"},next:{title:"rush.json",permalink:"/pages/configs/rush_json"}},c={},d=[],h={toc:d},u="wrapper";function m(e){var n=e.components,t=(0,i.Z)(e,a);return(0,o.kt)(u,(0,s.Z)({},h,t,{components:n,mdxType:"MDXLayout"}),(0,o.kt)("blockquote",null,(0,o.kt)("p",{parentName:"blockquote"},"NOTE: This config file was introduced with Rush 5.79.0. Prior to that release,\nPNPM settings were instead stored in the ",(0,o.kt)("inlineCode",{parentName:"p"},'"pnpmOptions"')," section of ",(0,o.kt)("strong",{parentName:"p"},"rush.json"),".\nFor backwards compatibility, Rush 5 still accepts the ",(0,o.kt)("inlineCode",{parentName:"p"},'"pnpmOptions"')," section.\nIf you are upgrading an old monorepo, in order to access these new PNPM settings,\nyou must manually delete the ",(0,o.kt)("inlineCode",{parentName:"p"},'"pnpmOptions"')," setting from ",(0,o.kt)("strong",{parentName:"p"},"rush.json")," and\ncreate the ",(0,o.kt)("strong",{parentName:"p"},"pnpm-config.json")," file.")),(0,o.kt)("p",null,"This is the template that ",(0,o.kt)("a",{parentName:"p",href:"/pages/commands/rush_init"},"rush init"),"\ngenerates for ",(0,o.kt)("strong",{parentName:"p"},"pnpm-config.json"),":"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"common/config/rush/pnpm-config.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'/**\n * This configuration file provides settings specific to the PNPM package manager.\n * More documentation is available on the Rush website: https://rushjs.io\n */\n{\n "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/pnpm-config.schema.json",\n\n /**\n * If true, then `rush install` and `rush update` will use the PNPM workspaces feature\n * to perform the install, instead of the old model where Rush generated the symlinks\n * for each projects\'s node_modules folder.\n *\n * When using workspaces, Rush will generate a `common/temp/pnpm-workspace.yaml` file referencing\n * all local projects to install. Rush will also generate a `.pnpmfile.cjs` shim which implements\n * Rush-specific features such as preferred versions. The user\'s `common/config/rush/.pnpmfile.cjs`\n * is invoked by the shim.\n *\n * This option is strongly recommended. The default value is false.\n */\n "useWorkspaces": true,\n\n /**\n * This setting determines how PNPM chooses version numbers during `rush update`.\n * For example, suppose `lib-x@3.0.0` depends on `"lib-y": "^1.2.3"` whose latest major\n * releases are `1.8.9` and `2.3.4`. The resolution mode `lowest-direct` might choose\n * `lib-y@1.2.3`, wheres `highest` will choose 1.8.9, and `time-based` will pick the\n * highest compatible version at the time when `lib-x@3.0.0` itself was published (ensuring\n * that the version could have been tested by the maintainer of "lib-x"). For local workspace\n * projects, `time-based` instead works like `lowest-direct`, avoiding upgrades unless\n * they are explicitly requested. Although `time-based` is the most robust option, it may be\n * slightly slower with registries such as npmjs.com that have not implemented an optimization.\n *\n * IMPORTANT: Be aware that PNPM 8.0.0 initially defaulted to `lowest-direct` instead of\n * `highest`, but PNPM reverted this decision in 8.6.12 because it caused confusion for users.\n * Rush version 5.106.0 and newer avoids this confusion by consistently defaulting to\n * `highest` when `resolutionMode` is not explicitly set in pnpm-config.json or .npmrc,\n * regardless of your PNPM version.\n *\n * PNPM documentation: https://pnpm.io/npmrc#resolution-mode\n *\n * Possible values are: `highest`, `time-based`, and `lowest-direct`.\n * The default is `highest`.\n */\n // "resolutionMode": "time-based",\n\n /**\n * If true, then Rush will add the `--strict-peer-dependencies` command-line parameter when\n * invoking PNPM. This causes `rush update` to fail if there are unsatisfied peer dependencies,\n * which is an invalid state that can cause build failures or incompatible dependency versions.\n * (For historical reasons, JavaScript package managers generally do not treat this invalid\n * state as an error.)\n *\n * PNPM documentation: https://pnpm.io/npmrc#strict-peer-dependencies\n *\n * The default value is false to avoid legacy compatibility issues.\n * It is strongly recommended to set `strictPeerDependencies=true`.\n */\n // "strictPeerDependencies": true,\n\n /**\n * Environment variables that will be provided to PNPM.\n */\n // "environmentVariables": {\n // "NODE_OPTIONS": {\n // "value": "--max-old-space-size=4096",\n // "override": false\n // }\n // },\n\n /**\n * Specifies the location of the PNPM store. There are two possible values:\n *\n * - `local` - use the `pnpm-store` folder in the current configured temp folder:\n * `common/temp/pnpm-store` by default.\n * - `global` - use PNPM\'s global store, which has the benefit of being shared\n * across multiple repo folders, but the disadvantage of less isolation for builds\n * (for example, bugs or incompatibilities when two repos use different releases of PNPM)\n *\n * In both cases, the store path can be overridden by the environment variable `RUSH_PNPM_STORE_PATH`.\n *\n * The default value is `local`.\n */\n // "pnpmStore": "global",\n\n /**\n * If true, then `rush install` will report an error if manual modifications\n * were made to the PNPM shrinkwrap file without running `rush update` afterwards.\n *\n * This feature protects against accidental inconsistencies that may be introduced\n * if the PNPM shrinkwrap file (`pnpm-lock.yaml`) is manually edited. When this\n * feature is enabled, `rush update` will append a hash to the file as a YAML comment,\n * and then `rush update` and `rush install` will validate the hash. Note that this\n * does not prohibit manual modifications, but merely requires `rush update` be run\n * afterwards, ensuring that PNPM can report or repair any potential inconsistencies.\n *\n * To temporarily disable this validation when invoking `rush install`, use the\n * `--bypass-policy` command-line parameter.\n *\n * The default value is false.\n */\n // "preventManualShrinkwrapChanges": true,\n\n /**\n * The "globalOverrides" setting provides a simple mechanism for overriding version selections\n * for all dependencies of all projects in the monorepo workspace. The settings are copied\n * into the `pnpm.overrides` field of the `common/temp/package.json` file that is generated\n * by Rush during installation.\n *\n * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by\n * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,\n * and `globalOverrides` has lowest precedence.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmoverrides\n */\n "globalOverrides": {\n // "example1": "^1.0.0",\n // "example2": "npm:@company/example2@^1.0.0"\n },\n\n /**\n * The `globalPeerDependencyRules` setting provides various settings for suppressing validation errors\n * that are reported during installation with `strictPeerDependencies=true`. The settings are copied\n * into the `pnpm.peerDependencyRules` field of the `common/temp/package.json` file that is generated\n * by Rush during installation.\n *\n * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by\n * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,\n * and `globalOverrides` has lowest precedence.\n *\n * https://pnpm.io/package_json#pnpmpeerdependencyrules\n */\n "globalPeerDependencyRules": {\n // "ignoreMissing": ["@eslint/*"],\n // "allowedVersions": { "react": "17" },\n // "allowAny": ["@babel/*"]\n },\n\n /**\n * The `globalPackageExtension` setting provides a way to patch arbitrary package.json fields\n * for any PNPM dependency of the monorepo. The settings are copied into the `pnpm.packageExtensions`\n * field of the `common/temp/package.json` file that is generated by Rush during installation.\n * The `globalPackageExtension` setting has similar capabilities as `.pnpmfile.cjs` but without\n * the downsides of an executable script (nondeterminism, unreliable caching, performance concerns).\n *\n * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by\n * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,\n * and `globalOverrides` has lowest precedence.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmpackageextensions\n */\n "globalPackageExtensions": {\n // "fork-ts-checker-webpack-plugin": {\n // "dependencies": {\n // "@babel/core": "1"\n // },\n // "peerDependencies": {\n // "eslint": ">= 6"\n // },\n // "peerDependenciesMeta": {\n // "eslint": {\n // "optional": true\n // }\n // }\n // }\n },\n\n /**\n * The `globalNeverBuiltDependencies` setting suppresses the `preinstall`, `install`, and `postinstall`\n * lifecycle events for the specified NPM dependencies. This is useful for scripts with poor practices\n * such as downloading large binaries without retries or attempting to invoke OS tools such as\n * a C++ compiler. (PNPM\'s terminology refers to these lifecycle events as "building" a package;\n * it has nothing to do with build system operations such as `rush build` or `rushx build`.)\n * The settings are copied into the `pnpm.neverBuiltDependencies` field of the `common/temp/package.json`\n * file that is generated by Rush during installation.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmneverbuiltdependencies\n */\n "globalNeverBuiltDependencies": [\n // "fsevents"\n ],\n\n /**\n * The `globalAllowedDeprecatedVersions` setting suppresses installation warnings for package\n * versions that the NPM registry reports as being deprecated. This is useful if the\n * deprecated package is an indirect dependency of an external package that has not released a fix.\n * The settings are copied into the `pnpm.allowedDeprecatedVersions` field of the `common/temp/package.json`\n * file that is generated by Rush during installation.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmalloweddeprecatedversions\n *\n * If you are working to eliminate a deprecated version, it\'s better to specify `allowedDeprecatedVersions`\n * in the package.json file for individual Rush projects.\n */\n "globalAllowedDeprecatedVersions": {\n // "request": "*"\n },\n\n\n /**\n * (THIS FIELD IS MACHINE GENERATED) The "globalPatchedDependencies" field is updated automatically\n * by the `rush-pnpm patch-commit` command. It is a dictionary, where the key is an NPM package name\n * and exact version, and the value is a relative path to the associated patch file.\n *\n * PNPM documentation: https://pnpm.io/package_json#pnpmpatcheddependencies\n */\n "globalPatchedDependencies": { },\n\n /**\n * (USE AT YOUR OWN RISK) This is a free-form property bag that will be copied into\n * the `common/temp/package.json` file that is generated by Rush during installation.\n * This provides a way to experiment with new PNPM features. These settings will override\n * any other Rush configuration associated with a given JSON field except for `.pnpmfile.cjs`.\n *\n * USAGE OF THIS SETTING IS NOT SUPPORTED BY THE RUSH MAINTAINERS AND MAY CAUSE RUSH\n * TO MALFUNCTION. If you encounter a missing PNPM setting that you believe should\n * be supported, please create a GitHub issue or PR. Note that Rush does not aim to\n * support every possible PNPM setting, but rather to promote a battle-tested installation\n * strategy that is known to provide a good experience for large teams with lots of projects.\n */\n "unsupportedPackageJsonSettings": {\n // "dependencies": {\n // "not-a-good-practice": "*"\n // },\n // "scripts": {\n // "do-something": "echo Also not a good practice"\n // },\n // "pnpm": { "futurePnpmFeature": true }\n }\n}\n')))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/ad372154.1595ca27.js b/assets/js/ad372154.1595ca27.js deleted file mode 100644 index 3e393cbb..00000000 --- a/assets/js/ad372154.1595ca27.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[6073],{158:(e,n,t)=>{t.d(n,{Zo:()=>l,kt:()=>f});var r=t(6393);function a(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function o(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);n&&(r=r.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,r)}return t}function i(e){for(var n=1;n=0||(a[t]=e[t]);return a}(e,n);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(a[t]=e[t])}return a}var c=r.createContext({}),u=function(e){var n=r.useContext(c),t=n;return e&&(t="function"==typeof e?e(n):i(i({},n),e)),t},l=function(e){var n=u(e.components);return r.createElement(c.Provider,{value:n},e.children)},h="mdxType",p={inlineCode:"code",wrapper:function(e){var n=e.children;return r.createElement(r.Fragment,{},n)}},m=r.forwardRef((function(e,n){var t=e.components,a=e.mdxType,o=e.originalType,c=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),h=u(t),m=a,f=h["".concat(c,".").concat(m)]||h[m]||p[m]||o;return t?r.createElement(f,i(i({ref:n},l),{},{components:t})):r.createElement(f,i({ref:n},l))}));function f(e,n){var t=arguments,a=n&&n.mdxType;if("string"==typeof e||a){var o=t.length,i=new Array(o);i[0]=m;var s={};for(var c in n)hasOwnProperty.call(n,c)&&(s[c]=n[c]);s.originalType=e,s[h]="string"==typeof e?e:a,i[1]=s;for(var u=2;u{t.r(n),t.d(n,{assets:()=>l,contentTitle:()=>c,default:()=>f,frontMatter:()=>s,metadata:()=>u,toc:()=>h});var r=t(9122),a=t(2501),o=(t(6393),t(158)),i=["components"],s={title:"build-cache.json"},c=void 0,u={unversionedId:"pages/configs/build-cache_json",id:"pages/configs/build-cache_json",title:"build-cache.json",description:"This is the template that rush init",source:"@site/docs/pages/configs/build-cache_json.md",sourceDirName:"pages/configs",slug:"/pages/configs/build-cache_json",permalink:"/pages/configs/build-cache_json",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/build-cache_json.md",tags:[],version:"current",frontMatter:{title:"build-cache.json"},sidebar:"docsSidebar",previous:{title:"artifactory.json",permalink:"/pages/configs/artifactory_json"},next:{title:"cobuild.json (experimental)",permalink:"/pages/configs/cobuild_json"}},l={},h=[{value:"See also",id:"see-also",level:2}],p={toc:h},m="wrapper";function f(e){var n=e.components,t=(0,a.Z)(e,i);return(0,o.kt)(m,(0,r.Z)({},p,t,{components:n,mdxType:"MDXLayout"}),(0,o.kt)("p",null,"This is the template that ",(0,o.kt)("a",{parentName:"p",href:"/pages/commands/rush_init"},"rush init"),"\ngenerates for ",(0,o.kt)("strong",{parentName:"p"},"build-cache.json"),":"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"common/config/rush/build-cache.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'/**\n * This configuration file manages Rush\'s build cache feature.\n * More documentation is available on the Rush website: https://rushjs.io\n */\n{\n "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/build-cache.schema.json",\n\n /**\n * (Required) EXPERIMENTAL - Set this to true to enable the build cache feature.\n *\n * See https://rushjs.io/pages/maintainer/build_cache/ for details about this experimental feature.\n */\n "buildCacheEnabled": false,\n\n /**\n * (Required) Choose where project build outputs will be cached.\n *\n * Possible values: "local-only", "azure-blob-storage", "amazon-s3"\n */\n "cacheProvider": "local-only",\n\n /**\n * Setting this property overrides the cache entry ID. If this property is set, it must contain\n * a [hash] token.\n *\n * Other available tokens:\n * - [projectName]\n * - [projectName:normalize]\n * - [phaseName]\n * - [phaseName:normalize]\n * - [phaseName:trimPrefix]\n */\n // "cacheEntryNamePattern": "[projectName:normalize]-[phaseName:normalize]-[hash]"\n\n /**\n * Use this configuration with "cacheProvider"="azure-blob-storage"\n */\n "azureBlobStorageConfiguration": {\n /**\n * (Required) The name of the the Azure storage account to use for build cache.\n */\n // "storageAccountName": "example",\n\n /**\n * (Required) The name of the container in the Azure storage account to use for build cache.\n */\n // "storageContainerName": "my-container",\n\n /**\n * The Azure environment the storage account exists in. Defaults to AzurePublicCloud.\n *\n * Possible values: "AzurePublicCloud", "AzureChina", "AzureGermany", "AzureGovernment"\n */\n // "azureEnvironment": "AzurePublicCloud",\n\n /**\n * An optional prefix for cache item blob names.\n */\n // "blobPrefix": "my-prefix",\n\n /**\n * If set to true, allow writing to the cache. Defaults to false.\n */\n // "isCacheWriteAllowed": true\n },\n\n /**\n * Use this configuration with "cacheProvider"="amazon-s3"\n */\n "amazonS3Configuration": {\n /**\n * (Required unless s3Endpoint is specified) The name of the bucket to use for build cache.\n * Example: "my-bucket"\n */\n // "s3Bucket": "my-bucket",\n\n /**\n * (Required unless s3Bucket is specified) The Amazon S3 endpoint of the bucket to use for build cache.\n * This should not include any path; use the s3Prefix to set the path.\n * Examples: "my-bucket.s3.us-east-2.amazonaws.com" or "http://localhost:9000"\n */\n // "s3Endpoint": "https://my-bucket.s3.us-east-2.amazonaws.com",\n\n /**\n * (Required) The Amazon S3 region of the bucket to use for build cache.\n * Example: "us-east-1"\n */\n // "s3Region": "us-east-1",\n\n /**\n * An optional prefix ("folder") for cache items. It should not start with "/".\n */\n // "s3Prefix": "my-prefix",\n\n /**\n * If set to true, allow writing to the cache. Defaults to false.\n */\n // "isCacheWriteAllowed": true\n }\n}\n')),(0,o.kt)("h2",{id:"see-also"},"See also"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"/pages/maintainer/build_cache"},"Enabling the build cache"))))}f.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/ad372154.d004cc6a.js b/assets/js/ad372154.d004cc6a.js new file mode 100644 index 00000000..bbec6b13 --- /dev/null +++ b/assets/js/ad372154.d004cc6a.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[6073],{158:(e,n,t)=>{t.d(n,{Zo:()=>u,kt:()=>f});var o=t(6393);function a(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function r(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);n&&(o=o.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,o)}return t}function i(e){for(var n=1;n=0||(a[t]=e[t]);return a}(e,n);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(a[t]=e[t])}return a}var c=o.createContext({}),l=function(e){var n=o.useContext(c),t=n;return e&&(t="function"==typeof e?e(n):i(i({},n),e)),t},u=function(e){var n=l(e.components);return o.createElement(c.Provider,{value:n},e.children)},h="mdxType",p={inlineCode:"code",wrapper:function(e){var n=e.children;return o.createElement(o.Fragment,{},n)}},m=o.forwardRef((function(e,n){var t=e.components,a=e.mdxType,r=e.originalType,c=e.parentName,u=s(e,["components","mdxType","originalType","parentName"]),h=l(t),m=a,f=h["".concat(c,".").concat(m)]||h[m]||p[m]||r;return t?o.createElement(f,i(i({ref:n},u),{},{components:t})):o.createElement(f,i({ref:n},u))}));function f(e,n){var t=arguments,a=n&&n.mdxType;if("string"==typeof e||a){var r=t.length,i=new Array(r);i[0]=m;var s={};for(var c in n)hasOwnProperty.call(n,c)&&(s[c]=n[c]);s.originalType=e,s[h]="string"==typeof e?e:a,i[1]=s;for(var l=2;l{t.r(n),t.d(n,{assets:()=>u,contentTitle:()=>c,default:()=>f,frontMatter:()=>s,metadata:()=>l,toc:()=>h});var o=t(9122),a=t(2501),r=(t(6393),t(158)),i=["components"],s={title:"build-cache.json"},c=void 0,l={unversionedId:"pages/configs/build-cache_json",id:"pages/configs/build-cache_json",title:"build-cache.json",description:"This is the template that rush init",source:"@site/docs/pages/configs/build-cache_json.md",sourceDirName:"pages/configs",slug:"/pages/configs/build-cache_json",permalink:"/pages/configs/build-cache_json",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/build-cache_json.md",tags:[],version:"current",frontMatter:{title:"build-cache.json"},sidebar:"docsSidebar",previous:{title:"artifactory.json",permalink:"/pages/configs/artifactory_json"},next:{title:"cobuild.json (experimental)",permalink:"/pages/configs/cobuild_json"}},u={},h=[{value:"See also",id:"see-also",level:2}],p={toc:h},m="wrapper";function f(e){var n=e.components,t=(0,a.Z)(e,i);return(0,r.kt)(m,(0,o.Z)({},p,t,{components:n,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"This is the template that ",(0,r.kt)("a",{parentName:"p",href:"/pages/commands/rush_init"},"rush init"),"\ngenerates for ",(0,r.kt)("strong",{parentName:"p"},"build-cache.json"),":"),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},"common/config/rush/build-cache.json")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-js"},'/**\n * This configuration file manages Rush\'s build cache feature.\n * More documentation is available on the Rush website: https://rushjs.io\n */\n{\n "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/build-cache.schema.json",\n\n /**\n * (Required) Set this to true to enable the build cache feature.\n *\n * See https://rushjs.io/pages/maintainer/build_cache/ for details about this feature.\n */\n "buildCacheEnabled": false,\n\n /**\n * (Required) Choose where project build outputs will be cached.\n *\n * Possible values: "local-only", "azure-blob-storage", "amazon-s3"\n */\n "cacheProvider": "local-only",\n\n /**\n * Setting this property overrides the cache entry ID. If this property is set, it must contain\n * a [hash] token.\n *\n * Other available tokens:\n * - [projectName]\n * - [projectName:normalize]\n * - [phaseName]\n * - [phaseName:normalize]\n * - [phaseName:trimPrefix]\n */\n // "cacheEntryNamePattern": "[projectName:normalize]-[phaseName:normalize]-[hash]"\n\n /**\n * Use this configuration with "cacheProvider"="azure-blob-storage"\n */\n "azureBlobStorageConfiguration": {\n /**\n * (Required) The name of the the Azure storage account to use for build cache.\n */\n // "storageAccountName": "example",\n\n /**\n * (Required) The name of the container in the Azure storage account to use for build cache.\n */\n // "storageContainerName": "my-container",\n\n /**\n * The Azure environment the storage account exists in. Defaults to AzurePublicCloud.\n *\n * Possible values: "AzurePublicCloud", "AzureChina", "AzureGermany", "AzureGovernment"\n */\n // "azureEnvironment": "AzurePublicCloud",\n\n /**\n * An optional prefix for cache item blob names.\n */\n // "blobPrefix": "my-prefix",\n\n /**\n * If set to true, allow writing to the cache. Defaults to false.\n */\n // "isCacheWriteAllowed": true\n },\n\n /**\n * Use this configuration with "cacheProvider"="amazon-s3"\n */\n "amazonS3Configuration": {\n /**\n * (Required unless s3Endpoint is specified) The name of the bucket to use for build cache.\n * Example: "my-bucket"\n */\n // "s3Bucket": "my-bucket",\n\n /**\n * (Required unless s3Bucket is specified) The Amazon S3 endpoint of the bucket to use for build cache.\n * This should not include any path; use the s3Prefix to set the path.\n * Examples: "my-bucket.s3.us-east-2.amazonaws.com" or "http://localhost:9000"\n */\n // "s3Endpoint": "https://my-bucket.s3.us-east-2.amazonaws.com",\n\n /**\n * (Required) The Amazon S3 region of the bucket to use for build cache.\n * Example: "us-east-1"\n */\n // "s3Region": "us-east-1",\n\n /**\n * An optional prefix ("folder") for cache items. It should not start with "/".\n */\n // "s3Prefix": "my-prefix",\n\n /**\n * If set to true, allow writing to the cache. Defaults to false.\n */\n // "isCacheWriteAllowed": true\n },\n\n /**\n * Use this configuration with "cacheProvider"="http"\n */\n "httpConfiguration": {\n /**\n * (Required) The URL of the server that stores the caches.\n * Example: "https://build-cacches.example.com/"\n */\n // "url": "https://build-cacches.example.com/",\n\n /**\n * (Optional) The HTTP method to use when writing to the cache (defaults to PUT).\n * Should be one of PUT, POST, or PATCH.\n * Example: "PUT"\n */\n // "uploadMethod": "PUT",\n\n /**\n * (Optional) HTTP headers to pass to the cache server.\n * Example: { "X-HTTP-Company-Id": "109283" }\n */\n // "headers": {},\n\n /**\n * (Optional) Shell command that prints the authorization token needed to communicate with the\n * cache server, and exits with exit code 0. This command will be executed from the root of\n * the monorepo.\n * Example: { "exec": "node", "args": ["common/scripts/auth.js"] }\n */\n // "tokenHandler": { "exec": "node", "args": ["common/scripts/auth.js"] },\n\n /**\n * (Optional) Prefix for cache keys.\n * Example: "my-company-"\n */\n // "cacheKeyPrefix": "",\n\n /**\n * (Optional) If set to true, allow writing to the cache. Defaults to false.\n */\n // "isCacheWriteAllowed": true\n }\n}\n')),(0,r.kt)("h2",{id:"see-also"},"See also"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"/pages/maintainer/build_cache"},"Enabling the build cache"))))}f.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/b93162f9.49447d6b.js b/assets/js/b93162f9.4c6e3096.js similarity index 59% rename from assets/js/b93162f9.49447d6b.js rename to assets/js/b93162f9.4c6e3096.js index 389d9161..b764f0f2 100644 --- a/assets/js/b93162f9.49447d6b.js +++ b/assets/js/b93162f9.4c6e3096.js @@ -1 +1 @@ -"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[9361],{158:(e,n,t)=>{t.d(n,{Zo:()=>c,kt:()=>h});var r=t(6393);function o(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function s(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);n&&(r=r.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,r)}return t}function a(e){for(var n=1;n=0||(o[t]=e[t]);return o}(e,n);if(Object.getOwnPropertySymbols){var s=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(o[t]=e[t])}return o}var l=r.createContext({}),p=function(e){var n=r.useContext(l),t=n;return e&&(t="function"==typeof e?e(n):a(a({},n),e)),t},c=function(e){var n=p(e.components);return r.createElement(l.Provider,{value:n},e.children)},u="mdxType",m={inlineCode:"code",wrapper:function(e){var n=e.children;return r.createElement(r.Fragment,{},n)}},f=r.forwardRef((function(e,n){var t=e.components,o=e.mdxType,s=e.originalType,l=e.parentName,c=i(e,["components","mdxType","originalType","parentName"]),u=p(t),f=o,h=u["".concat(l,".").concat(f)]||u[f]||m[f]||s;return t?r.createElement(h,a(a({ref:n},c),{},{components:t})):r.createElement(h,a({ref:n},c))}));function h(e,n){var t=arguments,o=n&&n.mdxType;if("string"==typeof e||o){var s=t.length,a=new Array(s);a[0]=f;var i={};for(var l in n)hasOwnProperty.call(n,l)&&(i[l]=n[l]);i.originalType=e,i[u]="string"==typeof e?e:o,a[1]=i;for(var p=2;p{t.r(n),t.d(n,{assets:()=>c,contentTitle:()=>l,default:()=>h,frontMatter:()=>i,metadata:()=>p,toc:()=>u});var r=t(9122),o=t(2501),s=(t(6393),t(158)),a=["components"],i={title:"experiments.json"},l=void 0,p={unversionedId:"pages/configs/experiments_json",id:"pages/configs/experiments_json",title:"experiments.json",description:"This is the template that rush init",source:"@site/docs/pages/configs/experiments_json.md",sourceDirName:"pages/configs",slug:"/pages/configs/experiments_json",permalink:"/pages/configs/experiments_json",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/experiments_json.md",tags:[],version:"current",frontMatter:{title:"experiments.json"},sidebar:"docsSidebar",previous:{title:"deploy.json",permalink:"/pages/configs/deploy_json"},next:{title:"pnpm-config.json",permalink:"/pages/configs/pnpm-config_json"}},c={},u=[],m={toc:u},f="wrapper";function h(e){var n=e.components,t=(0,o.Z)(e,a);return(0,s.kt)(f,(0,r.Z)({},m,t,{components:n,mdxType:"MDXLayout"}),(0,s.kt)("p",null,"This is the template that ",(0,s.kt)("a",{parentName:"p",href:"/pages/commands/rush_init"},"rush init"),"\ngenerates for ",(0,s.kt)("strong",{parentName:"p"},"experiments.json"),":"),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"common/config/rush/experiments.json")),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-js"},'/**\n * This configuration file allows repo maintainers to enable and disable experimental\n * Rush features. More documentation is available on the Rush website: https://rushjs.io\n */\n{\n "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/experiments.schema.json",\n\n /**\n * By default, \'rush install\' passes --no-prefer-frozen-lockfile to \'pnpm install\'.\n * Set this option to true to pass \'--frozen-lockfile\' instead for faster installs.\n */\n // "usePnpmFrozenLockfileForRushInstall": true,\n\n /**\n * By default, \'rush update\' passes --no-prefer-frozen-lockfile to \'pnpm install\'.\n * Set this option to true to pass \'--prefer-frozen-lockfile\' instead to minimize shrinkwrap changes.\n */\n // "usePnpmPreferFrozenLockfileForRushUpdate": true,\n\n /**\n * If using the \'preventManualShrinkwrapChanges\' option, restricts the hash to only include the layout of external dependencies.\n * Used to allow links between workspace projects or the addition/removal of references to existing dependency versions to not\n * cause hash changes.\n */\n // "omitImportersFromPreventManualShrinkwrapChanges": true,\n\n /**\n * If true, the chmod field in temporary project tar headers will not be normalized.\n * This normalization can help ensure consistent tarball integrity across platforms.\n */\n // "noChmodFieldInTarHeaderNormalization": true,\n\n /**\n * If true, build caching will respect the allowWarningsInSuccessfulBuild flag and cache builds with warnings.\n * This will not replay warnings from the cached build.\n */\n // "buildCacheWithAllowWarningsInSuccessfulBuild": true,\n\n /**\n * If true, the phased commands feature is enabled. To use this feature, create a "phased" command\n * in common/config/rush/command-line.json.\n */\n // "phasedCommands": true\n}\n')))}h.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[9361],{158:(e,n,t)=>{t.d(n,{Zo:()=>c,kt:()=>h});var r=t(6393);function o(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function s(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);n&&(r=r.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,r)}return t}function a(e){for(var n=1;n=0||(o[t]=e[t]);return o}(e,n);if(Object.getOwnPropertySymbols){var s=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(o[t]=e[t])}return o}var l=r.createContext({}),p=function(e){var n=r.useContext(l),t=n;return e&&(t="function"==typeof e?e(n):a(a({},n),e)),t},c=function(e){var n=p(e.components);return r.createElement(l.Provider,{value:n},e.children)},u="mdxType",f={inlineCode:"code",wrapper:function(e){var n=e.children;return r.createElement(r.Fragment,{},n)}},m=r.forwardRef((function(e,n){var t=e.components,o=e.mdxType,s=e.originalType,l=e.parentName,c=i(e,["components","mdxType","originalType","parentName"]),u=p(t),m=o,h=u["".concat(l,".").concat(m)]||u[m]||f[m]||s;return t?r.createElement(h,a(a({ref:n},c),{},{components:t})):r.createElement(h,a({ref:n},c))}));function h(e,n){var t=arguments,o=n&&n.mdxType;if("string"==typeof e||o){var s=t.length,a=new Array(s);a[0]=m;var i={};for(var l in n)hasOwnProperty.call(n,l)&&(i[l]=n[l]);i.originalType=e,i[u]="string"==typeof e?e:o,a[1]=i;for(var p=2;p{t.r(n),t.d(n,{assets:()=>c,contentTitle:()=>l,default:()=>h,frontMatter:()=>i,metadata:()=>p,toc:()=>u});var r=t(9122),o=t(2501),s=(t(6393),t(158)),a=["components"],i={title:"experiments.json"},l=void 0,p={unversionedId:"pages/configs/experiments_json",id:"pages/configs/experiments_json",title:"experiments.json",description:"This is the template that rush init",source:"@site/docs/pages/configs/experiments_json.md",sourceDirName:"pages/configs",slug:"/pages/configs/experiments_json",permalink:"/pages/configs/experiments_json",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/configs/experiments_json.md",tags:[],version:"current",frontMatter:{title:"experiments.json"},sidebar:"docsSidebar",previous:{title:"deploy.json",permalink:"/pages/configs/deploy_json"},next:{title:"pnpm-config.json",permalink:"/pages/configs/pnpm-config_json"}},c={},u=[],f={toc:u},m="wrapper";function h(e){var n=e.components,t=(0,o.Z)(e,a);return(0,s.kt)(m,(0,r.Z)({},f,t,{components:n,mdxType:"MDXLayout"}),(0,s.kt)("p",null,"This is the template that ",(0,s.kt)("a",{parentName:"p",href:"/pages/commands/rush_init"},"rush init"),"\ngenerates for ",(0,s.kt)("strong",{parentName:"p"},"experiments.json"),":"),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"common/config/rush/experiments.json")),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-js"},'/**\n * This configuration file allows repo maintainers to enable and disable experimental\n * Rush features. More documentation is available on the Rush website: https://rushjs.io\n */\n{\n "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/experiments.schema.json",\n\n /**\n * By default, \'rush install\' passes --no-prefer-frozen-lockfile to \'pnpm install\'.\n * Set this option to true to pass \'--frozen-lockfile\' instead for faster installs.\n */\n // "usePnpmFrozenLockfileForRushInstall": true,\n\n /**\n * By default, \'rush update\' passes --no-prefer-frozen-lockfile to \'pnpm install\'.\n * Set this option to true to pass \'--prefer-frozen-lockfile\' instead to minimize shrinkwrap changes.\n */\n // "usePnpmPreferFrozenLockfileForRushUpdate": true,\n\n /**\n * By default, \'rush update\' runs as a single operation.\n * Set this option to true to instead update the lockfile with `--lockfile-only`, then perform a `--frozen-lockfile` install.\n * Necessary when using the `afterAllResolved` hook in .pnpmfile.cjs.\n */\n // "usePnpmLockfileOnlyThenFrozenLockfileForRushUpdate": true,\n\n /**\n * If using the \'preventManualShrinkwrapChanges\' option, restricts the hash to only include the layout of external dependencies.\n * Used to allow links between workspace projects or the addition/removal of references to existing dependency versions to not\n * cause hash changes.\n */\n // "omitImportersFromPreventManualShrinkwrapChanges": true,\n\n /**\n * If true, the chmod field in temporary project tar headers will not be normalized.\n * This normalization can help ensure consistent tarball integrity across platforms.\n */\n // "noChmodFieldInTarHeaderNormalization": true,\n\n /**\n * If true, build caching will respect the allowWarningsInSuccessfulBuild flag and cache builds with warnings.\n * This will not replay warnings from the cached build.\n */\n // "buildCacheWithAllowWarningsInSuccessfulBuild": true,\n\n /**\n * If true, the phased commands feature is enabled. To use this feature, create a "phased" command\n * in common/config/rush/command-line.json.\n */\n // "phasedCommands": true,\n\n /**\n * If true, perform a clean install after when running `rush install` or `rush update` if the\n * `.npmrc` file has changed since the last install.\n */\n // "cleanInstallAfterNpmrcChanges": true,\n\n /**\n * If true, print the outputs of shell commands defined in event hooks to the console.\n */\n // "printEventHooksOutputToConsole": true,\n\n /**\n * If true, Rush will not allow node_modules in the repo folder or in parent folders.\n */\n // "forbidPhantomResolvableNodeModulesFolders": true\n}\n')))}h.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/d98d853d.3513af17.js b/assets/js/d98d853d.3513af17.js deleted file mode 100644 index d6996759..00000000 --- a/assets/js/d98d853d.3513af17.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[6339],{158:(e,t,n)=>{n.d(t,{Zo:()=>u,kt:()=>m});var a=n(6393);function r(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);t&&(a=a.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,a)}return n}function i(e){for(var t=1;t=0||(r[n]=e[n]);return r}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(a=0;a=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(r[n]=e[n])}return r}var l=a.createContext({}),c=function(e){var t=a.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},u=function(e){var t=c(e.components);return a.createElement(l.Provider,{value:t},e.children)},p="mdxType",h={inlineCode:"code",wrapper:function(e){var t=e.children;return a.createElement(a.Fragment,{},t)}},d=a.forwardRef((function(e,t){var n=e.components,r=e.mdxType,o=e.originalType,l=e.parentName,u=s(e,["components","mdxType","originalType","parentName"]),p=c(n),d=r,m=p["".concat(l,".").concat(d)]||p[d]||h[d]||o;return n?a.createElement(m,i(i({ref:t},u),{},{components:n})):a.createElement(m,i({ref:t},u))}));function m(e,t){var n=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var o=n.length,i=new Array(o);i[0]=d;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s[p]="string"==typeof e?e:r,i[1]=s;for(var c=2;c{n.r(t),n.d(t,{assets:()=>u,contentTitle:()=>l,default:()=>m,frontMatter:()=>s,metadata:()=>c,toc:()=>p});var a=n(9122),r=n(2501),o=(n(6393),n(158)),i=["components"],s={title:"Enabling the build cache"},l=void 0,c={unversionedId:"pages/maintainer/build_cache",id:"pages/maintainer/build_cache",title:"Enabling the build cache",description:"Rush has always supported an incremental build analyzer that",source:"@site/docs/pages/maintainer/build_cache.md",sourceDirName:"pages/maintainer",slug:"/pages/maintainer/build_cache",permalink:"/pages/maintainer/build_cache",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/maintainer/build_cache.md",tags:[],version:"current",frontMatter:{title:"Enabling the build cache"},sidebar:"docsSidebar",previous:{title:"Deploying projects",permalink:"/pages/maintainer/deploying"},next:{title:"Enabling phased builds",permalink:"/pages/maintainer/phased_builds"}},u={},p=[{value:"Enabling the local disk cache",id:"enabling-the-local-disk-cache",level:2},{value:"Configuring project output folders",id:"configuring-project-output-folders",level:2},{value:"Configuring project inputs",id:"configuring-project-inputs",level:2},{value:"Testing the build cache",id:"testing-the-build-cache",level:2},{value:"Enabling cloud storage",id:"enabling-cloud-storage",level:2},{value:"User authentication",id:"user-authentication",level:2},{value:"CI setup",id:"ci-setup",level:2},{value:"Credentials",id:"credentials",level:3},{value:"Azure Storage",id:"azure-storage",level:4},{value:"AWS",id:"aws",level:4}],h={toc:p},d="wrapper";function m(e){var t=e.components,n=(0,r.Z)(e,i);return(0,o.kt)(d,(0,a.Z)({},h,n,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("p",null,"Rush has always supported an ",(0,o.kt)("a",{parentName:"p",href:"/pages/advanced/incremental_builds"},"incremental build")," analyzer that\nenables ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," to skip projects whose input files have not changed since the last build.\nIt can also be used with custom commands by enabling the ",(0,o.kt)("inlineCode",{parentName:"p"},"incremental")," flag in ",(0,o.kt)("strong",{parentName:"p"},"custom-commands.json"),".\nWe call this the ",(0,o.kt)("strong",{parentName:"p"},'"output preservation"')," strategy for incremental builds. Because the build output\nis not saved anywhere, a full rebuild is generally still required when checking out a different branch."),(0,o.kt)("p",null,"Rush's ",(0,o.kt)("strong",{parentName:"p"},"build cache")," improves on this by creating a tar archive of each project's build outputs.\nThe archive is cached so that later, if ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," can find a match in the cache, it can extract the archive\ninstead of building that project. This can provide dramatic speedups, for example reducing a 30 minute build time\nto 30 seconds. We call this the ",(0,o.kt)("strong",{parentName:"p"},'"cache restoration"')," strategy for incremental builds."),(0,o.kt)("p",null,"The build cache archives are stored in two places:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"In a cache folder on your local disk.")," This way you can switch between different branches without\nlosing your incremental build state. You can even configure a centralized folder to be shared between\nmultiple enlistments on your machine. The default location is ",(0,o.kt)("strong",{parentName:"p"},"common/temp/build-cache"),".")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"In a cloud-hosted storage container. (Optional)")," In a typical setup, the CI system would be configured to write\nto cloud storage, and individual users are granted read-only access. For example, each time a PR is merged into\nthe ",(0,o.kt)("inlineCode",{parentName:"p"},"main")," branch, the CI system builds that baseline and uploads it to cloud storage. Even for a user who\nis doing ",(0,o.kt)("inlineCode",{parentName:"p"},"git clone")," for the first time, their ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," will be very fast."))),(0,o.kt)("h2",{id:"enabling-the-local-disk-cache"},"Enabling the local disk cache"),(0,o.kt)("p",null,"The build cache feature is enabled using the ",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/build-cache_json"},"build-cache.json"),"\nconfig file. You can copy the template from the website or use ",(0,o.kt)("inlineCode",{parentName:"p"},"rush init")," to create this file."),(0,o.kt)("p",null,"To enable the basic local disk cache, add these two settings:"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"common/config/rush/build-cache.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'{\n . . .\n /**\n * (Required) EXPERIMENTAL - Set this to true to enable the build cache feature.\n *\n * See https://rushjs.io/pages/maintainer/build_cache/ for details about this experimental feature.\n */\n "buildCacheEnabled": true,\n\n /**\n * (Required) Choose where project build outputs will be cached.\n *\n * Possible values: "local-only", "azure-blob-storage", "amazon-s3"\n */\n "cacheProvider": "local-only",\n\n . . .\n}\n')),(0,o.kt)("blockquote",null,(0,o.kt)("p",{parentName:"blockquote"},(0,o.kt)("strong",{parentName:"p"},"Upgrade note:")," Early releases of this feature were enabled using the ",(0,o.kt)("inlineCode",{parentName:"p"},'"buildCache": true')," setting\nin ",(0,o.kt)("strong",{parentName:"p"},"experiments.json"),". This has been superseded by ",(0,o.kt)("inlineCode",{parentName:"p"},'"buildCacheEnabled"')," in ",(0,o.kt)("strong",{parentName:"p"},"build-cache.json"),".")),(0,o.kt)("h2",{id:"configuring-project-output-folders"},"Configuring project output folders"),(0,o.kt)("p",null,"With only this change, if you run ",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild --verbose"),", you will see this warning:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre"},"Project does not have a rush-project.json configuration file, or one provided by a rig,\nso it does not support caching.\n")),(0,o.kt)("p",null,"The build cache needs to know which folders should be stored in the tar archive. Those details vary between\ntoolchains, and are thus configured separately for each project using the\n",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/rush-project_json"},"rush-project.json")," config file."),(0,o.kt)("p",null,"For example:"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"<","your-project",">","/config/rush-project.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'{\n . . .\n\n /**\n * Specify the folders where your toolchain writes its output files. If enabled, the Rush build cache will\n * restore these folders from the cache.\n *\n * The strings are folder names under the project root folder. These folders should not be tracked by Git.\n * They must not contain symlinks.\n */\n "projectOutputFolderNames": ["lib", "dist"]\n . . .\n}\n')),(0,o.kt)("h2",{id:"configuring-project-inputs"},"Configuring project inputs"),(0,o.kt)("p",null,"By default, the following inputs are incorporated into Rush's cache key. In other words, if any of these things\nchanges, then the project must be rebuilt:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},"the hash of the source files that are under the project's folder, ignoring any files excluded by ",(0,o.kt)("inlineCode",{parentName:"p"},".gitignore"))),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},"the hashes of source files under other workspace projects that are dependencies of the project ",(0,o.kt)("br",null),"\n(applies to ",(0,o.kt)("strong",{parentName:"p"},"cache restoration")," strategy but not ",(0,o.kt)("strong",{parentName:"p"},"output preservation")," strategy)")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},"the versions of all external NPM packages that your project depends on, including indirect dependencies")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},"the Rush command-line parameters used to perform the operation"))),(0,o.kt)("p",null,"These details can be customized using the ",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/rush-project_json"},"rush-project.json")," config file.\nFor example, you can include/exclude certain glob patterns, or specify environment variables that affect the\nbuild output. It's recommended to use a ",(0,o.kt)("a",{parentName:"p",href:"https://heft.rushstack.io/pages/intro/rig_packages/"},"rig package")," to avoid\nhaving to copy ",(0,o.kt)("strong",{parentName:"p"},"rush-project.json")," into every project folder."),(0,o.kt)("blockquote",null,(0,o.kt)("p",{parentName:"blockquote"},(0,o.kt)("strong",{parentName:"p"},"Important:")," Configure these settings carefully. If a project inputs/outputs are not accurately specified,\nthen the build cache may produce incorrect or inconsistent results. For example, the restored output may\nbe missing some files. Or it may be different from what would be produced by a full rebuild. Such problems\ncan be difficult to reproduce and troubleshoot."),(0,o.kt)("p",{parentName:"blockquote"},"If you suspect that the Rush build cache may be misconfigured, try the\n",(0,o.kt)("a",{parentName:"p",href:"https://www.npmjs.com/package/rush-audit-cache-plugin"},"rush-audit-cache-plugin"),".\nIt monitors file writes during the build to identify inputs that are not part of your cache key.")),(0,o.kt)("h2",{id:"testing-the-build-cache"},"Testing the build cache"),(0,o.kt)("p",null,"Now you should see projects being cached as shown in this sample log output:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-bash"},"rush build --verbose\n")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre"},'. . .\n\n==[ example-project ]==============================================[ 1 of 5 ]==\n\nThis project was not found in the build cache.\n\nInvoking: heft test --clean\n\n. . .\n\nCaching build output folders: lib\n\nSuccessfully set cache entry.\n\n"example-project" completed successfully in 11.27 seconds.\n')),(0,o.kt)("p",null,"When we run the same command a second time, Rush extracts the archive instead of invoking the build task:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-bash"},"rush build --verbose\n")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre"},". . .\n\n==[ example-project ]==============================================[ 1 of 5 ]==\n\nBuild cache hit.\n\nClearing cached folders: lib, dist\n\nSuccessfully restored output from the build cache.\n\nexample-project was restored from the build cache.\n")),(0,o.kt)("p",null,"Note that ",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild")," will not read from cache, only ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," does. To disable writing from cache during ",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild"),",\nset the ",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/environment_vars"},(0,o.kt)("inlineCode",{parentName:"a"},"RUSH_BUILD_CACHE_WRITE_ALLOWED"))," environment variable to ",(0,o.kt)("inlineCode",{parentName:"p"},"0"),"."),(0,o.kt)("p",null,"By default, the cached tar archives are stored under your ",(0,o.kt)("strong",{parentName:"p"},"common/temp/build-cache")," folder\n(and thus will be cleaned by ",(0,o.kt)("inlineCode",{parentName:"p"},"rush purge"),"). It is safe to delete these files."),(0,o.kt)("h2",{id:"enabling-cloud-storage"},"Enabling cloud storage"),(0,o.kt)("p",null,"Currently the ",(0,o.kt)("inlineCode",{parentName:"p"},"cacheProvider")," setting provides three choices:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},'"local-only"'),": no cloud storage; archives are only kept on a local disk folder"),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},'"azure-blob-storage"'),": Microsoft Azure ",(0,o.kt)("a",{parentName:"li",href:"https://docs.microsoft.com/en-us/azure/storage/blobs/"},"blob storage container")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},'"amazon-s3"'),": Amazon ",(0,o.kt)("a",{parentName:"li",href:"https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html"},"S3 bucket"))),(0,o.kt)("p",null,"(The above providers are ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/microsoft/rushstack/tree/main/rush-plugins"},"modeled as Rush plugins"),".\nCustom build cache storage providers can be implemented in the same way.)"),(0,o.kt)("p",null,"As one example, here's how to configure an Azure blob container:"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"common/config/rush/build-cache.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'{\n . . .\n /**\n * (Required) EXPERIMENTAL - Set this to true to enable the build cache feature.\n *\n * See https://rushjs.io/pages/maintainer/build_cache/ for details about this experimental feature.\n */\n "buildCacheEnabled": true,\n\n /**\n * (Required) Choose where project build outputs will be cached.\n *\n * Possible values: "local-only", "azure-blob-storage", "amazon-s3"\n */\n "cacheProvider": "azure-blob-storage",\n\n /**\n * Use this configuration with "cacheProvider"="azure-blob-storage"\n */\n "azureBlobStorageConfiguration": {\n /**\n * (Required) The name of the the Azure storage account to use for build cache.\n */\n "storageAccountName": "example",\n\n /**\n * The name of the container in the Azure storage account to use for build cache.\n */\n "storageContainerName": "my-container"\n\n /**\n * If set to true, allow writing to the cache. Defaults to false.\n */\n "isCacheWriteAllowed": false\n\n . . .\n')),(0,o.kt)("p",null,"Note that we have set ",(0,o.kt)("inlineCode",{parentName:"p"},'"isCacheWriteAllowed": false')," to prevent regular users from writing to the container.\n(Later, we will use an environment variable to override this for our CI job.)"),(0,o.kt)("h2",{id:"user-authentication"},"User authentication"),(0,o.kt)("p",null,"If security is not a priority for your repo, you can simplify user setup by configuring your storage container\nto allow unauthenticated anonymous access. The container is accessed via an HTTPS URL containing randomized\nhashes which are difficult to guess without access to your Git repo. This provides rudimentary\n",(0,o.kt)("a",{parentName:"p",href:"https://en.wikipedia.org/wiki/Security_through_obscurity"},"security through obscurity"),"."),(0,o.kt)("p",null,"A more security-conscious organization however will prefer to require authentication even for read-only access.\nRush provides a ",(0,o.kt)("a",{parentName:"p",href:"/pages/commands/rush_update-cloud-credentials"},"rush update-cloud-credentials"),"\ncommand to make this easy for users to set up:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-bash"},"rush update-cloud-credentials --interactive\n")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre"},'Rush Multi-Project Build Tool 5.45.6 (unmanaged) - https://rushjs.io\nNode.js version is 12.20.1 (LTS)\n\n\nStarting "rush update-cloud-credentials"\n\n \u2554\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2557\n \u2551 To sign in, use a web browser to open the page \u2551\n \u2551 https://microsoft.com/devicelogin and enter the code XAYBQEGRK \u2551\n \u2551 to authenticate. \u2551\n \u255a\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u255d\n')),(0,o.kt)("p",null,"The credentials are stored in the user's home directory under ",(0,o.kt)("inlineCode",{parentName:"p"},"~/.rush-user/credentials.json"),"."),(0,o.kt)("h2",{id:"ci-setup"},"CI setup"),(0,o.kt)("p",null,"In a typical configuration, users have read-only access and the cache is populated by an automation account;\nfor example, a CI job that builds your ",(0,o.kt)("inlineCode",{parentName:"p"},"main")," branch after each PR is merged. In our example above, the\n",(0,o.kt)("inlineCode",{parentName:"p"},'"isCacheWriteAllowed": false')," setting is what prevents users from writing to the cache. The CI job can\noverride this by setting the ",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/environment_vars"},"RUSH_BUILD_CACHE_WRITE_ALLOWED"),"\nenvironment variable, and by providing credentials for the CI environment in the\n",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/environment_vars"},"RUSH_BUILD_CACHE_CREDENTIAL")," environment variable."),(0,o.kt)("h3",{id:"credentials"},"Credentials"),(0,o.kt)("h4",{id:"azure-storage"},"Azure Storage"),(0,o.kt)("p",null,"For Azure Blob Storage, ",(0,o.kt)("inlineCode",{parentName:"p"},"RUSH_BUILD_CACHE_CREDENTIAL")," must be a SAS token serialized as query parameters.\nSee ",(0,o.kt)("a",{parentName:"p",href:"https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview"},"this article")," for details\nabout SAS tokens. You can obtain a SAS token via the ",(0,o.kt)("a",{parentName:"p",href:"https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage?tabs=azure-portal"},"Settings > Access keys"),"\npage for your storage account."),(0,o.kt)("h4",{id:"aws"},"AWS"),(0,o.kt)("p",null,"For Amazon S3, ",(0,o.kt)("inlineCode",{parentName:"p"},"RUSH_BUILD_CACHE_CREDENTIAL")," will be your AWS Access Key ID and AWS Secret Access Key separated by a colon,\nsuch as: ",(0,o.kt)("inlineCode",{parentName:"p"},":"),". You can also pass temporary session tokens required when assuming an IAM role: ",(0,o.kt)("inlineCode",{parentName:"p"},"::"),"."),(0,o.kt)("p",null,"If ",(0,o.kt)("inlineCode",{parentName:"p"},"RUSH_BUILD_CACHE_CREDENTIAL")," is not set, the build cache will attempt to read the environment vars ",(0,o.kt)("inlineCode",{parentName:"p"},"AWS_ACCESS_KEY_ID"),", ",(0,o.kt)("inlineCode",{parentName:"p"},"AWS_SECRET_ACCESS_KEY"),", and ",(0,o.kt)("inlineCode",{parentName:"p"},"AWS_SESSION_TOKEN")," that\nare commonly set via the AWS CLI or other CI tooling. However, ",(0,o.kt)("inlineCode",{parentName:"p"},"RUSH_BUILD_CACHE_CREDENTIAL")," will always take precedence if it exists."),(0,o.kt)("blockquote",null,(0,o.kt)("p",{parentName:"blockquote"},"The build cache feature is still under development. Feedback is welcome!"),(0,o.kt)("p",{parentName:"blockquote"},"Some relevant GitHub issues to follow:"),(0,o.kt)("ul",{parentName:"blockquote"},(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/microsoft/rushstack/issues/2393"},"Build cache feature #2393")," - the original feature spec"),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/microsoft/rushstack/issues/2642"},"Build Cache: split apart RUSH_BUILD_CACHE_WRITE_CREDENTIAL #2642")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/microsoft/rushstack/issues/2618"},"Allow project config to specify non-build-related files #2618")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/microsoft/rushstack/issues/2622"},'"tar" exited with code 1 while attempting to create the cache entry #2622')))))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/d98d853d.d10f8d08.js b/assets/js/d98d853d.d10f8d08.js new file mode 100644 index 00000000..c9743433 --- /dev/null +++ b/assets/js/d98d853d.d10f8d08.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[6339],{158:(e,t,n)=>{n.d(t,{Zo:()=>u,kt:()=>m});var a=n(6393);function r(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);t&&(a=a.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,a)}return n}function i(e){for(var t=1;t=0||(r[n]=e[n]);return r}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(a=0;a=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(r[n]=e[n])}return r}var l=a.createContext({}),c=function(e){var t=a.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},u=function(e){var t=c(e.components);return a.createElement(l.Provider,{value:t},e.children)},p="mdxType",h={inlineCode:"code",wrapper:function(e){var t=e.children;return a.createElement(a.Fragment,{},t)}},d=a.forwardRef((function(e,t){var n=e.components,r=e.mdxType,o=e.originalType,l=e.parentName,u=s(e,["components","mdxType","originalType","parentName"]),p=c(n),d=r,m=p["".concat(l,".").concat(d)]||p[d]||h[d]||o;return n?a.createElement(m,i(i({ref:t},u),{},{components:n})):a.createElement(m,i({ref:t},u))}));function m(e,t){var n=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var o=n.length,i=new Array(o);i[0]=d;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s[p]="string"==typeof e?e:r,i[1]=s;for(var c=2;c{n.r(t),n.d(t,{assets:()=>u,contentTitle:()=>l,default:()=>m,frontMatter:()=>s,metadata:()=>c,toc:()=>p});var a=n(9122),r=n(2501),o=(n(6393),n(158)),i=["components"],s={title:"Enabling the build cache"},l=void 0,c={unversionedId:"pages/maintainer/build_cache",id:"pages/maintainer/build_cache",title:"Enabling the build cache",description:"Rush has always supported an incremental build analyzer that",source:"@site/docs/pages/maintainer/build_cache.md",sourceDirName:"pages/maintainer",slug:"/pages/maintainer/build_cache",permalink:"/pages/maintainer/build_cache",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/maintainer/build_cache.md",tags:[],version:"current",frontMatter:{title:"Enabling the build cache"},sidebar:"docsSidebar",previous:{title:"Deploying projects",permalink:"/pages/maintainer/deploying"},next:{title:"Enabling phased builds",permalink:"/pages/maintainer/phased_builds"}},u={},p=[{value:"Enabling the local disk cache",id:"enabling-the-local-disk-cache",level:2},{value:"Configuring project output folders",id:"configuring-project-output-folders",level:2},{value:"Configuring project inputs",id:"configuring-project-inputs",level:2},{value:"Testing the build cache",id:"testing-the-build-cache",level:2},{value:"Enabling cloud storage",id:"enabling-cloud-storage",level:2},{value:"User authentication",id:"user-authentication",level:2},{value:"CI setup",id:"ci-setup",level:2},{value:"Credentials",id:"credentials",level:3},{value:"Azure Storage",id:"azure-storage",level:4},{value:"AWS",id:"aws",level:4}],h={toc:p},d="wrapper";function m(e){var t=e.components,n=(0,r.Z)(e,i);return(0,o.kt)(d,(0,a.Z)({},h,n,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("p",null,"Rush has always supported an ",(0,o.kt)("a",{parentName:"p",href:"/pages/advanced/incremental_builds"},"incremental build")," analyzer that\nenables ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," to skip projects whose input files have not changed since the last build.\nIt can also be used with custom commands by enabling the ",(0,o.kt)("inlineCode",{parentName:"p"},"incremental")," flag in ",(0,o.kt)("strong",{parentName:"p"},"custom-commands.json"),".\nWe call this the ",(0,o.kt)("strong",{parentName:"p"},'"output preservation"')," strategy for incremental builds. Because the build output\nis not saved anywhere, a full rebuild is generally still required when checking out a different branch."),(0,o.kt)("p",null,"Rush's ",(0,o.kt)("strong",{parentName:"p"},"build cache")," improves on this by creating a tar archive of each project's build outputs.\nThe archive is cached so that later, if ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," can find a match in the cache, it can extract the archive\ninstead of building that project. This can provide dramatic speedups, for example reducing a 30 minute build time\nto 30 seconds. We call this the ",(0,o.kt)("strong",{parentName:"p"},'"cache restoration"')," strategy for incremental builds."),(0,o.kt)("p",null,"The build cache archives are stored in two places:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"In a cache folder on your local disk.")," This way you can switch between different branches without\nlosing your incremental build state. You can even configure a centralized folder to be shared between\nmultiple enlistments on your machine. The default location is ",(0,o.kt)("strong",{parentName:"p"},"common/temp/build-cache"),".")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"In a cloud-hosted storage container. (Optional)")," In a typical setup, the CI system would be configured to write\nto cloud storage, and individual users are granted read-only access. For example, each time a PR is merged into\nthe ",(0,o.kt)("inlineCode",{parentName:"p"},"main")," branch, the CI system builds that baseline and uploads it to cloud storage. Even for a user who\nis doing ",(0,o.kt)("inlineCode",{parentName:"p"},"git clone")," for the first time, their ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," will be very fast."))),(0,o.kt)("h2",{id:"enabling-the-local-disk-cache"},"Enabling the local disk cache"),(0,o.kt)("p",null,"The build cache feature is enabled using the ",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/build-cache_json"},"build-cache.json"),"\nconfig file. You can copy the template from the website or use ",(0,o.kt)("inlineCode",{parentName:"p"},"rush init")," to create this file."),(0,o.kt)("p",null,"To enable the basic local disk cache, add these two settings:"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"common/config/rush/build-cache.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'{\n . . .\n /**\n * (Required) Set this to true to enable the build cache feature.\n *\n * See https://rushjs.io/pages/maintainer/build_cache/ for details about this feature.\n */\n "buildCacheEnabled": true,\n\n /**\n * (Required) Choose where project build outputs will be cached.\n *\n * Possible values: "local-only", "azure-blob-storage", "amazon-s3"\n */\n "cacheProvider": "local-only",\n\n . . .\n}\n')),(0,o.kt)("h2",{id:"configuring-project-output-folders"},"Configuring project output folders"),(0,o.kt)("p",null,"With only this change, if you run ",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild --verbose"),", you will see this warning:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre"},"Project does not have a rush-project.json configuration file, or one provided by a rig,\nso it does not support caching.\n")),(0,o.kt)("p",null,"The build cache needs to know which folders should be stored in the tar archive. Those details vary between\ntoolchains, and are thus configured separately for each project using the\n",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/rush-project_json"},"rush-project.json")," config file."),(0,o.kt)("p",null,"For example:"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"<","your-project",">","/config/rush-project.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'{\n . . .\n\n /**\n * Specify the folders where your toolchain writes its output files. If enabled, the Rush build cache will\n * restore these folders from the cache.\n *\n * The strings are folder names under the project root folder. These folders should not be tracked by Git.\n * They must not contain symlinks.\n */\n "projectOutputFolderNames": ["lib", "dist"]\n . . .\n}\n')),(0,o.kt)("h2",{id:"configuring-project-inputs"},"Configuring project inputs"),(0,o.kt)("p",null,"By default, the following inputs are incorporated into Rush's cache key. In other words, if any of these things\nchanges, then the project must be rebuilt:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},"the hash of the source files that are under the project's folder, ignoring any files excluded by ",(0,o.kt)("inlineCode",{parentName:"p"},".gitignore"))),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},"the hashes of source files under other workspace projects that are dependencies of the project ",(0,o.kt)("br",null),"\n(applies to ",(0,o.kt)("strong",{parentName:"p"},"cache restoration")," strategy but not ",(0,o.kt)("strong",{parentName:"p"},"output preservation")," strategy)")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},"the versions of all external NPM packages that your project depends on, including indirect dependencies")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},"the Rush command-line parameters used to perform the operation"))),(0,o.kt)("p",null,"These details can be customized using the ",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/rush-project_json"},"rush-project.json")," config file.\nFor example, you can include/exclude certain glob patterns, or specify environment variables that affect the\nbuild output. It's recommended to use a ",(0,o.kt)("a",{parentName:"p",href:"https://heft.rushstack.io/pages/intro/rig_packages/"},"rig package")," to avoid\nhaving to copy ",(0,o.kt)("strong",{parentName:"p"},"rush-project.json")," into every project folder."),(0,o.kt)("blockquote",null,(0,o.kt)("p",{parentName:"blockquote"},(0,o.kt)("strong",{parentName:"p"},"Important:")," Configure these settings carefully. If a project inputs/outputs are not accurately specified,\nthen the build cache may produce incorrect or inconsistent results. For example, the restored output may\nbe missing some files. Or it may be different from what would be produced by a full rebuild. Such problems\ncan be difficult to reproduce and troubleshoot."),(0,o.kt)("p",{parentName:"blockquote"},"If you suspect that the Rush build cache may be misconfigured, try the\n",(0,o.kt)("a",{parentName:"p",href:"https://www.npmjs.com/package/rush-audit-cache-plugin"},"rush-audit-cache-plugin"),".\nIt monitors file writes during the build to identify inputs that are not part of your cache key.")),(0,o.kt)("h2",{id:"testing-the-build-cache"},"Testing the build cache"),(0,o.kt)("p",null,"Now you should see projects being cached as shown in this sample log output:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-bash"},"rush build --verbose\n")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre"},'. . .\n\n==[ example-project ]==============================================[ 1 of 5 ]==\n\nThis project was not found in the build cache.\n\nInvoking: heft test --clean\n\n. . .\n\nCaching build output folders: lib\n\nSuccessfully set cache entry.\n\n"example-project" completed successfully in 11.27 seconds.\n')),(0,o.kt)("p",null,"When we run the same command a second time, Rush extracts the archive instead of invoking the build task:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-bash"},"rush build --verbose\n")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre"},". . .\n\n==[ example-project ]==============================================[ 1 of 5 ]==\n\nBuild cache hit.\n\nClearing cached folders: lib, dist\n\nSuccessfully restored output from the build cache.\n\nexample-project was restored from the build cache.\n")),(0,o.kt)("p",null,"Note that ",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild")," will not read from cache, only ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," does. To disable writing from cache during ",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild"),",\nset the ",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/environment_vars"},(0,o.kt)("inlineCode",{parentName:"a"},"RUSH_BUILD_CACHE_WRITE_ALLOWED"))," environment variable to ",(0,o.kt)("inlineCode",{parentName:"p"},"0"),"."),(0,o.kt)("p",null,"By default, the cached tar archives are stored under your ",(0,o.kt)("strong",{parentName:"p"},"common/temp/build-cache")," folder\n(and thus will be cleaned by ",(0,o.kt)("inlineCode",{parentName:"p"},"rush purge"),"). It is safe to delete these files."),(0,o.kt)("h2",{id:"enabling-cloud-storage"},"Enabling cloud storage"),(0,o.kt)("p",null,"Currently the ",(0,o.kt)("inlineCode",{parentName:"p"},"cacheProvider")," setting provides three choices:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},'"local-only"'),": no cloud storage; archives are only kept on a local disk folder"),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},'"azure-blob-storage"'),": Microsoft Azure ",(0,o.kt)("a",{parentName:"li",href:"https://docs.microsoft.com/en-us/azure/storage/blobs/"},"blob storage container")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},'"amazon-s3"'),": Amazon ",(0,o.kt)("a",{parentName:"li",href:"https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html"},"S3 bucket"))),(0,o.kt)("p",null,"(The above providers are ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/microsoft/rushstack/tree/main/rush-plugins"},"modeled as Rush plugins"),".\nCustom build cache storage providers can be implemented in the same way.)"),(0,o.kt)("p",null,"As one example, here's how to configure an Azure blob container:"),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"common/config/rush/build-cache.json")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-js"},'{\n . . .\n /**\n * (Required) Set this to true to enable the build cache feature.\n *\n * See https://rushjs.io/pages/maintainer/build_cache/ for details about this feature.\n */\n "buildCacheEnabled": true,\n\n /**\n * (Required) Choose where project build outputs will be cached.\n *\n * Possible values: "local-only", "azure-blob-storage", "amazon-s3"\n */\n "cacheProvider": "azure-blob-storage",\n\n /**\n * Use this configuration with "cacheProvider"="azure-blob-storage"\n */\n "azureBlobStorageConfiguration": {\n /**\n * (Required) The name of the the Azure storage account to use for build cache.\n */\n "storageAccountName": "example",\n\n /**\n * The name of the container in the Azure storage account to use for build cache.\n */\n "storageContainerName": "my-container"\n\n /**\n * If set to true, allow writing to the cache. Defaults to false.\n */\n "isCacheWriteAllowed": false\n\n . . .\n')),(0,o.kt)("p",null,"Note that we have set ",(0,o.kt)("inlineCode",{parentName:"p"},'"isCacheWriteAllowed": false')," to prevent regular users from writing to the container.\n(Later, we will use an environment variable to override this for our CI job.)"),(0,o.kt)("h2",{id:"user-authentication"},"User authentication"),(0,o.kt)("p",null,"If security is not a priority for your repo, you can simplify user setup by configuring your storage container\nto allow unauthenticated anonymous access. The container is accessed via an HTTPS URL containing randomized\nhashes which are difficult to guess without access to your Git repo. This provides rudimentary\n",(0,o.kt)("a",{parentName:"p",href:"https://en.wikipedia.org/wiki/Security_through_obscurity"},"security through obscurity"),"."),(0,o.kt)("p",null,"A more security-conscious organization however will prefer to require authentication even for read-only access.\nRush provides a ",(0,o.kt)("a",{parentName:"p",href:"/pages/commands/rush_update-cloud-credentials"},"rush update-cloud-credentials"),"\ncommand to make this easy for users to set up:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-bash"},"rush update-cloud-credentials --interactive\n")),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre"},'Rush Multi-Project Build Tool 5.45.6 (unmanaged) - https://rushjs.io\nNode.js version is 12.20.1 (LTS)\n\n\nStarting "rush update-cloud-credentials"\n\n \u2554\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2557\n \u2551 To sign in, use a web browser to open the page \u2551\n \u2551 https://microsoft.com/devicelogin and enter the code XAYBQEGRK \u2551\n \u2551 to authenticate. \u2551\n \u255a\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u255d\n')),(0,o.kt)("p",null,"The credentials are stored in the user's home directory under ",(0,o.kt)("inlineCode",{parentName:"p"},"~/.rush-user/credentials.json"),"."),(0,o.kt)("h2",{id:"ci-setup"},"CI setup"),(0,o.kt)("p",null,"In a typical configuration, users have read-only access and the cache is populated by an automation account;\nfor example, a CI job that builds your ",(0,o.kt)("inlineCode",{parentName:"p"},"main")," branch after each PR is merged. In our example above, the\n",(0,o.kt)("inlineCode",{parentName:"p"},'"isCacheWriteAllowed": false')," setting is what prevents users from writing to the cache. The CI job can\noverride this by setting the ",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/environment_vars"},"RUSH_BUILD_CACHE_WRITE_ALLOWED"),"\nenvironment variable, and by providing credentials for the CI environment in the\n",(0,o.kt)("a",{parentName:"p",href:"/pages/configs/environment_vars"},"RUSH_BUILD_CACHE_CREDENTIAL")," environment variable."),(0,o.kt)("h3",{id:"credentials"},"Credentials"),(0,o.kt)("h4",{id:"azure-storage"},"Azure Storage"),(0,o.kt)("p",null,"For Azure Blob Storage, ",(0,o.kt)("inlineCode",{parentName:"p"},"RUSH_BUILD_CACHE_CREDENTIAL")," must be a SAS token serialized as query parameters.\nSee ",(0,o.kt)("a",{parentName:"p",href:"https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview"},"this article")," for details\nabout SAS tokens. You can obtain a SAS token via the ",(0,o.kt)("a",{parentName:"p",href:"https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage?tabs=azure-portal"},"Settings > Access keys"),"\npage for your storage account."),(0,o.kt)("h4",{id:"aws"},"AWS"),(0,o.kt)("p",null,"For Amazon S3, ",(0,o.kt)("inlineCode",{parentName:"p"},"RUSH_BUILD_CACHE_CREDENTIAL")," will be your AWS Access Key ID and AWS Secret Access Key separated by a colon,\nsuch as: ",(0,o.kt)("inlineCode",{parentName:"p"},":"),". You can also pass temporary session tokens required when assuming an IAM role: ",(0,o.kt)("inlineCode",{parentName:"p"},"::"),"."),(0,o.kt)("p",null,"If ",(0,o.kt)("inlineCode",{parentName:"p"},"RUSH_BUILD_CACHE_CREDENTIAL")," is not set, the build cache will attempt to read the environment vars ",(0,o.kt)("inlineCode",{parentName:"p"},"AWS_ACCESS_KEY_ID"),", ",(0,o.kt)("inlineCode",{parentName:"p"},"AWS_SECRET_ACCESS_KEY"),", and ",(0,o.kt)("inlineCode",{parentName:"p"},"AWS_SESSION_TOKEN")," that\nare commonly set via the AWS CLI or other CI tooling. However, ",(0,o.kt)("inlineCode",{parentName:"p"},"RUSH_BUILD_CACHE_CREDENTIAL")," will always take precedence if it exists."),(0,o.kt)("blockquote",null,(0,o.kt)("p",{parentName:"blockquote"},"The build cache feature is still under development. Feedback is welcome!"),(0,o.kt)("p",{parentName:"blockquote"},"Some relevant GitHub issues to follow:"),(0,o.kt)("ul",{parentName:"blockquote"},(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/microsoft/rushstack/issues/2393"},"Build cache feature #2393")," - the original feature spec"),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/microsoft/rushstack/issues/2642"},"Build Cache: split apart RUSH_BUILD_CACHE_WRITE_CREDENTIAL #2642")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/microsoft/rushstack/issues/2618"},"Allow project config to specify non-build-related files #2618")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/microsoft/rushstack/issues/2622"},'"tar" exited with code 1 while attempting to create the cache entry #2622')))))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/runtime~main.b1e683a4.js b/assets/js/runtime~main.f06fdba5.js similarity index 94% rename from assets/js/runtime~main.b1e683a4.js rename to assets/js/runtime~main.f06fdba5.js index 761a578d..8446a89d 100644 --- a/assets/js/runtime~main.b1e683a4.js +++ b/assets/js/runtime~main.f06fdba5.js @@ -1 +1 @@ -(()=>{"use strict";var e,a,c,d,f,b={},t={};function r(e){var a=t[e];if(void 0!==a)return a.exports;var c=t[e]={exports:{}};return b[e].call(c.exports,c,c.exports,r),c.exports}r.m=b,e=[],r.O=(a,c,d,f)=>{if(!c){var b=1/0;for(i=0;i=f)&&Object.keys(r.O).every((e=>r.O[e](c[o])))?c.splice(o--,1):(t=!1,f0&&e[i-1][2]>f;i--)e[i]=e[i-1];e[i]=[c,d,f]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},c=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,d){if(1&d&&(e=this(e)),8&d)return e;if("object"==typeof e&&e){if(4&d&&e.__esModule)return e;if(16&d&&"function"==typeof e.then)return e}var f=Object.create(null);r.r(f);var b={};a=a||[null,c({}),c([]),c(c)];for(var t=2&d&&e;"object"==typeof t&&!~a.indexOf(t);t=c(t))Object.getOwnPropertyNames(t).forEach((a=>b[a]=()=>e[a]));return b.default=()=>e,r.d(f,b),f},r.d=(e,a)=>{for(var c in a)r.o(a,c)&&!r.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:a[c]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,c)=>(r.f[c](e,a),a)),[])),r.u=e=>"assets/js/"+({53:"935f2afb",328:"235044f7",404:"4438d6ba",471:"0684aa34",514:"90ddd12c",528:"0621135e",554:"d0002971",607:"cd7aa8bf",647:"e3035796",769:"577e77e8",887:"3e2d6682",1044:"0765952b",1122:"846c8d6e",1299:"04c3341c",1322:"a8f877c2",1400:"df160fbc",1442:"a0380121",1815:"5e6284ec",1949:"282c1a37",2140:"233c0c3f",2377:"1dc5c5b7",2440:"7ccd1f8a",2563:"2ed09d84",2570:"02ccd5d4",2583:"e4f5d984",2692:"223e0a36",2722:"eef550e9",2751:"7bc9a246",2823:"7b619af1",3034:"3d9b5d3d",3060:"c9322d33",3173:"fc5d18da",3224:"33a22dbe",3237:"1df93b7f",3523:"68b67c52",3566:"a3435be8",3904:"e541189a",3951:"3020617b",4044:"28dd16ce",4070:"c4f4e2a2",4199:"75321ab6",4288:"06aed492",4290:"d1ff4259",4315:"5b152299",4599:"6d08bb7e",4656:"571dcc93",4668:"dd2d64b6",4696:"c1874168",4708:"35c43f5f",4723:"6a5786be",4794:"e439323c",4973:"a6ae31b5",5244:"62a372f1",5333:"182eac2e",5418:"1c28e8c2",5584:"5aaad5b7",5659:"bd6bf340",5711:"a483313a",5964:"3579650a",6016:"d9ccc361",6073:"ad372154",6078:"6b59883c",6165:"e33f9b2e",6202:"cbd0bb2d",6218:"d8d12fe7",6225:"30925530",6339:"d98d853d",6557:"8edc8e08",6640:"0fc792b0",6746:"10a14b75",6969:"6ae68ea7",7029:"95a336c6",7194:"a5720c04",7357:"9949baf9",7467:"04cbcf03",7603:"aa9a0c9f",7651:"ebea99ed",7722:"2970f5d1",7918:"17896441",7920:"1a4e3797",8149:"fc35d859",8179:"8f311749",8246:"f5155a44",8277:"063a13ec",8400:"d88be1c1",8413:"3ac5f93e",8649:"f653bd9f",8661:"438f83e3",8764:"65cd7bc2",8791:"bad14213",8848:"f5b5f31d",8922:"57a267e5",9066:"0c7c0fa8",9122:"7bc8bbc0",9184:"dd413e20",9190:"dbf9ac6b",9329:"44c7a5f9",9361:"b93162f9",9514:"1be78505",9624:"5d4477f0",9672:"9279c390",9798:"74b61b4b",9871:"2aaefaac"}[e]||e)+"."+{53:"d71d98d5",328:"94b13d2d",404:"d6a552db",471:"50e168df",514:"1b808413",528:"1f067c3e",554:"564cf252",607:"427d6564",647:"f3cb050b",769:"ab0738a9",887:"ccd5672e",1044:"8aef515e",1122:"d671f878",1299:"2ca7703a",1322:"f4783669",1400:"e50f0b92",1442:"a092dc8a",1815:"77ac0eb1",1949:"9c34ba06",2140:"f67ff391",2377:"f10a3e9e",2440:"f6c0ebf0",2563:"e9a19000",2570:"aefa393c",2583:"5bdf0329",2692:"f63335a1",2722:"82bef283",2751:"25626dac",2823:"e5e644ad",2832:"0d9a94f2",2928:"9d23e8f2",3034:"1f146f9b",3060:"22fc8ded",3173:"e01e4d51",3224:"b08b75f1",3237:"00c2849c",3523:"98deeedc",3566:"bd85f904",3904:"f5e75793",3951:"5c3423f6",4044:"25c239fd",4070:"37176b3e",4199:"08c274dd",4288:"368d8cbc",4290:"5289cd18",4315:"b8c4c9ed",4391:"e2e60112",4599:"8218d3fc",4656:"79876acc",4668:"d880c294",4696:"80259771",4708:"aa3a3524",4723:"ff329ad1",4794:"c3fd771e",4973:"e0eb258f",5244:"e82a43b4",5333:"03ad7749",5418:"2c08385f",5502:"09e1c67b",5584:"c5d210b5",5659:"882ac1c7",5711:"8eb870ce",5964:"ab415ac8",6016:"d0c63308",6073:"1595ca27",6078:"812ea7a5",6165:"275a8594",6202:"eb5cbc86",6218:"0f488f2d",6225:"9e14104c",6339:"3513af17",6557:"e232ced2",6640:"ca609e18",6746:"2dbf61cc",6969:"53123f99",7029:"2cbd9d5c",7194:"78ab0997",7357:"1bbd2974",7467:"2ae81311",7603:"2e08e802",7651:"3d609d2d",7722:"26908a52",7918:"781e8e87",7920:"d74d357c",8149:"a8a4fc62",8179:"3923df19",8246:"f9f0bbb3",8277:"bd9e0590",8400:"9d165d89",8413:"9c9d7999",8649:"cf6e00d7",8661:"8ba2dab9",8764:"2d6fa7f0",8791:"68cd0730",8848:"d4d3b20a",8922:"d9558ac8",8988:"5a29583b",9042:"eabad492",9066:"9a39ac46",9122:"257c2150",9184:"712be8e4",9190:"d272aba7",9329:"06bc77c4",9361:"49447d6b",9485:"879ad254",9514:"8ffd2c13",9624:"80d9e9ca",9672:"8dd00097",9798:"ddc57431",9871:"48443af5",9970:"6f0174d1"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),d={},f="rushjs.io:",r.l=(e,a,c,b)=>{if(d[e])d[e].push(a);else{var t,o;if(void 0!==c)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var f=d[e];if(delete d[e],t.parentNode&&t.parentNode.removeChild(t),f&&f.forEach((e=>e(c))),a)return a(c)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/",r.gca=function(e){return e={17896441:"7918",30925530:"6225","935f2afb":"53","235044f7":"328","4438d6ba":"404","0684aa34":"471","90ddd12c":"514","0621135e":"528",d0002971:"554",cd7aa8bf:"607",e3035796:"647","577e77e8":"769","3e2d6682":"887","0765952b":"1044","846c8d6e":"1122","04c3341c":"1299",a8f877c2:"1322",df160fbc:"1400",a0380121:"1442","5e6284ec":"1815","282c1a37":"1949","233c0c3f":"2140","1dc5c5b7":"2377","7ccd1f8a":"2440","2ed09d84":"2563","02ccd5d4":"2570",e4f5d984:"2583","223e0a36":"2692",eef550e9:"2722","7bc9a246":"2751","7b619af1":"2823","3d9b5d3d":"3034",c9322d33:"3060",fc5d18da:"3173","33a22dbe":"3224","1df93b7f":"3237","68b67c52":"3523",a3435be8:"3566",e541189a:"3904","3020617b":"3951","28dd16ce":"4044",c4f4e2a2:"4070","75321ab6":"4199","06aed492":"4288",d1ff4259:"4290","5b152299":"4315","6d08bb7e":"4599","571dcc93":"4656",dd2d64b6:"4668",c1874168:"4696","35c43f5f":"4708","6a5786be":"4723",e439323c:"4794",a6ae31b5:"4973","62a372f1":"5244","182eac2e":"5333","1c28e8c2":"5418","5aaad5b7":"5584",bd6bf340:"5659",a483313a:"5711","3579650a":"5964",d9ccc361:"6016",ad372154:"6073","6b59883c":"6078",e33f9b2e:"6165",cbd0bb2d:"6202",d8d12fe7:"6218",d98d853d:"6339","8edc8e08":"6557","0fc792b0":"6640","10a14b75":"6746","6ae68ea7":"6969","95a336c6":"7029",a5720c04:"7194","9949baf9":"7357","04cbcf03":"7467",aa9a0c9f:"7603",ebea99ed:"7651","2970f5d1":"7722","1a4e3797":"7920",fc35d859:"8149","8f311749":"8179",f5155a44:"8246","063a13ec":"8277",d88be1c1:"8400","3ac5f93e":"8413",f653bd9f:"8649","438f83e3":"8661","65cd7bc2":"8764",bad14213:"8791",f5b5f31d:"8848","57a267e5":"8922","0c7c0fa8":"9066","7bc8bbc0":"9122",dd413e20:"9184",dbf9ac6b:"9190","44c7a5f9":"9329",b93162f9:"9361","1be78505":"9514","5d4477f0":"9624","9279c390":"9672","74b61b4b":"9798","2aaefaac":"9871"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,c)=>{var d=r.o(e,a)?e[a]:void 0;if(0!==d)if(d)c.push(d[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var f=new Promise(((c,f)=>d=e[a]=[c,f]));c.push(d[2]=f);var b=r.p+r.u(a),t=new Error;r.l(b,(c=>{if(r.o(e,a)&&(0!==(d=e[a])&&(e[a]=void 0),d)){var f=c&&("load"===c.type?"missing":c.type),b=c&&c.target&&c.target.src;t.message="Loading chunk "+a+" failed.\n("+f+": "+b+")",t.name="ChunkLoadError",t.type=f,t.request=b,d[1](t)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,c)=>{var d,f,[b,t,o]=c,n=0;if(b.some((a=>0!==e[a]))){for(d in t)r.o(t,d)&&(r.m[d]=t[d]);if(o)var i=o(r)}for(a&&a(c);n{"use strict";var e,a,c,d,f,b={},t={};function r(e){var a=t[e];if(void 0!==a)return a.exports;var c=t[e]={exports:{}};return b[e].call(c.exports,c,c.exports,r),c.exports}r.m=b,e=[],r.O=(a,c,d,f)=>{if(!c){var b=1/0;for(i=0;i=f)&&Object.keys(r.O).every((e=>r.O[e](c[o])))?c.splice(o--,1):(t=!1,f0&&e[i-1][2]>f;i--)e[i]=e[i-1];e[i]=[c,d,f]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},c=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,d){if(1&d&&(e=this(e)),8&d)return e;if("object"==typeof e&&e){if(4&d&&e.__esModule)return e;if(16&d&&"function"==typeof e.then)return e}var f=Object.create(null);r.r(f);var b={};a=a||[null,c({}),c([]),c(c)];for(var t=2&d&&e;"object"==typeof t&&!~a.indexOf(t);t=c(t))Object.getOwnPropertyNames(t).forEach((a=>b[a]=()=>e[a]));return b.default=()=>e,r.d(f,b),f},r.d=(e,a)=>{for(var c in a)r.o(a,c)&&!r.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:a[c]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,c)=>(r.f[c](e,a),a)),[])),r.u=e=>"assets/js/"+({53:"935f2afb",328:"235044f7",404:"4438d6ba",471:"0684aa34",514:"90ddd12c",528:"0621135e",554:"d0002971",607:"cd7aa8bf",647:"e3035796",769:"577e77e8",887:"3e2d6682",1044:"0765952b",1122:"846c8d6e",1299:"04c3341c",1322:"a8f877c2",1400:"df160fbc",1442:"a0380121",1815:"5e6284ec",1949:"282c1a37",2140:"233c0c3f",2377:"1dc5c5b7",2440:"7ccd1f8a",2563:"2ed09d84",2570:"02ccd5d4",2583:"e4f5d984",2692:"223e0a36",2722:"eef550e9",2751:"7bc9a246",2823:"7b619af1",3034:"3d9b5d3d",3060:"c9322d33",3173:"fc5d18da",3224:"33a22dbe",3237:"1df93b7f",3523:"68b67c52",3566:"a3435be8",3904:"e541189a",3951:"3020617b",4044:"28dd16ce",4070:"c4f4e2a2",4199:"75321ab6",4288:"06aed492",4290:"d1ff4259",4315:"5b152299",4599:"6d08bb7e",4656:"571dcc93",4668:"dd2d64b6",4696:"c1874168",4708:"35c43f5f",4723:"6a5786be",4794:"e439323c",4973:"a6ae31b5",5244:"62a372f1",5333:"182eac2e",5418:"1c28e8c2",5584:"5aaad5b7",5659:"bd6bf340",5711:"a483313a",5964:"3579650a",6016:"d9ccc361",6073:"ad372154",6078:"6b59883c",6165:"e33f9b2e",6202:"cbd0bb2d",6218:"d8d12fe7",6225:"30925530",6339:"d98d853d",6557:"8edc8e08",6640:"0fc792b0",6746:"10a14b75",6969:"6ae68ea7",7029:"95a336c6",7194:"a5720c04",7357:"9949baf9",7467:"04cbcf03",7603:"aa9a0c9f",7651:"ebea99ed",7722:"2970f5d1",7918:"17896441",7920:"1a4e3797",8149:"fc35d859",8179:"8f311749",8246:"f5155a44",8277:"063a13ec",8400:"d88be1c1",8413:"3ac5f93e",8649:"f653bd9f",8661:"438f83e3",8764:"65cd7bc2",8791:"bad14213",8848:"f5b5f31d",8922:"57a267e5",9066:"0c7c0fa8",9122:"7bc8bbc0",9184:"dd413e20",9190:"dbf9ac6b",9329:"44c7a5f9",9361:"b93162f9",9514:"1be78505",9624:"5d4477f0",9672:"9279c390",9798:"74b61b4b",9871:"2aaefaac"}[e]||e)+"."+{53:"d71d98d5",328:"94b13d2d",404:"d6a552db",471:"50e168df",514:"2fd03b54",528:"1f067c3e",554:"564cf252",607:"427d6564",647:"f3cb050b",769:"ab0738a9",887:"ccd5672e",1044:"8aef515e",1122:"d671f878",1299:"2ca7703a",1322:"f4783669",1400:"e50f0b92",1442:"a092dc8a",1815:"77ac0eb1",1949:"9c34ba06",2140:"f67ff391",2377:"f10a3e9e",2440:"f6c0ebf0",2563:"e9a19000",2570:"aefa393c",2583:"5bdf0329",2692:"f63335a1",2722:"82bef283",2751:"25626dac",2823:"e5e644ad",2832:"0d9a94f2",2928:"9d23e8f2",3034:"1f146f9b",3060:"22fc8ded",3173:"e01e4d51",3224:"b08b75f1",3237:"00c2849c",3523:"98deeedc",3566:"bd85f904",3904:"f5e75793",3951:"5c3423f6",4044:"25c239fd",4070:"37176b3e",4199:"08c274dd",4288:"368d8cbc",4290:"5289cd18",4315:"b8c4c9ed",4391:"e2e60112",4599:"8218d3fc",4656:"79876acc",4668:"d880c294",4696:"80259771",4708:"aa3a3524",4723:"ff329ad1",4794:"c3fd771e",4973:"a0d943ef",5244:"e82a43b4",5333:"03ad7749",5418:"2c08385f",5502:"09e1c67b",5584:"728171b9",5659:"882ac1c7",5711:"8eb870ce",5964:"ab415ac8",6016:"d0c63308",6073:"d004cc6a",6078:"812ea7a5",6165:"275a8594",6202:"eb5cbc86",6218:"0f488f2d",6225:"9e14104c",6339:"d10f8d08",6557:"e232ced2",6640:"ca609e18",6746:"2dbf61cc",6969:"53123f99",7029:"2cbd9d5c",7194:"78ab0997",7357:"1bbd2974",7467:"2ae81311",7603:"2e08e802",7651:"3d609d2d",7722:"26908a52",7918:"781e8e87",7920:"d74d357c",8149:"a8a4fc62",8179:"3923df19",8246:"f9f0bbb3",8277:"bd9e0590",8400:"9d165d89",8413:"9c9d7999",8649:"cf6e00d7",8661:"8ba2dab9",8764:"2d6fa7f0",8791:"68cd0730",8848:"d4d3b20a",8922:"d9558ac8",8988:"5a29583b",9042:"eabad492",9066:"9a39ac46",9122:"257c2150",9184:"712be8e4",9190:"d272aba7",9329:"06bc77c4",9361:"4c6e3096",9485:"879ad254",9514:"8ffd2c13",9624:"80d9e9ca",9672:"8dd00097",9798:"ddc57431",9871:"48443af5",9970:"6f0174d1"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),d={},f="rushjs.io:",r.l=(e,a,c,b)=>{if(d[e])d[e].push(a);else{var t,o;if(void 0!==c)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var f=d[e];if(delete d[e],t.parentNode&&t.parentNode.removeChild(t),f&&f.forEach((e=>e(c))),a)return a(c)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/",r.gca=function(e){return e={17896441:"7918",30925530:"6225","935f2afb":"53","235044f7":"328","4438d6ba":"404","0684aa34":"471","90ddd12c":"514","0621135e":"528",d0002971:"554",cd7aa8bf:"607",e3035796:"647","577e77e8":"769","3e2d6682":"887","0765952b":"1044","846c8d6e":"1122","04c3341c":"1299",a8f877c2:"1322",df160fbc:"1400",a0380121:"1442","5e6284ec":"1815","282c1a37":"1949","233c0c3f":"2140","1dc5c5b7":"2377","7ccd1f8a":"2440","2ed09d84":"2563","02ccd5d4":"2570",e4f5d984:"2583","223e0a36":"2692",eef550e9:"2722","7bc9a246":"2751","7b619af1":"2823","3d9b5d3d":"3034",c9322d33:"3060",fc5d18da:"3173","33a22dbe":"3224","1df93b7f":"3237","68b67c52":"3523",a3435be8:"3566",e541189a:"3904","3020617b":"3951","28dd16ce":"4044",c4f4e2a2:"4070","75321ab6":"4199","06aed492":"4288",d1ff4259:"4290","5b152299":"4315","6d08bb7e":"4599","571dcc93":"4656",dd2d64b6:"4668",c1874168:"4696","35c43f5f":"4708","6a5786be":"4723",e439323c:"4794",a6ae31b5:"4973","62a372f1":"5244","182eac2e":"5333","1c28e8c2":"5418","5aaad5b7":"5584",bd6bf340:"5659",a483313a:"5711","3579650a":"5964",d9ccc361:"6016",ad372154:"6073","6b59883c":"6078",e33f9b2e:"6165",cbd0bb2d:"6202",d8d12fe7:"6218",d98d853d:"6339","8edc8e08":"6557","0fc792b0":"6640","10a14b75":"6746","6ae68ea7":"6969","95a336c6":"7029",a5720c04:"7194","9949baf9":"7357","04cbcf03":"7467",aa9a0c9f:"7603",ebea99ed:"7651","2970f5d1":"7722","1a4e3797":"7920",fc35d859:"8149","8f311749":"8179",f5155a44:"8246","063a13ec":"8277",d88be1c1:"8400","3ac5f93e":"8413",f653bd9f:"8649","438f83e3":"8661","65cd7bc2":"8764",bad14213:"8791",f5b5f31d:"8848","57a267e5":"8922","0c7c0fa8":"9066","7bc8bbc0":"9122",dd413e20:"9184",dbf9ac6b:"9190","44c7a5f9":"9329",b93162f9:"9361","1be78505":"9514","5d4477f0":"9624","9279c390":"9672","74b61b4b":"9798","2aaefaac":"9871"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,c)=>{var d=r.o(e,a)?e[a]:void 0;if(0!==d)if(d)c.push(d[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var f=new Promise(((c,f)=>d=e[a]=[c,f]));c.push(d[2]=f);var b=r.p+r.u(a),t=new Error;r.l(b,(c=>{if(r.o(e,a)&&(0!==(d=e[a])&&(e[a]=void 0),d)){var f=c&&("load"===c.type?"missing":c.type),b=c&&c.target&&c.target.src;t.message="Loading chunk "+a+" failed.\n("+f+": "+b+")",t.name="ChunkLoadError",t.type=f,t.request=b,d[1](t)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,c)=>{var d,f,[b,t,o]=c,n=0;if(b.some((a=>0!==e[a]))){for(d in t)r.o(t,d)&&(r.m[d]=t[d]);if(o)var i=o(r)}for(a&&a(c);nRush - +
Rush StackShopBlogEvents

Rush: a scalable monorepo manager for the web

Rush makes life easier for JavaScript developers who build and publish many packages from a common Git repo. If you're looking to break up your giant application into smaller pieces, and you already realized why it doesn't work to put each package in a separate repo... then Rush is for you!

monorepo diagram
monorepo diagram

The Rush difference

These days many different tools can run "npm install" and "npm run build" in 20 different folders. What's so great about Rush?

Git repositories

Ready for large repos

Rush is built by professional engineers who maintain large production monorepos. Our job is to provide the best developer experience for our colleagues, not to convert you into a customer for a paid consulting or hosting service. The repositories we maintain contain hundreds of apps with many years of Git history. To manage this scale, Rush offers parallel builds, subset builds, incremental builds, and distributed builds.

large team

Designed for large teams

Rush provides many mechanisms for onboarding newcomers and coordinating collaboration between teams. Repo policies allow new package dependencies to be reviewed before they are accepted. Rush can enforce consistent dependency versions across your repo. Different subsets of projects can publish separately with lockstep or independent versioning strategies.

NPM phantom dependency

Reliable NPM installations

Rush's installation model leverages the PNPM package manager to eliminate the phantom dependencies and NPM doppelgangers that frustrate large scale installations. You can visualize and troubleshoot version conflicts using our Lockfile Explorer companion tool.

motorbike and tricycle

Easy to administer

When you maintain a large repo, you don't want developers opening support tickets that can't be reproduced on any other computer. Rush helps to ensure that installs and builds are completely deterministic. Even the Rush engine version is automatically installed according to your Git branch. If you define custom commands or options, they are strictly validated and documented as part of Rush's command-line help.

army knife

Turnkey solution

Tired of cobbling together your developer experience from multiple tools that never seem to integrate properly? Rush is a unified orchestrator that can install, link, build, generate change logs, publish, and bump versions. These features are designed to integrate with the broader Rush Stack suite of tools and practices.

free price tag

Open model

The Rush software is free and open source. Community contributions are welcome! We're also open-minded about your toolchain: In a Rush repo, each project folder remains fully self-contained, individually installable, and easy to relocate if needed. Relatively little effort is required to enable/disable Rush for a given set of projects.

Who's using Rush?

Azure SDK logo
Azure SDK
HBO Max logo
HBO Max
OneDrive logo
OneDrive
SharePoint logo
SharePoint
Office 365 Small Business logo
Office 365 Small Business
Windows Store logo
Windows Store
Office Web Apps logo
Office Web Apps
SimplrJS react-forms logo
SimplrJS react-forms
Telia Company logo
Telia Company
Welbi logo
Welbi
Wix logo
Wix
© 2023 Microsoft
- + \ No newline at end of file diff --git a/link/pnpm-issue-5132/index.html b/link/pnpm-issue-5132/index.html index 8ad37154..ced02890 100644 --- a/link/pnpm-issue-5132/index.html +++ b/link/pnpm-issue-5132/index.html @@ -6,13 +6,13 @@ pnpm-issue-5132 | Rush - +
Rush StackShopBlogEvents

Redirecting...

© 2023 Microsoft
- + \ No newline at end of file diff --git a/link/upgrading/index.html b/link/upgrading/index.html index a3c6410c..07c4602c 100644 --- a/link/upgrading/index.html +++ b/link/upgrading/index.html @@ -6,13 +6,13 @@ upgrading | Rush - +
Rush StackShopBlogEvents

Redirecting...

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/api/index.html b/pages/advanced/api/index.html index 27a83986..8b6cfe79 100644 --- a/pages/advanced/api/index.html +++ b/pages/advanced/api/index.html @@ -6,13 +6,13 @@ api | Rush - +
Rush StackShopBlogEvents

Redirecting...

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/compatibility_db/index.html b/pages/advanced/compatibility_db/index.html index 79a66492..39335ede 100644 --- a/pages/advanced/compatibility_db/index.html +++ b/pages/advanced/compatibility_db/index.html @@ -6,13 +6,13 @@ PNPM Compatibility DB | Rush - +
Rush StackShopBlogEvents

PNPM Compatibility DB

Both Yarn and PNPM support a feature called the Compatibility DB, which is a public database of package.json fixups. These fixups solve known issues that the official maintainer of an NPM package may be unwilling to solve. (The best practice would be to avoid such packages, but often that is impractical.) Compatibility DB fixups are similar to user-authored rules found in .pnpmfile.cjs. They are maintained with the @yarnpkg/extensions package.

PNPM's feature protects small projects from common pitfalls, but the approach has some downsides for a large monorepo:

  • Hidden magic: The fixups are bundled into the PNPM binary. When trying to coordinate complex cross-project version dependencies, it is awkward for key inputs to be in a file with no Git diff, not even viewable in the GitHub website.
  • Unnecessary coupling: Different versions of the @yarnpkg/extensions rules are bundled into different PNPM releases. This may cause churn the lockfile when upgrading or downgrading the package manager.
  • Applied last: The fixups are applied after .pnpmfile.cjs. This means the fixed up versions aren't visible to the user's own transformations or logging, and .pnpmfile.cjs is no longer the final authority about version choices.

To avoid these issues, rush install and rush update always disable the Compatibility DB feature when invoking PNPM.

Details:

  • Compatibility DB is implemented by PNPM versions >= 6.32.12, >= 7.0.1 (but not 7.0.0)
  • The ignore-compatibility-db switch is implemented in newer PNPM releases: >= 6.34.0 <7.0.01 and >= 7.9.0
  • Compatibility DB is disabled by Rush versions >= 5.76.0 if possible...
  • ..otherwise, if the switch is missing, Rush prints a warning recommending to upgrade PNPM

The Compatibility DB fixes are useful. To apply them in your Rush repo, it's recommended to copy these settings into a proper Git-tracked file such as .pnpmfile.cjs.

💡 Feature idea: Propose an automated mechanism for syncing @yarnpkg/extensions into a Git-tracked file under common/config/rush.

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/config_files/index.html b/pages/advanced/config_files/index.html index a9de7414..db2589a8 100644 --- a/pages/advanced/config_files/index.html +++ b/pages/advanced/config_files/index.html @@ -6,13 +6,13 @@ config_files | Rush - +
Rush StackShopBlogEvents

Redirecting...

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/incremental_builds/index.html b/pages/advanced/incremental_builds/index.html index 549db710..19bef88b 100644 --- a/pages/advanced/incremental_builds/index.html +++ b/pages/advanced/incremental_builds/index.html @@ -6,7 +6,7 @@ Incremental builds | Rush - + @@ -59,7 +59,7 @@ color of a button control, or some text in an error message.

The --changed-projects-only flag tells Rush to build only those projects where a file was changed:

rush build --only B

We'd invoke it like this:

# This command will rebuild B (but ignore the effects for C and D)
rush build --changed-projects-only

The --changed-projects-only is "unsafe" because errors might be encountered if the downstream projects actually did need to be rebuilt. This parameter saves time by assuming that you know better than Rush about what really needs to be built. If that assumption is incorrect, you can always do rush build to get back to a good state.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/installation_variants/index.html b/pages/advanced/installation_variants/index.html index 3c00b070..fdc72114 100644 --- a/pages/advanced/installation_variants/index.html +++ b/pages/advanced/installation_variants/index.html @@ -6,7 +6,7 @@ Installation variants | Rush - + @@ -39,7 +39,7 @@ state by running rush install without the --variant option. We call this the "default variant", because it's the same default behavior as a repo that didn't define any variants:

# Restore the original state by omitting "--variant":
rush install

Tip: If you forget which variant is active, you can look in the common/temp/current-variant.json file. If you open this file in a text editor, you should see a line like this:

{
 "variant": "old-widget-sdk"
}
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/npm_doppelgangers/index.html b/pages/advanced/npm_doppelgangers/index.html index 960f1d3b..6cdfbbdf 100644 --- a/pages/advanced/npm_doppelgangers/index.html +++ b/pages/advanced/npm_doppelgangers/index.html @@ -6,7 +6,7 @@ NPM doppelgangers | Rush - + @@ -53,7 +53,7 @@ unfortunately doppelgangers are still possible for any indirect dependencies. Whereas if you use PNPM with Rush, the doppelganger problem is fully solved (because PNPM's installation model accurately simulates a true directed acyclic graph).

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/phantom_deps/index.html b/pages/advanced/phantom_deps/index.html index 82e47317..daf66adb 100644 --- a/pages/advanced/phantom_deps/index.html +++ b/pages/advanced/phantom_deps/index.html @@ -6,7 +6,7 @@ Phantom dependencies | Rush - + @@ -81,7 +81,7 @@ sometimes find node_modules folders that aren't even under your Git working directory!

How Rush helps: Rush's got you covered. The rush install command scans all potential parent folders and issues a warning if any phantom node_modules folders are found.

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/pinned_versions/index.html b/pages/advanced/pinned_versions/index.html index 603e6b0e..f4c08da1 100644 --- a/pages/advanced/pinned_versions/index.html +++ b/pages/advanced/pinned_versions/index.html @@ -6,13 +6,13 @@ pinned_versions | Rush - +
Rush StackShopBlogEvents

Redirecting...

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/preferred_versions/index.html b/pages/advanced/preferred_versions/index.html index e2b58123..391ced2c 100644 --- a/pages/advanced/preferred_versions/index.html +++ b/pages/advanced/preferred_versions/index.html @@ -6,7 +6,7 @@ Preferred versions | Rush - + @@ -19,7 +19,7 @@ ranges. If you're encountering installation errors involving peer dependencies, we recommend to disable this behavior by setting implicitlyPreferredVersions to false in the common/config/rush/common-versions.json config file.

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/rush_files_and_folders/index.html b/pages/advanced/rush_files_and_folders/index.html index c39dd500..c1c56f81 100644 --- a/pages/advanced/rush_files_and_folders/index.html +++ b/pages/advanced/rush_files_and_folders/index.html @@ -6,13 +6,13 @@ Rush files and folders | Rush - +
Rush StackShopBlogEvents

Rush files and folders

Every Rush monorepo has a standard folder structure that is created by rush init and validated by rush update.

Configuration files​

Folder pathWhat it does
rush.jsonThe main configuration file for Rush
common/config/rush/.npmrcIf you need custom settings for "npm install" (e.g. NPM registry mappings), put them in this file. Rush will copy this file into the common/temp/ folder.
common/config/rush/.npmrc-publishUsed instead of .npmrc for publishing operations.
common/config/artifactory.jsonConfiguration for Rush integration with JFrog Artifactory services.
common/config/build-cache.jsonConfiguration for Rush's Build cache
common/config/rush/command-line.jsonUsed to define custom commands.
common/config/rush/common-versions.jsonUsed to specify versions that affect all projects in a repo.
common/config/rush/deploy.jsonUsed to define profiles for the rush deploy command
common/config/rush/experiments.jsonEnables experimental features of Rush
common/config/rush/npm-shrinkwrap.jsonThe shrinkwrap file when your package manager is NPM. This is the common shrinkwrap file that applies to all projects in the Rush repo. For more information, see "What is this "shrinkwrap file" in the Everyday commands section.
common/config/rush/rush-plugins.jsonSpecifies Rush plugins to be loaded for the monorepo.
common/config/rush/pnpm-lock.yamlThe shrinkwrap file when your package manager is PNPM.
common/config/rush/yarn.lockThe shrinkwrap file when your package manager is Yarn.
common/config/rush/browser-approved-packages.jsonUsed by the approvedPackagesPolicy setting from rush.json
common/config/rush/nonbrowser-approved-packages.jsonUsed by the approvedPackagesPolicy setting from rush.json
common/config/rush/pnpm-config.jsonConfiguration specific to the PNPM package manager
common/config/rush/version-policies.jsonDefines the rush version and rush publish workflows.

Standard Rush folders​

Folder pathWhat it does
common/autoinstallers/...Autoinstaller projects are created under this folder
common/changes/...Stores change files created by the rush change command and consumed by the rush version command.
common/deploy/...The rush init-deploy creates deployment configurations under this folder.
common/git-hooks/...Rush's git hook scripts are defined here
common/pnpm-patches/...The rush-pnpm commit-patch command stores package patch files under this folder
common/scripts/install-run-rush.jsCI bootstrap script for invoking rush. The rush update generates this file, which should be committed to Git. See Enabling CI builds for details.
common/scripts/install-run-rush-pnpm.jsCI bootstrap script for invoking rush-pnpm.
common/scripts/install-run-rushx.jsCI bootstrap script for invoking rushx.
common/scripts/install-run.jsCI bootstrap script for invoking arbitrary NPM packages.

Temporary files created by Rush​

Folder pathWhat it does
common/temp/build-cache/...Default storage location for Rush's Build cache
common/temp/install-run/...Storage for the install-run.js and install-run-rush.js scripts. See Enabling CI builds.
common/temp/node_modules/...The installed packages. This is a plain old npm install output, with no symlinks in this tree.
common/temp/npm-cache/...A local NPM cache will be created here. Rush does not use the global NPM cache due to its concurrency problems.
common/temp/npm-local/...If the NPM package manager is selected, this is a symlink to Rush's global install of the version specified in rush.json.
common/temp/npm-tmp/...Temporary files created by NPM during installation.
common/temp/patches/...The rush-pnpm patch command creates patch files under this temporary folder (which rush-pnpm commit-patch will copy to common/pnpm-patches)
common/temp/pnpm-local/...If the PNPM package manager is selected, this is a symlink to Rush's global install of the version specified in rush.json.
common/temp/pnpm-store/...If the PNPM package manager is selected, this is the default location of the PNPM store. (It can be redirected using the RUSH_PNPM_STORE_PATH environment variable.)
common/temp/projects/...Synthetic projects referenced by common/temp/package.json.
common/temp/rush-recycler/...Used to speed up recursive deletes.
common/temp/telemetry/...Stores telemetry output saved by Rush when telemetryEnabled=true in rush.json
common/temp/yarn-local/...If the Yarn package manager is selected, this is a symlink to Rush's global install of the version specified in rush.json.
common/temp/last-install.flagDon't worry about this file. It tracks the timestamp of the last successful rush install.
common/temp/package.jsonThe common package definition.
common/temp/repo-state.jsonGenerated by the preventManualShrinkwrapChanges setting from pnpm-config.json
common/temp/rush-link.jsonDon't worry about this file. It is created whenever you run rush link, and read by later commands such as "rush build".
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/advanced/watch_mode/index.html b/pages/advanced/watch_mode/index.html index 294d36a3..79bbdf2c 100644 --- a/pages/advanced/watch_mode/index.html +++ b/pages/advanced/watch_mode/index.html @@ -6,7 +6,7 @@ Using watch mode | Rush - + @@ -40,7 +40,7 @@ helpful:

  • @telia/rush-select is an interactive dashboard for monitoring Rush projects and selecting what to rebuild.

  • rush-dev-watcher is a simple but useful script from Daniel Imfeld that performs an initial build and then launches multiple watchers.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/best_practices/change_logs/index.html b/pages/best_practices/change_logs/index.html index 742ef990..37ed6da0 100644 --- a/pages/best_practices/change_logs/index.html +++ b/pages/best_practices/change_logs/index.html @@ -6,13 +6,13 @@ Authoring change logs | Rush - +
Rush StackShopBlogEvents

Authoring change logs

When publishing an NPM package, it is common practice to include a CHANGELOG.md file to inform your consumers about bug fixes, new features, and changed or removed functionality. Rush automates this using the rush change command. This command should be run once you are ready to merge your PR, after all your changes have been committed to the branch. It analyzes the changes in your branch and (when necessary) prompts you to write human-readable descriptions of your changes.

The way in which you phrase your description is important. You don't want to be overly concise or specific, you don't want to reveal private information, and you want the description to be as helpful as possible. We recommend to err on the side of readability. Ask yourself:

  • "How is my change relevant to a third-party developer?"
  • "Could it break them?"
  • "Does it fix a bug that's been annoying them?"
  • "Is it a new feature for them to try?"

In some workflows, a human editor will review the change logs before they are published, however everyone should do their best to ensure that the content is clear and professional.

  • Use the present simple tense using the imperative ("command") mood.

  • Write from the perspective of an external audience who may be unfamiliar with implementation details of your package

  • Focus on scenario outcomes ("Searching now supports wildcards") instead of code changes ("Added regular expression support to SearchHelper class")

  • Start with a verb. These verbs are recommended:

    • Add - when you introduce or expose a new feature, property, class, UI, etc.
    • Remove - when you fully removed something and it can no longer be used.
    • Deprecate - when you plan on removing something, but it is still accessible.
    • Fix an issue with/where... - when you fixed a bug.
    • Improve - when you made an existing thing better.
    • Update - when you refresh something, but don't necessarily make it better.
    • Upgrade - when upgrading the version of a dependency.
    • Initial/Beta release of ... - when releasing a brand-new feature.

  • Don't use the word bug. Use issue instead.

  • Don't use shorthand words or acronyms, unless they are widely recognized (e.g. "HTTP")

  • Use correct spelling and grammar. The CHANGELOG.md is part of your package's published documentation.

  • When referring to public API changes, use the () suffix to indicate a function name, e.g. setSomethingOnWebpart()

  • When referring to public API changes, use backticks (` `) around class and property names.

  • When documenting an upgrade, indicate the old and new version. For example: "Upgraded widget-library from 1.0.2 to 2.0.1"

  • If fixing a GitHub issue, consider adding the issue URL in parentheses.

  • Don't add a trailing period unless you have two or more sentences.

Example Change Log Messages​

Here are some hypothetical change log messages that might be provided to rush change:

  • Add "buttonColor" to the button manifest schema
  • Remove support for older mobile web browsers as described in the README.md
  • Deprecate the doSomething() API function. Use doSomethingBetter() instead.
  • Fix an issue where "ExampleWidget" API did not handle dates correctly
  • Improve the diagnostic logging when running in advanced mode
  • Upgrade from React 15 to React 16
  • Initial release of the flexible panels feature
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush-pnpm/index.html b/pages/commands/rush-pnpm/index.html index f3dd2b1b..2ea29f33 100644 --- a/pages/commands/rush-pnpm/index.html +++ b/pages/commands/rush-pnpm/index.html @@ -6,7 +6,7 @@ rush-pnpm | Rush - + @@ -18,7 +18,7 @@ incompatible with Rush's enhancements.

To avoid these problems, use rush-pnpm in your Rush repo wherever you would normally use pnpm. The @microsoft/rush NPM package includes the rush-pnpm binary, which is a drop-in replacement for the pnpm command. It provides the following features:

  • sets up the correct context/environment so that PNPM commands work correctly
  • reports an error for operations that are known to be incompatible with Rush
  • reports a warning for operations that may be unsafe with Rush
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_add/index.html b/pages/commands/rush_add/index.html index b054e109..0fe075ac 100644 --- a/pages/commands/rush_add/index.html +++ b/pages/commands/rush_add/index.html @@ -6,13 +6,13 @@ rush add | Rush - +
Rush StackShopBlogEvents

rush add

usage: rush add [-h] -p PACKAGE [--exact] [--caret] [--dev] [-m] [-s] [--all]

Adds specified package(s) to the dependencies of the current project (as
determined by the current working directory) and then runs "rush update". If
no version is specified, a version will be automatically detected (typically
either the latest version or a version that won't break the
"ensureConsistentVersions" policy). If a version range (or a workspace range)
is specified, the latest version in the range will be used. The version will
be automatically prepended with a tilde, unless the "--exact" or "--caret"
flags are used. The "--make-consistent" flag can be used to update all
packages with the dependency.

Optional arguments:
  -h, --help            Show this help message and exit.
  -p PACKAGE, --package PACKAGE
                        (Required) The name of the package which should be
                        added as a dependency. A SemVer version specifier can
                        be appended after an "@" sign. WARNING: Symbol
                        characters are usually interpreted by your shell, so
                        it's recommended to use quotes. For example, write
                        "rush add --package "example@^1.2.3"" instead of
                        "rush add --package example@^1.2.3". To add multiple
                        packages, write "rush add --package foo --package
                        bar".
  --exact               If specified, the SemVer specifier added to the
                        package.json will be an exact version (e.g. without
                        tilde or caret).
  --caret               If specified, the SemVer specifier added to the
                        package.json will be a prepended with a "caret"
                        specifier ("^").
  --dev                 If specified, the package will be added to the
                        "devDependencies" section of the package.json
  -m, --make-consistent
                        If specified, other packages with this dependency
                        will have their package.json files updated to use the
                        same version of the dependency.
  -s, --skip-update     If specified, the "rush update" command will not be
                        run after updating the package.json files.
  --all                 If specified, the dependency will be added to all
                        projects.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_build/index.html b/pages/commands/rush_build/index.html index ed35b993..b53194ef 100644 --- a/pages/commands/rush_build/index.html +++ b/pages/commands/rush_build/index.html @@ -6,13 +6,13 @@ rush build | Rush - +
Rush StackShopBlogEvents

rush build

usage: rush build [-h] [-p COUNT] [--timeline] [-t PROJECT] [-T PROJECT]
                  [-f PROJECT] [-o PROJECT] [-i PROJECT] [-I PROJECT]
                  [--to-version-policy VERSION_POLICY_NAME]
                  [--from-version-policy VERSION_POLICY_NAME] [-v] [-c]
                  [--ignore-hooks]


This command is similar to "rush rebuild", except that "rush build" performs
an incremental build. In other words, it only builds projects whose source
files have changed since the last successful build. The analysis requires a
Git working tree, and only considers source files that are tracked by Git and
whose path is under the project folder. (For more details about this
algorithm, see the documentation for the "package-deps-hash" NPM package.)
The incremental build state is tracked in a per-project folder called ".
rush/temp" which should NOT be added to Git. The build command is tracked by
the "arguments" field in the "package-deps_build.json" file contained
therein; a full rebuild is forced whenever the command has changed (e.g.
"--production" or not).

Optional arguments:
  -h, --help            Show this help message and exit.
  -p COUNT, --parallelism COUNT
                        Specifies the maximum number of concurrent processes
                        to launch during a build. The COUNT should be a
                        positive integer, a percentage value (eg. "50%") or
                        the word "max" to specify a count that is equal to
                        the number of CPU cores. If this parameter is omitted,
                         then the default value depends on the operating
                        system and number of CPU cores. This parameter may
                        alternatively be specified via the RUSH_PARALLELISM
                        environment variable.
  --timeline            After the build is complete, print additional
                        statistics and CPU usage information, including an
                        ASCII chart of the start and stop times for each
                        operation.
  -t PROJECT, --to PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--to" parameter expands
                        this selection to include PROJECT and all its
                        dependencies. "." can be used as shorthand for the
                        project in the current working directory. For details,
                         refer to the website article "Selecting subsets of
                        projects".
  -T PROJECT, --to-except PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--to-except" parameter
                        expands this selection to include all dependencies of
                        PROJECT, but not PROJECT itself. "." can be used as
                        shorthand for the project in the current working
                        directory. For details, refer to the website article
                        "Selecting subsets of projects".
  -f PROJECT, --from PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--from" parameter expands
                        this selection to include PROJECT and all projects
                        that depend on it, plus all dependencies of this set.
                        "." can be used as shorthand for the project in the
                        current working directory. For details, refer to the
                        website article "Selecting subsets of projects".
  -o PROJECT, --only PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--only" parameter expands
                        this selection to include PROJECT; its dependencies
                        are not added. "." can be used as shorthand for the
                        project in the current working directory. Note that
                        this parameter is "unsafe" as it may produce a
                        selection that excludes some dependencies. For
                        details, refer to the website article "Selecting
                        subsets of projects".
  -i PROJECT, --impacted-by PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--impacted-by" parameter
                        expands this selection to include PROJECT and any
                        projects that depend on PROJECT (and thus might be
                        broken by changes to PROJECT). "." can be used as
                        shorthand for the project in the current working
                        directory. Note that this parameter is "unsafe" as it
                        may produce a selection that excludes some
                        dependencies. For details, refer to the website
                        article "Selecting subsets of projects".
  -I PROJECT, --impacted-by-except PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--impacted-by-except"
                        parameter works the same as "--impacted-by" except
                        that PROJECT itself is not added to the selection. ".
                        " can be used as shorthand for the project in the
                        current working directory. Note that this parameter
                        is "unsafe" as it may produce a selection that
                        excludes some dependencies. For details, refer to the
                        website article "Selecting subsets of projects".
  --to-version-policy VERSION_POLICY_NAME
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. The "--to-version-policy"
                        parameter is equivalent to specifying "--to" for each
                        of the projects belonging to VERSION_POLICY_NAME. For
                        details, refer to the website article "Selecting
                        subsets of projects".
  --from-version-policy VERSION_POLICY_NAME
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. The "--from-version-policy"
                        parameter is equivalent to specifying "--from" for
                        each of the projects belonging to VERSION_POLICY_NAME.
                         For details, refer to the website article "Selecting
                        subsets of projects".
  -v, --verbose         Display the logs during the build, rather than just
                        displaying the build status summary
  -c, --changed-projects-only
                        Normally the incremental build logic will rebuild
                        changed projects as well as any projects that
                        directly or indirectly depend on a changed project.
                        Specify "--changed-projects-only" to ignore dependent
                        projects, only rebuilding those projects whose files
                        were changed. Note that this parameter is "unsafe";
                        it is up to the developer to ensure that the ignored
                        projects are okay to ignore.
  --ignore-hooks        Skips execution of the "eventHooks" scripts defined
                        in rush.json. Make sure you know what you are
                        skipping.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_change/index.html b/pages/commands/rush_change/index.html index ea273a67..4b2f396d 100644 --- a/pages/commands/rush_change/index.html +++ b/pages/commands/rush_change/index.html @@ -6,13 +6,13 @@ rush change | Rush - +
Rush StackShopBlogEvents

rush change

usage: rush change [-h] [-v] [--no-fetch] [-b BRANCH] [--overwrite]
                   [--email EMAIL] [--bulk] [--message MESSAGE]
                   [--bump-type {major,minor,patch,none}]


Asks a series of questions and then generates a <branchname>-<timestamp>.json
file in the common folder. The `publish` command will consume these files and
perform the proper version bumps. Note these changes will eventually be
published in a changelog.md file in each package. The possible types of
changes are: MAJOR - these are breaking changes that are not backwards
compatible. Examples are: renaming a public class, adding/removing a
non-optional parameter from a public API, or renaming an variable or function
that is exported. MINOR - these are changes that are backwards compatible
(but not forwards compatible). Examples are: adding a new public API or
adding an optional parameter to a public API PATCH - these are changes that
are backwards and forwards compatible. Examples are: Modifying a private API
or fixing a bug in the logic of how an existing API works. NONE - these are
changes that are backwards and forwards compatible and don't require an
immediate release. Examples are: Modifying dev tooling configuration like
eslint. HOTFIX (EXPERIMENTAL) - these are changes that are hotfixes targeting
a specific older version of the package. When a hotfix change is added, other
changes will not be able to increment the version number. Enable this feature
by setting 'hotfixChangeEnabled' in your rush.json.

Optional arguments:
  -h, --help            Show this help message and exit.
  -v, --verify          Verify the change file has been generated and that it
                        is a valid JSON file
  --no-fetch            Skips fetching the baseline branch before running
                        "git diff" to detect changes.
  -b BRANCH, --target-branch BRANCH
                        If this parameter is specified, compare the checked
                        out branch with the specified branch to determine
                        which projects were changed. If this parameter is not
                        specified, the checked out branch is compared against
                        the "main" branch.
  --overwrite           If a changefile already exists, overwrite without
                        prompting (or erroring in --bulk mode).
  --email EMAIL         The email address to use in changefiles. If this
                        parameter is not provided, the email address will be
                        detected or prompted for in interactive mode.
  --bulk                If this flag is specified, apply the same change
                        message and bump type to all changed projects. The
                        --message and the --bump-type parameters must be
                        specified if the --bulk parameter is specified
  --message MESSAGE     The message to apply to all changed projects if the
                        --bulk flag is provided.
  --bump-type {major,minor,patch,none}
                        The bump type to apply to all changed projects if the
                        --bulk flag is provided.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_check/index.html b/pages/commands/rush_check/index.html index b06c254a..5c7a4840 100644 --- a/pages/commands/rush_check/index.html +++ b/pages/commands/rush_check/index.html @@ -6,13 +6,13 @@ rush check | Rush - +
Rush StackShopBlogEvents

rush check

usage: rush check [-h] [--variant VARIANT] [--json] [--verbose]

Checks each project's package.json files and ensures that all dependencies
are of the same version throughout the repository.

Optional arguments:
  -h, --help         Show this help message and exit.
  --variant VARIANT  Run command using a variant installation configuration.
                     This parameter may alternatively be specified via the
                     RUSH_VARIANT environment variable.
  --json             If this flag is specified, output will be in JSON format.
  --verbose          If this flag is specified, long lists of package names
                     will not be truncated. This has no effect if the --json
                     flag is also specified.
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_deploy/index.html b/pages/commands/rush_deploy/index.html index 3def67d1..09d4e75f 100644 --- a/pages/commands/rush_deploy/index.html +++ b/pages/commands/rush_deploy/index.html @@ -6,13 +6,13 @@ rush deploy | Rush - +
Rush StackShopBlogEvents

rush deploy

usage: rush deploy [-h] [-p PROJECT_NAME] [-s SCENARIO_NAME] [--overwrite]
                   [-t PATH] [--create-archive ARCHIVE_PATH]


After building the repo, "rush deploy" can be used to prepare a deployment by
copying a subset of Rush projects and their dependencies to a target folder,
which can then be uploaded to a production server. The "rush deploy" behavior
is specified by a scenario config file that must be created first, using the
"rush init-deploy" command.

Optional arguments:
  -h, --help            Show this help message and exit.
  -p PROJECT_NAME, --project PROJECT_NAME
                        Specifies the name of the main Rush project to be
                        deployed. It must appear in the
                        "deploymentProjectNames" setting in the deployment
                        config file.
  -s SCENARIO_NAME, --scenario SCENARIO_NAME
                        By default, the deployment configuration is specified
                        in "common/config/rush/deploy.json". You can use
                        "--scenario" to specify an alternate name. The name
                        must be lowercase and separated by dashes. For
                        example, if SCENARIO_NAME is "web", then the config
                        file would be "common/config/rush/deploy-web.json".
  --overwrite           By default, deployment will fail if the target folder
                        is not empty. SPECIFYING THIS FLAG WILL RECURSIVELY
                        DELETE EXISTING CONTENTS OF THE TARGET FOLDER.
  -t PATH, --target-folder PATH
                        By default, files are deployed to the "common/deploy"
                        folder inside the Rush repo. Use this parameter to
                        specify a different location. WARNING: USE CAUTION
                        WHEN COMBINING WITH "--overwrite". This parameter may
                        alternatively be specified via the
                        RUSH_DEPLOY_TARGET_FOLDER environment variable.
  --create-archive ARCHIVE_PATH
                        If specified, after the deployment has been prepared,
                        "rush deploy" will create an archive containing the
                        contents of the target folder. The newly created
                        archive file will be placed according to the
                        designated path, relative to the target folder.
                        Supported file extensions: .zip

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_init-autoinstaller/index.html b/pages/commands/rush_init-autoinstaller/index.html index a5788e05..63ddc780 100644 --- a/pages/commands/rush_init-autoinstaller/index.html +++ b/pages/commands/rush_init-autoinstaller/index.html @@ -6,13 +6,13 @@ rush init-autoinstaller | Rush - +
Rush StackShopBlogEvents

rush init-autoinstaller

usage: rush init-autoinstaller [-h] --name AUTOINSTALLER_NAME

Use this command to initialize a new autoinstaller folder. Autoinstallers
provide a way to manage a set of related dependencies that are used for
scripting scenarios outside of the usual "rush install" context. See the
command-line.json documentation for an example.

Optional arguments:
  -h, --help            Show this help message and exit.
  --name AUTOINSTALLER_NAME
                        Specifies the name of the autoinstaller folder, which
                        must conform to the naming rules for NPM packages.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_init-deploy/index.html b/pages/commands/rush_init-deploy/index.html index 2df51a6d..cf8cd46a 100644 --- a/pages/commands/rush_init-deploy/index.html +++ b/pages/commands/rush_init-deploy/index.html @@ -6,13 +6,13 @@ rush init-deploy | Rush - +
Rush StackShopBlogEvents

rush init-deploy

usage: rush init-deploy [-h] -p PROJECT_NAME [-s SCENARIO]

Use this command to initialize a new scenario config file for use with "rush
deploy". The default filename is common/config/rush/deploy.json. However, if
you need to manage multiple deployments with different settings, you can use
use "--scenario" to create additional config files.

Optional arguments:
  -h, --help            Show this help message and exit.
  -p PROJECT_NAME, --project PROJECT_NAME
                        Specifies the name of the main Rush project to be
                        deployed in this scenario. It will be added to the
                        "deploymentProjectNames" setting.
  -s SCENARIO, --scenario SCENARIO
                        By default, the deployment configuration will be
                        written to "common/config/rush/deploy.json". You can
                        use "--scenario" to specify an alternate name. The
                        name must be lowercase and separated by dashes. For
                        example, if the name is "web", then the config file
                        would be "common/config/rush/deploy-web.json".

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_init/index.html b/pages/commands/rush_init/index.html index b3067815..bd726f8a 100644 --- a/pages/commands/rush_init/index.html +++ b/pages/commands/rush_init/index.html @@ -6,13 +6,13 @@ rush init | Rush - +
Rush StackShopBlogEvents

rush init

usage: rush init [-h] [--overwrite-existing] [--rush-example-repo]

When invoked in an empty folder, this command provisions a standard set of
config file templates to start managing projects using Rush.

Optional arguments:
  -h, --help            Show this help message and exit.
  --overwrite-existing  By default "rush init" will not overwrite existing
                        config files. Specify this switch to override that.
                        This can be useful when upgrading your repo to a
                        newer release of Rush. WARNING: USE WITH CARE!
  --rush-example-repo   When copying the template config files, this
                        uncomments fragments that are used by the
                        "rush-example" GitHub repo, which is a sample
                        monorepo that illustrates many Rush features. This
                        option is primarily intended for maintaining that
                        example.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_install/index.html b/pages/commands/rush_install/index.html index d6c100ff..6d465fef 100644 --- a/pages/commands/rush_install/index.html +++ b/pages/commands/rush_install/index.html @@ -6,13 +6,13 @@ rush install | Rush - +
Rush StackShopBlogEvents

rush install

usage: rush install [-h] [-p] [--bypass-policy] [--no-link]
                    [--network-concurrency COUNT] [--debug-package-manager]
                    [--max-install-attempts NUMBER] [--ignore-hooks]
                    [--variant VARIANT] [-t PROJECT] [-T PROJECT] [-f PROJECT]
                    [-o PROJECT] [-i PROJECT] [-I PROJECT]
                    [--to-version-policy VERSION_POLICY_NAME]
                    [--from-version-policy VERSION_POLICY_NAME] [--check-only]


The "rush install" command installs package dependencies for all your
projects, based on the shrinkwrap file that is created/updated using "rush
update". (This "shrinkwrap" file stores a central inventory of all
dependencies and versions for projects in your repo. It is found in the
"common/config/rush" folder.) If the shrinkwrap file is missing or outdated
(e.g. because project package.json files have changed), "rush install" will
fail and tell you to run "rush update" instead. This read-only nature is the
main feature: Continuous integration builds should use "rush install" instead
of "rush update" to catch developers who forgot to commit their shrinkwrap
changes. Cautious people can also use "rush install" if they want to avoid
accidentally updating their shrinkwrap file.

Optional arguments:
  -h, --help            Show this help message and exit.
  -p, --purge           Perform "rush purge" before starting the installation
  --bypass-policy       Overrides enforcement of the "gitPolicy" rules from
                        rush.json (use honorably!)
  --no-link             If "--no-link" is specified, then project symlinks
                        will NOT be created after the installation completes.
                        You will need to run "rush link" manually. This flag
                        is useful for automated builds that want to report
                        stages individually or perform extra operations in
                        between the two stages. This flag is not supported
                        when using workspaces.
  --network-concurrency COUNT
                        If specified, limits the maximum number of concurrent
                        network requests. This is useful when troubleshooting
                        network failures.
  --debug-package-manager
                        Activates verbose logging for the package manager.
                        You will probably want to pipe the output of Rush to
                        a file when using this command.
  --max-install-attempts NUMBER
                        Overrides the default maximum number of install
                        attempts. The default value is 1.
  --ignore-hooks        Skips execution of the "eventHooks" scripts defined
                        in rush.json. Make sure you know what you are
                        skipping.
  --variant VARIANT     Run command using a variant installation
                        configuration. This parameter may alternatively be
                        specified via the RUSH_VARIANT environment variable.
  -t PROJECT, --to PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--to" parameter expands
                        this selection to include PROJECT and all its
                        dependencies. "." can be used as shorthand for the
                        project in the current working directory. For details,
                         refer to the website article "Selecting subsets of
                        projects".
  -T PROJECT, --to-except PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--to-except" parameter
                        expands this selection to include all dependencies of
                        PROJECT, but not PROJECT itself. "." can be used as
                        shorthand for the project in the current working
                        directory. For details, refer to the website article
                        "Selecting subsets of projects".
  -f PROJECT, --from PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--from" parameter expands
                        this selection to include PROJECT and all projects
                        that depend on it, plus all dependencies of this set.
                        "." can be used as shorthand for the project in the
                        current working directory. For details, refer to the
                        website article "Selecting subsets of projects".
  -o PROJECT, --only PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--only" parameter expands
                        this selection to include PROJECT; its dependencies
                        are not added. "." can be used as shorthand for the
                        project in the current working directory. Note that
                        this parameter is "unsafe" as it may produce a
                        selection that excludes some dependencies. For
                        details, refer to the website article "Selecting
                        subsets of projects".
  -i PROJECT, --impacted-by PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--impacted-by" parameter
                        expands this selection to include PROJECT and any
                        projects that depend on PROJECT (and thus might be
                        broken by changes to PROJECT). "." can be used as
                        shorthand for the project in the current working
                        directory. Note that this parameter is "unsafe" as it
                        may produce a selection that excludes some
                        dependencies. For details, refer to the website
                        article "Selecting subsets of projects".
  -I PROJECT, --impacted-by-except PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--impacted-by-except"
                        parameter works the same as "--impacted-by" except
                        that PROJECT itself is not added to the selection. ".
                        " can be used as shorthand for the project in the
                        current working directory. Note that this parameter
                        is "unsafe" as it may produce a selection that
                        excludes some dependencies. For details, refer to the
                        website article "Selecting subsets of projects".
  --to-version-policy VERSION_POLICY_NAME
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. The "--to-version-policy"
                        parameter is equivalent to specifying "--to" for each
                        of the projects belonging to VERSION_POLICY_NAME. For
                        details, refer to the website article "Selecting
                        subsets of projects".
  --from-version-policy VERSION_POLICY_NAME
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. The "--from-version-policy"
                        parameter is equivalent to specifying "--from" for
                        each of the projects belonging to VERSION_POLICY_NAME.
                         For details, refer to the website article "Selecting
                        subsets of projects".
  --check-only          Only check the validity of the shrinkwrap file
                        without performing an install.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_link/index.html b/pages/commands/rush_link/index.html index 0e011fbd..beeeca69 100644 --- a/pages/commands/rush_link/index.html +++ b/pages/commands/rush_link/index.html @@ -6,13 +6,13 @@ rush link | Rush - +
Rush StackShopBlogEvents

rush link

usage: rush link [-h] [-f]

Create node_modules symlinks for all projects. This operation is normally
performed automatically as part of "rush install" or "rush update". You
should only need to use "rush link" if you performed "rush unlink" for some
reason, or if you specified the "--no-link" option for "rush install" or
"rush update".

Optional arguments:
  -h, --help   Show this help message and exit.
  -f, --force  Deletes and recreates all links, even if the filesystem state
               seems to indicate that this is unnecessary.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_list/index.html b/pages/commands/rush_list/index.html index 39b39c0b..6b45a2b9 100644 --- a/pages/commands/rush_list/index.html +++ b/pages/commands/rush_list/index.html @@ -6,13 +6,13 @@ rush list | Rush - +
Rush StackShopBlogEvents

rush list

usage: rush list [-h] [-v] [-p] [--full-path] [--detailed] [--json]
                 [-t PROJECT] [-T PROJECT] [-f PROJECT] [-o PROJECT]
                 [-i PROJECT] [-I PROJECT]
                 [--to-version-policy VERSION_POLICY_NAME]
                 [--from-version-policy VERSION_POLICY_NAME]


List package names, and optionally version (--version) and path (--path) or
full path (--full-path), for projects in the current rush config.

Optional arguments:
  -h, --help            Show this help message and exit.
  -v, --version         If this flag is specified, the project version will
                        be displayed in a column along with the package name.
  -p, --path            If this flag is specified, the project path will be
                        displayed in a column along with the package name.
  --full-path           If this flag is specified, the project full path will
                        be displayed in a column along with the package name.
  --detailed            For the non --json view, if this flag is specified,
                        include path (-p), version (-v) columns along with
                        the project's applicable: versionPolicy,
                        versionPolicyName, shouldPublish, reviewPolicy, and
                        tags fields.
  --json                If this flag is specified, output will be in JSON
                        format.
  -t PROJECT, --to PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--to" parameter expands
                        this selection to include PROJECT and all its
                        dependencies. "." can be used as shorthand for the
                        project in the current working directory. For details,
                         refer to the website article "Selecting subsets of
                        projects".
  -T PROJECT, --to-except PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--to-except" parameter
                        expands this selection to include all dependencies of
                        PROJECT, but not PROJECT itself. "." can be used as
                        shorthand for the project in the current working
                        directory. For details, refer to the website article
                        "Selecting subsets of projects".
  -f PROJECT, --from PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--from" parameter expands
                        this selection to include PROJECT and all projects
                        that depend on it, plus all dependencies of this set.
                        "." can be used as shorthand for the project in the
                        current working directory. For details, refer to the
                        website article "Selecting subsets of projects".
  -o PROJECT, --only PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--only" parameter expands
                        this selection to include PROJECT; its dependencies
                        are not added. "." can be used as shorthand for the
                        project in the current working directory. Note that
                        this parameter is "unsafe" as it may produce a
                        selection that excludes some dependencies. For
                        details, refer to the website article "Selecting
                        subsets of projects".
  -i PROJECT, --impacted-by PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--impacted-by" parameter
                        expands this selection to include PROJECT and any
                        projects that depend on PROJECT (and thus might be
                        broken by changes to PROJECT). "." can be used as
                        shorthand for the project in the current working
                        directory. Note that this parameter is "unsafe" as it
                        may produce a selection that excludes some
                        dependencies. For details, refer to the website
                        article "Selecting subsets of projects".
  -I PROJECT, --impacted-by-except PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--impacted-by-except"
                        parameter works the same as "--impacted-by" except
                        that PROJECT itself is not added to the selection. ".
                        " can be used as shorthand for the project in the
                        current working directory. Note that this parameter
                        is "unsafe" as it may produce a selection that
                        excludes some dependencies. For details, refer to the
                        website article "Selecting subsets of projects".
  --to-version-policy VERSION_POLICY_NAME
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. The "--to-version-policy"
                        parameter is equivalent to specifying "--to" for each
                        of the projects belonging to VERSION_POLICY_NAME. For
                        details, refer to the website article "Selecting
                        subsets of projects".
  --from-version-policy VERSION_POLICY_NAME
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. The "--from-version-policy"
                        parameter is equivalent to specifying "--from" for
                        each of the projects belonging to VERSION_POLICY_NAME.
                         For details, refer to the website article "Selecting
                        subsets of projects".
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_publish/index.html b/pages/commands/rush_publish/index.html index 2b61121d..7278b2a5 100644 --- a/pages/commands/rush_publish/index.html +++ b/pages/commands/rush_publish/index.html @@ -6,13 +6,13 @@ rush publish | Rush - +
Rush StackShopBlogEvents

rush publish

usage: rush publish [-h] [-a] [-b BRANCH] [-p] [--add-commit-details]
                    [--regenerate-changelogs] [-r REGISTRY] [-n TOKEN]
                    [-t TAG] [--set-access-level {public,restricted}] [--pack]
                    [--release-folder FOLDER] [--include-all]
                    [--version-policy POLICY] [--prerelease-name NAME]
                    [--partial-prerelease] [--suffix SUFFIX] [--force]
                    [--apply-git-tags-on-pack] [-c COMMIT_ID]
                    [--ignore-git-hooks]


Reads and processes package publishing change requests generated by "rush
change". This will perform a read-only operation by default, printing
operations executed to the console. To commit changes and publish packages,
you must use the --commit flag and/or the --publish flag.

Optional arguments:
  -h, --help            Show this help message and exit.
  -a, --apply           If this flag is specified, the change requests will
                        be applied to package.json files.
  -b BRANCH, --target-branch BRANCH
                        If this flag is specified, applied changes and
                        deleted change requests will be committed and merged
                        into the target branch.
  -p, --publish         If this flag is specified, applied changes will be
                        published to the NPM registry.
  --add-commit-details  Adds commit author and hash to the changelog.json
                        files for each change.
  --regenerate-changelogs
                        Regenerates all changelog files based on the current
                        JSON content.
  -r REGISTRY, --registry REGISTRY
                        Publishes to a specified NPM registry. If this is
                        specified, it will prevent the current commit will
                        not be tagged.
  -n TOKEN, --npm-auth-token TOKEN
                        (DEPRECATED) Specifies the authentication token to
                        use during publishing. This parameter is deprecated
                        because command line parameters may be readable by
                        unrelated processes on a lab machine. Instead, a
                        safer practice is to pass the token via an
                        environment variable and reference it from your
                        common/config/rush/.npmrc-publish file.
  -t TAG, --tag TAG     The tag option to pass to npm publish. By default NPM
                        will publish using the 'latest' tag, even if the
                        package is older than the current latest, so in
                        publishing workflows for older releases, providing a
                        tag is important. When hotfix changes are made, this
                        parameter defaults to 'hotfix'.
  --set-access-level {public,restricted}
                        By default, when Rush invokes "npm publish" it will
                        publish scoped packages with an access level of
                        "restricted". Scoped packages can be published with
                        an access level of "public" by specifying that value
                        for this flag with the initial publication. NPM
                        always publishes unscoped packages with an access
                        level of "public". For more information, see the NPM
                        documentation for the "--access" option of "npm
                        publish".
  --pack                Packs projects into tarballs instead of publishing to
                        npm repository. It can only be used when
                        --include-all is specified. If this flag is specified,
                         NPM registry related parameters will be ignored.
  --release-folder FOLDER
                        This parameter is used with --pack parameter to
                        provide customized location for the tarballs instead
                        of the default value.
  --include-all         If this flag is specified, all packages with
                        shouldPublish=true in rush.json or with a specified
                        version policy will be published if their version is
                        newer than published version.
  --version-policy POLICY
                        Version policy name. Only projects with this version
                        policy will be published if used with --include-all.
  --prerelease-name NAME
                        Bump up to a prerelease version with the provided
                        prerelease name. Cannot be used with --suffix
  --partial-prerelease  Used with --prerelease-name. Only bump packages to a
                        prerelease version if they have changes.
  --suffix SUFFIX       Append a suffix to all changed versions. Cannot be
                        used with --prerelease-name.
  --force               If this flag is specified with --publish, packages
                        will be published with --force on npm
  --apply-git-tags-on-pack
                        If specified with --publish and --pack, git tags will
                        be applied for packages as if a publish was being run
                        without --pack.
  -c COMMIT_ID, --commit COMMIT_ID
                        Used in conjunction with git tagging -- apply git
                        tags at the commit hash specified. If not provided,
                        the current HEAD will be tagged.
  --ignore-git-hooks    Skips execution of all git hooks. Make sure you know
                        what you are skipping.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_purge/index.html b/pages/commands/rush_purge/index.html index 8674529d..799526b2 100644 --- a/pages/commands/rush_purge/index.html +++ b/pages/commands/rush_purge/index.html @@ -6,13 +6,13 @@ rush purge | Rush - +
Rush StackShopBlogEvents

rush purge

usage: rush purge [-h] [--unsafe]

The "rush purge" command is used to delete temporary files created by Rush.
This is useful if you are having problems and suspect that cache files may be
corrupt.

Optional arguments:
  -h, --help  Show this help message and exit.
  --unsafe    (UNSAFE!) Also delete shared files such as the package manager
              instances stored in the ".rush" folder in the user's home
              directory. This is a more aggressive fix that is NOT SAFE to
              run in a live environment because it will cause other
              concurrent Rush processes to fail.
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_rebuild/index.html b/pages/commands/rush_rebuild/index.html index eb22937f..dd29caed 100644 --- a/pages/commands/rush_rebuild/index.html +++ b/pages/commands/rush_rebuild/index.html @@ -6,13 +6,13 @@ rush rebuild | Rush - +
Rush StackShopBlogEvents

rush rebuild

usage: rush rebuild [-h] [-p COUNT] [--timeline] [-t PROJECT] [-T PROJECT]
                    [-f PROJECT] [-o PROJECT] [-i PROJECT] [-I PROJECT]
                    [--to-version-policy VERSION_POLICY_NAME]
                    [--from-version-policy VERSION_POLICY_NAME] [-v]
                    [--ignore-hooks]


This command assumes that the package.json file for each project contains a
"scripts" entry for "npm run build" that performs a full clean build. Rush
invokes this script to build each project that is registered in rush.json.
Projects are built in parallel where possible, but always respecting the
dependency graph for locally linked projects. The number of simultaneous
processes will be based on the number of machine cores unless overridden by
the --parallelism flag. (For an incremental build, see "rush build" instead
of "rush rebuild".)

Optional arguments:
  -h, --help            Show this help message and exit.
  -p COUNT, --parallelism COUNT
                        Specifies the maximum number of concurrent processes
                        to launch during a build. The COUNT should be a
                        positive integer, a percentage value (eg. "50%") or
                        the word "max" to specify a count that is equal to
                        the number of CPU cores. If this parameter is omitted,
                         then the default value depends on the operating
                        system and number of CPU cores. This parameter may
                        alternatively be specified via the RUSH_PARALLELISM
                        environment variable.
  --timeline            After the build is complete, print additional
                        statistics and CPU usage information, including an
                        ASCII chart of the start and stop times for each
                        operation.
  -t PROJECT, --to PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--to" parameter expands
                        this selection to include PROJECT and all its
                        dependencies. "." can be used as shorthand for the
                        project in the current working directory. For details,
                         refer to the website article "Selecting subsets of
                        projects".
  -T PROJECT, --to-except PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--to-except" parameter
                        expands this selection to include all dependencies of
                        PROJECT, but not PROJECT itself. "." can be used as
                        shorthand for the project in the current working
                        directory. For details, refer to the website article
                        "Selecting subsets of projects".
  -f PROJECT, --from PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--from" parameter expands
                        this selection to include PROJECT and all projects
                        that depend on it, plus all dependencies of this set.
                        "." can be used as shorthand for the project in the
                        current working directory. For details, refer to the
                        website article "Selecting subsets of projects".
  -o PROJECT, --only PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--only" parameter expands
                        this selection to include PROJECT; its dependencies
                        are not added. "." can be used as shorthand for the
                        project in the current working directory. Note that
                        this parameter is "unsafe" as it may produce a
                        selection that excludes some dependencies. For
                        details, refer to the website article "Selecting
                        subsets of projects".
  -i PROJECT, --impacted-by PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--impacted-by" parameter
                        expands this selection to include PROJECT and any
                        projects that depend on PROJECT (and thus might be
                        broken by changes to PROJECT). "." can be used as
                        shorthand for the project in the current working
                        directory. Note that this parameter is "unsafe" as it
                        may produce a selection that excludes some
                        dependencies. For details, refer to the website
                        article "Selecting subsets of projects".
  -I PROJECT, --impacted-by-except PROJECT
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. Each "--impacted-by-except"
                        parameter works the same as "--impacted-by" except
                        that PROJECT itself is not added to the selection. ".
                        " can be used as shorthand for the project in the
                        current working directory. Note that this parameter
                        is "unsafe" as it may produce a selection that
                        excludes some dependencies. For details, refer to the
                        website article "Selecting subsets of projects".
  --to-version-policy VERSION_POLICY_NAME
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. The "--to-version-policy"
                        parameter is equivalent to specifying "--to" for each
                        of the projects belonging to VERSION_POLICY_NAME. For
                        details, refer to the website article "Selecting
                        subsets of projects".
  --from-version-policy VERSION_POLICY_NAME
                        Normally all projects in the monorepo will be
                        processed; adding this parameter will instead select
                        a subset of projects. The "--from-version-policy"
                        parameter is equivalent to specifying "--from" for
                        each of the projects belonging to VERSION_POLICY_NAME.
                         For details, refer to the website article "Selecting
                        subsets of projects".
  -v, --verbose         Display the logs during the build, rather than just
                        displaying the build status summary
  --ignore-hooks        Skips execution of the "eventHooks" scripts defined
                        in rush.json. Make sure you know what you are
                        skipping.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_remove/index.html b/pages/commands/rush_remove/index.html index 96fa6597..7939ad6c 100644 --- a/pages/commands/rush_remove/index.html +++ b/pages/commands/rush_remove/index.html @@ -6,13 +6,13 @@ rush remove | Rush - +
Rush StackShopBlogEvents

rush remove

usage: rush remove [-h] [-s] -p PACKAGE [--all]

Removes specified package(s) from the dependencies of the current project (as
determined by the current working directory) and then runs "rush update".

Optional arguments:
  -h, --help            Show this help message and exit.
  -s, --skip-update     If specified, the "rush update" command will not be
                        run after updating the package.json files.
  -p PACKAGE, --package PACKAGE
                        The name of the package which should be removed. To
                        remove multiple packages, run "rush remove --package
                        foo --package bar".
  --all                 If specified, the dependency will be removed from all
                        projects that declare it.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_scan/index.html b/pages/commands/rush_scan/index.html index a678a9f4..d24781cf 100644 --- a/pages/commands/rush_scan/index.html +++ b/pages/commands/rush_scan/index.html @@ -6,13 +6,13 @@ rush scan | Rush - +
Rush StackShopBlogEvents

rush scan

usage: rush scan [-h] [--json] [--all]

The Node.js module system allows a project to import NPM packages without
explicitly declaring them as dependencies in the package.json file. Such
"phantom dependencies" can cause problems. Rush and PNPM use symlinks
specifically to protect against phantom dependencies. These protections may
cause runtime errors for existing projects when they are first migrated into
a Rush monorepo. The "rush scan" command is a handy tool for fixing these
errors. It scans the "./src" and "./lib" folders for import syntaxes such as
"import __ from '__'", "require('__')", and "System.import('__'). It prints a
report of the referenced packages. This heuristic is not perfect, but it can
save a lot of time when migrating projects.

Optional arguments:
  -h, --help  Show this help message and exit.
  --json      If this flag is specified, output will be in JSON format.
  --all       If this flag is specified, output will list all detected
              dependencies.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_setup/index.html b/pages/commands/rush_setup/index.html index 44f291ee..54f3ddf3 100644 --- a/pages/commands/rush_setup/index.html +++ b/pages/commands/rush_setup/index.html @@ -6,13 +6,13 @@ rush setup | Rush - +
Rush StackShopBlogEvents

rush setup

usage: rush setup [-h]

(EXPERIMENTAL) Invoke this command before working in a new repo to ensure
that any required prerequisites are installed and permissions are configured.
The initial implementation configures the NPM registry credentials. More
features will be added later.

Optional arguments:
  -h, --help  Show this help message and exit.
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_tab-complete/index.html b/pages/commands/rush_tab-complete/index.html index c22ee656..58567853 100644 --- a/pages/commands/rush_tab-complete/index.html +++ b/pages/commands/rush_tab-complete/index.html @@ -6,13 +6,13 @@ rush tab-complete | Rush - +
Rush StackShopBlogEvents

rush tab-complete

usage: rush tab-complete [-h] [--word WORD] [--position INDEX]

Provides tab completion.

Optional arguments:
  -h, --help        Show this help message and exit.
  --word WORD       The word to complete. The default value is "".
  --position INDEX  The position in the word to be completed. The default
                    value is 0.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_unlink/index.html b/pages/commands/rush_unlink/index.html index cd8c9896..b4b93b53 100644 --- a/pages/commands/rush_unlink/index.html +++ b/pages/commands/rush_unlink/index.html @@ -6,13 +6,13 @@ rush unlink | Rush - +
Rush StackShopBlogEvents

rush unlink

usage: rush unlink [-h]

This removes the symlinks created by the "rush link" command. This is useful
for cleaning a repo using "git clean" without accidentally deleting source
files, or for using standard NPM commands on a project.

Optional arguments:
  -h, --help  Show this help message and exit.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_update-autoinstaller/index.html b/pages/commands/rush_update-autoinstaller/index.html index d12c476f..4f937546 100644 --- a/pages/commands/rush_update-autoinstaller/index.html +++ b/pages/commands/rush_update-autoinstaller/index.html @@ -6,13 +6,13 @@ rush update-autoinstaller | Rush - +
Rush StackShopBlogEvents

rush update-autoinstaller

usage: rush update-autoinstaller [-h] --name AUTOINSTALLER_NAME

Use this command to regenerate the shrinkwrap file for an autoinstaller
folder.

Optional arguments:
  -h, --help            Show this help message and exit.
  --name AUTOINSTALLER_NAME
                        Specifies the name of the autoinstaller, which must
                        be one of the folders under common/autoinstallers.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_update-cloud-credentials/index.html b/pages/commands/rush_update-cloud-credentials/index.html index 05332374..7e9c1b51 100644 --- a/pages/commands/rush_update-cloud-credentials/index.html +++ b/pages/commands/rush_update-cloud-credentials/index.html @@ -6,13 +6,13 @@ rush update-cloud-credentials | Rush - +
Rush StackShopBlogEvents

rush update-cloud-credentials

usage: rush update-cloud-credentials [-h] [-i]
                                     [--credential CREDENTIAL_STRING] [-d]


(EXPERIMENTAL) If the build caching feature is configured, this command
facilitates updating the credentials used by a cloud-based provider.

Optional arguments:
  -h, --help            Show this help message and exit.
  -i, --interactive     Run the credential update operation in interactive
                        mode, if supported by the provider.
  --credential CREDENTIAL_STRING
                        A static credential, to be cached.
  -d, --delete          If specified, delete stored credentials.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_update/index.html b/pages/commands/rush_update/index.html index 8319b66d..b198e3ed 100644 --- a/pages/commands/rush_update/index.html +++ b/pages/commands/rush_update/index.html @@ -6,13 +6,13 @@ rush update | Rush - +
Rush StackShopBlogEvents

rush update

usage: rush update [-h] [-p] [--bypass-policy] [--no-link]
                   [--network-concurrency COUNT] [--debug-package-manager]
                   [--max-install-attempts NUMBER] [--ignore-hooks]
                   [--variant VARIANT] [--full] [--recheck]


The "rush update" command installs the dependencies described in your package.
json files, and updates the shrinkwrap file as needed. (This "shrinkwrap"
file stores a central inventory of all dependencies and versions for projects
in your repo. It is found in the "common/config/rush" folder.) Note that Rush
always performs a single install for all projects in your repo. You should
run "rush update" whenever you start working in a Rush repo, after you pull
from Git, and after you modify a package.json file. If there is nothing to do,
 "rush update" is instantaneous. NOTE: In certain cases "rush install" should
be used instead of "rush update" -- for details, see the command help for
"rush install".

Optional arguments:
  -h, --help            Show this help message and exit.
  -p, --purge           Perform "rush purge" before starting the installation
  --bypass-policy       Overrides enforcement of the "gitPolicy" rules from
                        rush.json (use honorably!)
  --no-link             If "--no-link" is specified, then project symlinks
                        will NOT be created after the installation completes.
                        You will need to run "rush link" manually. This flag
                        is useful for automated builds that want to report
                        stages individually or perform extra operations in
                        between the two stages. This flag is not supported
                        when using workspaces.
  --network-concurrency COUNT
                        If specified, limits the maximum number of concurrent
                        network requests. This is useful when troubleshooting
                        network failures.
  --debug-package-manager
                        Activates verbose logging for the package manager.
                        You will probably want to pipe the output of Rush to
                        a file when using this command.
  --max-install-attempts NUMBER
                        Overrides the default maximum number of install
                        attempts. The default value is 1.
  --ignore-hooks        Skips execution of the "eventHooks" scripts defined
                        in rush.json. Make sure you know what you are
                        skipping.
  --variant VARIANT     Run command using a variant installation
                        configuration. This parameter may alternatively be
                        specified via the RUSH_VARIANT environment variable.
  --full                Normally "rush update" tries to preserve your
                        existing installed versions and only makes the
                        minimum updates needed to satisfy the package.json
                        files. This conservative approach prevents your PR
                        from getting involved with package updates that are
                        unrelated to your work. Use "--full" when you really
                        want to update all dependencies to the latest
                        SemVer-compatible version. This should be done
                        periodically by a person or robot whose role is to
                        deal with potential upgrade regressions.
  --recheck             If the shrinkwrap file appears to already satisfy the
                        package.json files, then "rush update" will skip
                        invoking the package manager at all. In certain
                        situations this heuristic may be inaccurate. Use the
                        "--recheck" flag to force the package manager to
                        process the shrinkwrap file. This will also update
                        your shrinkwrap file with Rush's fixups. (To minimize
                        shrinkwrap churn, these fixups are normally performed
                        only in the temporary folder.)

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_upgrade-interactive/index.html b/pages/commands/rush_upgrade-interactive/index.html index 0ebc83ef..c0a511f5 100644 --- a/pages/commands/rush_upgrade-interactive/index.html +++ b/pages/commands/rush_upgrade-interactive/index.html @@ -6,13 +6,13 @@ rush upgrade-interactive | Rush - +
Rush StackShopBlogEvents

rush upgrade-interactive

usage: rush upgrade-interactive [-h] [--make-consistent] [-s]

Provide an interactive way to upgrade your dependencies. Running the command
will open an interactive prompt that will ask you which projects and which
dependencies you would like to upgrade. It will then update your package.json
files, and run "rush update" for you. If you are using
ensureConsistentVersions policy, upgrade-interactive will update all packages
which use the dependencies that you are upgrading and match their SemVer
range if provided. If ensureConsistentVersions is not enabled,
upgrade-interactive will only update the dependency in the package you
specify. This can be overriden by using the --make-consistent flag.

Optional arguments:
  -h, --help         Show this help message and exit.
  --make-consistent  When upgrading dependencies from a single project, also
                     upgrade dependencies from other projects.
  -s, --skip-update  If specified, the "rush update" command will not be run
                     after updating the package.json files.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rush_version/index.html b/pages/commands/rush_version/index.html index ba98ca0b..69cdb4d2 100644 --- a/pages/commands/rush_version/index.html +++ b/pages/commands/rush_version/index.html @@ -6,13 +6,13 @@ rush version | Rush - +
Rush StackShopBlogEvents

rush version

usage: rush version [-h] [-b BRANCH] [--ensure-version-policy]
                    [--override-version NEW_VERSION] [--bump]
                    [--bypass-policy] [--version-policy POLICY]
                    [--override-bump BUMPTYPE] [--override-prerelease-id ID]
                    [--ignore-git-hooks]


use this "rush version" command to ensure version policies and bump versions.

Optional arguments:
  -h, --help            Show this help message and exit.
  -b BRANCH, --target-branch BRANCH
                        If this flag is specified, changes will be committed
                        and merged into the target branch.
  --ensure-version-policy
                        Updates package versions if needed to satisfy version
                        policies.
  --override-version NEW_VERSION
                        Override the version in the specified
                        --version-policy. This setting only works for
                        lock-step version policy and when
                        --ensure-version-policy is specified.
  --bump                Bumps package version based on version policies.
  --bypass-policy       Overrides "gitPolicy" enforcement (use honorably!)
  --version-policy POLICY
                        The name of the version policy
  --override-bump BUMPTYPE
                        Overrides the bump type in the version-policy.json
                        for the specified version policy. Valid BUMPTYPE
                        values include: prerelease, patch, preminor, minor,
                        major. This setting only works for lock-step version
                        policy in bump action.
  --override-prerelease-id ID
                        Overrides the prerelease identifier in the version
                        value of version-policy.json for the specified
                        version policy. This setting only works for lock-step
                        version policy. This setting increases to new
                        prerelease id when "--bump" is provided but only
                        replaces the prerelease name when
                        "--ensure-version-policy" is provided.
  --ignore-git-hooks    Skips execution of all git hooks. Make sure you know
                        what you are skipping.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/commands/rushx/index.html b/pages/commands/rushx/index.html index 90ba0c40..5899fc70 100644 --- a/pages/commands/rushx/index.html +++ b/pages/commands/rushx/index.html @@ -6,7 +6,7 @@ rushx | Rush - + @@ -15,7 +15,7 @@ "scripts" section of the package.json file for an individual project. Any additional CLI parameters are passed only to that shell script without any validation.

Consider this very simple example project:

<my project>/package.json

{
  "name": "my-project",
  "version": "0.0.0",
  "scripts": {
    "build": "rm -Rf lib && tsc",
    "test": "jest"
  }
}

If you invoke rushx alone, it will simply display the available commands:

usage: rushx [-h]
       rushx [-q/--quiet] <command> ...

Optional arguments:
  -h, --help            Show this help message and exit.
  -q, --quiet           Hide rushx startup information.

Project commands for my-project:
  build: "rm -Rf lib && tsc"
  test:  "jest"

If you invoke rushx build, then it would run rm -Rf lib && tsc. If you add a parameter such as rushx build --verbose, it is blindly appended to the end of the string: rm -Rf lib && tsc --verbose.

rush vs rushx​

It's easy to confuse these two commands:

  • rush invokes a generic operation that affects the entire repo ("global commands") or else affects multiple projects ("bulk commands"). Such commands should be carefully designed. Rush enforces that their parameters must be validated and documented.
  • rushx performs custom operations for one single project. Although some of these are used to implement bulk commands, many of them will be helper scripts that are understood only by the developers of that particular project. Rush does not rigorously validate these commands.

Why use "rushx" instead of "pnpm run" or "npx"?​

The rushx command has similar functionality as pnpm run or npx, but with some additional benefits:

  • Ensures deterministic tooling by using the Rush version selector
  • Prepares the shell environment based on Rush's configuration
  • Implements additional validations
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/artifactory_json/index.html b/pages/configs/artifactory_json/index.html index ce5452f5..ae62a3f8 100644 --- a/pages/configs/artifactory_json/index.html +++ b/pages/configs/artifactory_json/index.html @@ -6,14 +6,14 @@ artifactory.json | Rush - +
Rush StackShopBlogEvents

artifactory.json

This is the template that rush init generates for artifactory.json:

common/config/rush/artifactory.json

/**
 * This configuration file manages Rush integration with JFrog Artifactory services.
 * More documentation is available on the Rush website: https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/artifactory.schema.json",

  "packageRegistry": {
    /**
     * (Required) Set this to "true" to enable Rush to manage tokens for an Artifactory NPM registry.
     * When enabled, "rush install" will automatically detect when the user's ~/.npmrc
     * authentication token is missing or expired.  And "rush setup" will prompt the user to
     * renew their token.
     *
     * The default value is false.
     */
    "enabled": false,

    /**
     * (Required) Specify the URL of your NPM registry.  This is the same URL that appears in
     * your .npmrc file.  It should look something like this example:
     *
     *   https://your-company.jfrog.io/your-project/api/npm/npm-private/
     */
    "registryUrl": "",

    /**
     * A list of custom strings that "rush setup" should add to the user's ~/.npmrc file at the time
     * when the token is updated.  This could be used for example to configure the company registry
     * to be used whenever NPM is invoked as a standalone command (but it's not needed for Rush
     * operations like "rush add" and "rush install", which get their mappings from the monorepo's
     * common/config/rush/.npmrc file).
     *
     * NOTE: The ~/.npmrc settings are global for the user account on a given machine, so be careful
     * about adding settings that may interfere with other work outside the monorepo.
     */
    "userNpmrcLinesToAdd": [
      // "@example:registry=https://your-company.jfrog.io/your-project/api/npm/npm-private/"
    ],

    /**
     * (Required) Specifies the URL of the Artifactory control panel where the user can generate
     * an API key.  This URL is printed after the "visitWebsite" message.
     * It should look something like this example:  https://your-company.jfrog.io/
     * Specify an empty string to suppress this line entirely.
     */
    "artifactoryWebsiteUrl": "",

    /**
     * Uncomment this line to specify the type of credential to save in the user's ~/.npmrc file.
     * The default is "password", which means the user's API token will be traded in for an
     * npm password specific to that registry. Optionally you can specify "authToken", which
     * will save the user's API token as credentials instead.
     */
    // "credentialType": "password",

    /**
     * These settings allow the "rush setup" interactive prompts to be customized, for
     * example with messages specific to your team or configuration.  Specify an empty string
     * to suppress that message entirely.
     */
    "messageOverrides": {
      /**
       * Overrides the message that normally says:
       * "This monorepo consumes packages from an Artifactory private NPM registry."
       */
      // "introduction": "",

      /**
       * Overrides the message that normally says:
       * "Please contact the repository maintainers for help with setting up an Artifactory user account."
       */
      // "obtainAnAccount": "",

      /**
       * Overrides the message that normally says:
       * "Please open this URL in your web browser:"
       *
       * The "artifactoryWebsiteUrl" string is printed after this message.
       */
      // "visitWebsite": "",

      /**
       * Overrides the message that normally says:
       * "Your user name appears in the upper-right corner of the JFrog website."
       */
      // "locateUserName": "",

      /**
       * Overrides the message that normally says:
       * "Click 'Edit Profile' on the JFrog website.  Click the 'Generate API Key'
       * button if you haven't already done so previously."
       */
      // "locateApiKey": ""

      /**
       * Overrides the message that normally prompts:
       * "What is your Artifactory user name?"
       */
      // "userNamePrompt": ""

      /**
       * Overrides the message that normally prompts:
       * "What is your Artifactory API key?"
       */
      // "apiKeyPrompt": ""
    }
  }
}

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/build-cache_json/index.html b/pages/configs/build-cache_json/index.html index 0af0b823..683b26fb 100644 --- a/pages/configs/build-cache_json/index.html +++ b/pages/configs/build-cache_json/index.html @@ -6,14 +6,14 @@ build-cache.json | Rush - +
Rush StackShopBlogEvents

build-cache.json

This is the template that rush init -generates for build-cache.json:

common/config/rush/build-cache.json

/**
 * This configuration file manages Rush's build cache feature.
 * More documentation is available on the Rush website: https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/build-cache.schema.json",

  /**
   * (Required) EXPERIMENTAL - Set this to true to enable the build cache feature.
   *
   * See https://rushjs.io/pages/maintainer/build_cache/ for details about this experimental feature.
   */
  "buildCacheEnabled": false,

  /**
   * (Required) Choose where project build outputs will be cached.
   *
   * Possible values: "local-only", "azure-blob-storage", "amazon-s3"
   */
  "cacheProvider": "local-only",

  /**
   * Setting this property overrides the cache entry ID.  If this property is set, it must contain
   * a [hash] token.
   *
   * Other available tokens:
   *  - [projectName]
   *  - [projectName:normalize]
   *  - [phaseName]
   *  - [phaseName:normalize]
   *  - [phaseName:trimPrefix]
   */
  // "cacheEntryNamePattern": "[projectName:normalize]-[phaseName:normalize]-[hash]"

  /**
   * Use this configuration with "cacheProvider"="azure-blob-storage"
   */
  "azureBlobStorageConfiguration": {
    /**
     * (Required) The name of the the Azure storage account to use for build cache.
     */
    // "storageAccountName": "example",

    /**
     * (Required) The name of the container in the Azure storage account to use for build cache.
     */
    // "storageContainerName": "my-container",

    /**
     * The Azure environment the storage account exists in. Defaults to AzurePublicCloud.
     *
     * Possible values: "AzurePublicCloud", "AzureChina", "AzureGermany", "AzureGovernment"
     */
    // "azureEnvironment": "AzurePublicCloud",

    /**
     * An optional prefix for cache item blob names.
     */
    // "blobPrefix": "my-prefix",

    /**
     * If set to true, allow writing to the cache. Defaults to false.
     */
    // "isCacheWriteAllowed": true
  },

  /**
   * Use this configuration with "cacheProvider"="amazon-s3"
   */
  "amazonS3Configuration": {
    /**
     * (Required unless s3Endpoint is specified) The name of the bucket to use for build cache.
     * Example: "my-bucket"
     */
    // "s3Bucket": "my-bucket",

    /**
     * (Required unless s3Bucket is specified) The Amazon S3 endpoint of the bucket to use for build cache.
     * This should not include any path; use the s3Prefix to set the path.
     * Examples: "my-bucket.s3.us-east-2.amazonaws.com" or "http://localhost:9000"
     */
    // "s3Endpoint": "https://my-bucket.s3.us-east-2.amazonaws.com",

    /**
     * (Required) The Amazon S3 region of the bucket to use for build cache.
     * Example: "us-east-1"
     */
    // "s3Region": "us-east-1",

    /**
     * An optional prefix ("folder") for cache items. It should not start with "/".
     */
    // "s3Prefix": "my-prefix",

    /**
     * If set to true, allow writing to the cache. Defaults to false.
     */
    // "isCacheWriteAllowed": true
  }
}

See also​

© 2023 Microsoft
- +generates for build-cache.json:

common/config/rush/build-cache.json

/**
 * This configuration file manages Rush's build cache feature.
 * More documentation is available on the Rush website: https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/build-cache.schema.json",

  /**
   * (Required) Set this to true to enable the build cache feature.
   *
   * See https://rushjs.io/pages/maintainer/build_cache/ for details about this feature.
   */
  "buildCacheEnabled": false,

  /**
   * (Required) Choose where project build outputs will be cached.
   *
   * Possible values: "local-only", "azure-blob-storage", "amazon-s3"
   */
  "cacheProvider": "local-only",

  /**
   * Setting this property overrides the cache entry ID.  If this property is set, it must contain
   * a [hash] token.
   *
   * Other available tokens:
   *  - [projectName]
   *  - [projectName:normalize]
   *  - [phaseName]
   *  - [phaseName:normalize]
   *  - [phaseName:trimPrefix]
   */
  // "cacheEntryNamePattern": "[projectName:normalize]-[phaseName:normalize]-[hash]"

  /**
   * Use this configuration with "cacheProvider"="azure-blob-storage"
   */
  "azureBlobStorageConfiguration": {
    /**
     * (Required) The name of the the Azure storage account to use for build cache.
     */
    // "storageAccountName": "example",

    /**
     * (Required) The name of the container in the Azure storage account to use for build cache.
     */
    // "storageContainerName": "my-container",

    /**
     * The Azure environment the storage account exists in. Defaults to AzurePublicCloud.
     *
     * Possible values: "AzurePublicCloud", "AzureChina", "AzureGermany", "AzureGovernment"
     */
    // "azureEnvironment": "AzurePublicCloud",

    /**
     * An optional prefix for cache item blob names.
     */
    // "blobPrefix": "my-prefix",

    /**
     * If set to true, allow writing to the cache. Defaults to false.
     */
    // "isCacheWriteAllowed": true
  },

  /**
   * Use this configuration with "cacheProvider"="amazon-s3"
   */
  "amazonS3Configuration": {
    /**
     * (Required unless s3Endpoint is specified) The name of the bucket to use for build cache.
     * Example: "my-bucket"
     */
    // "s3Bucket": "my-bucket",

    /**
     * (Required unless s3Bucket is specified) The Amazon S3 endpoint of the bucket to use for build cache.
     * This should not include any path; use the s3Prefix to set the path.
     * Examples: "my-bucket.s3.us-east-2.amazonaws.com" or "http://localhost:9000"
     */
    // "s3Endpoint": "https://my-bucket.s3.us-east-2.amazonaws.com",

    /**
     * (Required) The Amazon S3 region of the bucket to use for build cache.
     * Example: "us-east-1"
     */
    // "s3Region": "us-east-1",

    /**
     * An optional prefix ("folder") for cache items. It should not start with "/".
     */
    // "s3Prefix": "my-prefix",

    /**
     * If set to true, allow writing to the cache. Defaults to false.
     */
    // "isCacheWriteAllowed": true
  },

  /**
   * Use this configuration with "cacheProvider"="http"
   */
  "httpConfiguration": {
    /**
     * (Required) The URL of the server that stores the caches.
     * Example: "https://build-cacches.example.com/"
     */
    // "url": "https://build-cacches.example.com/",

    /**
     * (Optional) The HTTP method to use when writing to the cache (defaults to PUT).
     * Should be one of PUT, POST, or PATCH.
     * Example: "PUT"
     */
    // "uploadMethod": "PUT",

    /**
     * (Optional) HTTP headers to pass to the cache server.
     * Example: { "X-HTTP-Company-Id": "109283" }
     */
    // "headers": {},

    /**
     * (Optional) Shell command that prints the authorization token needed to communicate with the
     * cache server, and exits with exit code 0. This command will be executed from the root of
     * the monorepo.
     * Example: { "exec": "node", "args": ["common/scripts/auth.js"] }
     */
    // "tokenHandler": { "exec": "node", "args": ["common/scripts/auth.js"] },

    /**
     * (Optional) Prefix for cache keys.
     * Example: "my-company-"
     */
    // "cacheKeyPrefix": "",

    /**
     * (Optional) If set to true, allow writing to the cache. Defaults to false.
     */
    // "isCacheWriteAllowed": true
  }
}

See also​

© 2023 Microsoft
+ \ No newline at end of file diff --git a/pages/configs/cobuild_json/index.html b/pages/configs/cobuild_json/index.html index e05490c5..3fd3d05a 100644 --- a/pages/configs/cobuild_json/index.html +++ b/pages/configs/cobuild_json/index.html @@ -6,14 +6,14 @@ cobuild.json (experimental) | Rush - +
Rush StackShopBlogEvents

cobuild.json (experimental)

This is the template that rush init generates for the cobuild feature.

common/config/rush/cobuild.json

/**
 * This configuration file manages Rush's cobuild feature.
 * More documentation is available on the Rush website: https://rushjs.io
 */
 {
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/cobuild.schema.json",

  /**
   * (Required) EXPERIMENTAL - Set this to true to enable the cobuild feature.
   * RUSH_COBUILD_CONTEXT_ID should always be specified as an environment variable with an non-empty string,
   * otherwise the cobuild feature will be disabled.
   */
  "cobuildFeatureEnabled": false,

  /**
   * (Required) Choose where cobuild lock will be acquired.
   *
   * The lock provider is registered by the rush plugins.
   * For example, @rushstack/rush-redis-cobuild-plugin registers the "redis" lock provider.
   */
  "cobuildLockProvider": "redis"
}

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/command-line_json/index.html b/pages/configs/command-line_json/index.html index 774f75d9..e08c551e 100644 --- a/pages/configs/command-line_json/index.html +++ b/pages/configs/command-line_json/index.html @@ -6,14 +6,14 @@ command-line.json | Rush - +
Rush StackShopBlogEvents

command-line.json

This is the template that rush init generates for command-line.json:

common/config/rush/command-line.json

/**
 * 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,
    //
    //   /**
    //    * 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"
    //     }
    //   ]
    // }
  ]
}

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/command_line_json/index.html b/pages/configs/command_line_json/index.html index ac159f99..627646cf 100644 --- a/pages/configs/command_line_json/index.html +++ b/pages/configs/command_line_json/index.html @@ -6,13 +6,13 @@ command_line_json | Rush - +
Rush StackShopBlogEvents

Redirecting...

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/common-versions_json/index.html b/pages/configs/common-versions_json/index.html index 20dbcf02..4978fa2c 100644 --- a/pages/configs/common-versions_json/index.html +++ b/pages/configs/common-versions_json/index.html @@ -6,14 +6,14 @@ common-versions.json | Rush - +
Rush StackShopBlogEvents

common-versions.json

This is the template that rush init generates for common-versions.json:

common/config/rush/common-versions.json

/**
 * 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,

  /**
   * 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"
    // ]
  }
}
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/common_versions_json/index.html b/pages/configs/common_versions_json/index.html index bb92ddc7..d511cd75 100644 --- a/pages/configs/common_versions_json/index.html +++ b/pages/configs/common_versions_json/index.html @@ -6,13 +6,13 @@ common_versions_json | Rush - +
Rush StackShopBlogEvents

Redirecting...

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/custom-tips_json/index.html b/pages/configs/custom-tips_json/index.html index f725c2f3..b89afa67 100644 --- a/pages/configs/custom-tips_json/index.html +++ b/pages/configs/custom-tips_json/index.html @@ -6,14 +6,14 @@ custom-tips.json (experimental) | Rush - +
Rush StackShopBlogEvents

custom-tips.json (experimental)

This is the template that rush init generates for the Custom tips feature.

common/config/rush/custom-tips.json

/**
 * 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",

  /**
   * Specifies the custom tips to be displayed by Rush.
   */
  "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.
    //    * Consult the Rush documentation for the current list of possible identifiers.
    //    */
    //   "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"
    // }
  ]
}

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/deploy_json/index.html b/pages/configs/deploy_json/index.html index 50a963d9..b929020e 100644 --- a/pages/configs/deploy_json/index.html +++ b/pages/configs/deploy_json/index.html @@ -6,14 +6,14 @@ deploy.json | Rush - +
Rush StackShopBlogEvents

deploy.json

This is the template that rush init-deploy generates for deploy.json and deploy-<scenario name>>.json:

common/config/rush/deploy.json

/**
 * This configuration file defines a deployment scenario for use with the "rush deploy" command.
 * The default scenario file path is "deploy.json"; additional files use the naming pattern
 * "deploy-<scenario-name>.json". For full documentation, please see https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/deploy-scenario.schema.json",

  /**
   * The "rush deploy" command prepares a deployment folder, starting from the main project and collecting
   * all of its dependencies (both NPM packages and other Rush projects).  The main project is specified
   * using the "--project" parameter.  The "deploymentProjectNames" setting lists the allowable choices for
   * the "--project" parameter; this documents the intended deployments for your monorepo and helps validate
   * that "rush deploy" is invoked correctly.  If there is only one item in the "deploymentProjectNames" array,
   * then "--project" can be omitted.  The names should be complete package names as declared in rush.json.
   *
   * If the main project should include other unrelated Rush projects, add it to the "projectSettings" section,
   * and then specify those projects in the "additionalProjectsToInclude" list.
   */
  "deploymentProjectNames": [ /* YOUR PROJECT HERE */ ],

  /**
   * When deploying a local Rush project, the package.json "devDependencies" are normally excluded.
   * If you want to include them, set "includeDevDependencies" to true.
   *
   * The default value is false.
   */
  // "includeDevDependencies": true,

  /**
   * When deploying a local Rush project, normally the .npmignore filter is applied so that Rush only copies
   * files that would be packaged by "npm pack".  Setting "includeNpmIgnoreFiles" to true will disable this
   * filtering so that all files are copied (with a few trivial exceptions such as the "node_modules" folder).
   *
   * The default value is false.
   */
  // "includeNpmIgnoreFiles": true,

  /**
   * To improve backwards compatibility with legacy packages, the PNPM package manager installs extra links in the
   * node_modules folder that enable packages to import undeclared dependencies.  In some cases this workaround may
   * double the number of links created.  If your deployment does not require this workaround, you can set
   * "omitPnpmWorkaroundLinks" to true to avoid creating the extra links.
   *
   * The default value is false.
   */
  // "omitPnpmWorkaroundLinks": true,

  /**
   * Specify how links (symbolic links, hard links, and/or NTFS junctions) will be created in the deployed folder:
   *
   * - "default": Create the links while copying the files; this is the default behavior.
   * - "script": A Node.js script called "create-links.js" will be written.  When executed, this script will
   *   create the links described in the "deploy-metadata.json" output file.
   * - "none": Do nothing; some other tool may create the links later.
   */
  // "linkCreation": "script",

  /**
   * If this path is specified, then after "rush deploy", recursively copy the files from this folder to
   * the deployment target folder (common/deploy). This can be used to provide additional configuration files
   * or scripts needed by the server when deploying. The path is resolved relative to the repository root.
   */
  //  "folderToCopy": "repo-tools/assets/deploy-config",

  /**
   * Customize how Rush projects are processed during deployment.
   */
  "projectSettings": [
    // {
    //   /**
    //    * The full package name of the project, which must be declared in rush.json.
    //    */
    //   "projectName": "@my-scope/my-project",
    //
    //   /**
    //    * A list of additional local Rush projects to be deployed with this project (beyond the package.json
    //    * dependencies).  Specify full package names, which must be declared in rush.json.
    //    */
    //   "additionalProjectsToInclude": [
    //     // "@my-scope/my-project2"
    //   ],
    //
    //   /**
    //    * When deploying a project, the included dependencies are normally determined automatically based on
    //    * package.json fields such as "dependencies", "peerDependencies", and "optionalDependencies",
    //    * subject to other deployment settings such as "includeDevDependencies".  However, in cases where
    //    * that information is not accurate, you can use "additionalDependenciesToInclude" to add more
    //    * packages to the list.
    //    *
    //    * The list can include any package name that is installed by Rush and resolvable via Node.js module
    //    * resolution; however, if it resolves to a local Rush project, the "additionalProjectsToInclude"
    //    * field will not be recursively applied.
    //    */
    //   "additionalDependenciesToInclude": [
    //     // "@rushstack/node-core-library"
    //   ],
    //
    //   /**
    //    * This setting prevents specific dependencies from being deployed.  It only filters dependencies that
    //    * are explicitly declared in package.json for this project.  It does not affect dependencies added
    //    * via "additionalProjectsToInclude" or "additionalDependenciesToInclude", nor does it affect indirect
    //    * dependencies.
    //    *
    //    * The "*" wildcard may be used to match zero or more characters.  For example, if your project already
    //    * bundles its own dependencies, specify "dependenciesToExclude": [ "*" ] to exclude all package.json
    //    * dependencies.
    //    */
    //   "dependenciesToExclude": [
    //     // "@types/*"
    //   ]
    // }
  ]
}

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/environment_vars/index.html b/pages/configs/environment_vars/index.html index fc7103ad..24e4d78f 100644 --- a/pages/configs/environment_vars/index.html +++ b/pages/configs/environment_vars/index.html @@ -6,7 +6,7 @@ Environment variables | Rush - + @@ -19,17 +19,17 @@ in the command-line.json configuration file. Specify 1 to allow warnings in a successful build, or 0 to disallow them. (See the comments in the command-line.json -file for more information).

RUSH_BUILD_CACHE_CREDENTIAL (EXPERIMENTAL)​

This environment variable is used by the experimental +file for more information).

RUSH_BUILD_CACHE_CREDENTIAL​

This environment variable is used by the build cache feature.

Provides a credential for accessing the remote build cache, if configured. This credential overrides any cached credentials.

Setting this environment variable overrides whatever credential has been saved in the local cloud cache credentials using rush update-cloud-credentials.

If Azure Blob Storage is used to store cache entries, this must be a SAS token serialized as query parameters. See this article for details -about SAS tokens.

RUSH_BUILD_CACHE_ENABLED (EXPERIMENTAL)​

This environment variable is used by the experimental +about SAS tokens.

RUSH_BUILD_CACHE_ENABLED​

This environment variable is used by the build cache feature.

Setting this environment variable overrides the value of buildCacheEnabled in the build-cache.json -configuration file. Specify 1 to enable the build cache or 0 to disable it.

If set to 0, this is equivalent to passing the --disable-build-cache flag.

If there is no build cache configured, then this environment variable is ignored.

RUSH_BUILD_CACHE_WRITE_ALLOWED (EXPERIMENTAL)​

This environment variable is used by the experimental +configuration file. Specify 1 to enable the build cache or 0 to disable it.

If set to 0, this is equivalent to passing the --disable-build-cache flag.

If there is no build cache configured, then this environment variable is ignored.

RUSH_BUILD_CACHE_WRITE_ALLOWED​

This environment variable is used by the build cache feature.

Overrides the value of isCacheWriteAllowed in the build-cache.json configuration file. The value of this environment variable must be 1 (for true) or 0 (for false). If there is no build cache configured, then @@ -49,7 +49,10 @@ of files (e.g. installations of the @microsoft/rush-lib engine and the package manager) are stored in a global folder to speed up installations. The default location is ~/.rush on POSIX-like operating systems or C:\Users\YourName on Windows.

Use RUSH_GLOBAL_FOLDER to specify a different folder path. This is useful for example if a Windows -group policy forbids executing scripts installed in a user's home directory.

(POSIX is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc.)

RUSH_INVOKED_FOLDER​

When Rush executes shell scripts, it sometimes changes the working directory to be a project folder or +group policy forbids executing scripts installed in a user's home directory.

(POSIX is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc.)

RUSH_INVOKED_ARGS​

When running a hook script, this environment variable communicates the original arguments +passed to the rush or rushx command.

Unlike RUSH_INVOKED_FOLDER, the RUSH_INVOKED_ARGS variable is only available for hook scripts. +Other lifecycle scripts should not make assumptions about Rush's command line syntax +if Rush did not explicitly pass along command-line parameters to their process.

RUSH_INVOKED_FOLDER​

When Rush executes shell scripts, it sometimes changes the working directory to be a project folder or the repository root folder. The original working directory (where the Rush command was invoked) is assigned to the the child process's RUSH_INVOKED_FOLDER environment variable, in case it is needed by the script.

The RUSH_INVOKED_FOLDER variable is the same idea as the INIT_CWD variable that package managers assign when they execute lifecycle scripts.

RUSH_PARALLELISM​

Specifies the maximum number of concurrent processes to launch during a build. @@ -63,8 +66,10 @@ The default value is common/temp under the repository root.

This environment variable is not compatible with workspace installs (useWorkspaces = true). If attempting to move the PNPM store path, see the RUSH_PNPM_STORE_PATH environment variable.

RUSH_VARIANT​

This variable selects a specific installation variant for Rush to use when installing and linking package dependencies.

For more information about this feature, see -Installation Variants.

© 2023 Microsoft
- +Installation Variants.

RUSH_PNPM_VERIFY_STORE_INTEGRITY​

When using PNPM as the package manager, this variable can be used to control whether or not PNPM +validates the integrity of the PNPM store during installation. The value of this environment variable must be +1 (for true) or 0 (for false). If not specified, defaults to the value in .npmrc.

© 2023 Microsoft
+ \ No newline at end of file diff --git a/pages/configs/experiments_json/index.html b/pages/configs/experiments_json/index.html index e639a8fe..ddc997cf 100644 --- a/pages/configs/experiments_json/index.html +++ b/pages/configs/experiments_json/index.html @@ -6,14 +6,14 @@ experiments.json | Rush - +
Rush StackShopBlogEvents

experiments.json

This is the template that rush init -generates for experiments.json:

common/config/rush/experiments.json

/**
 * 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,

  /**
   * 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, the phased commands feature is enabled. To use this feature, create a "phased" command
   * in common/config/rush/command-line.json.
   */
  // "phasedCommands": true
}
© 2023 Microsoft
- +generates for experiments.json:

common/config/rush/experiments.json

/**
 * 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, the phased commands feature is enabled. To use this feature, create a "phased" command
   * in common/config/rush/command-line.json.
   */
  // "phasedCommands": 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
}
© 2023 Microsoft
+ \ No newline at end of file diff --git a/pages/configs/npmrc-publish/index.html b/pages/configs/npmrc-publish/index.html index fe1f777e..4bf9c1ed 100644 --- a/pages/configs/npmrc-publish/index.html +++ b/pages/configs/npmrc-publish/index.html @@ -6,14 +6,14 @@ .npmrc-publish | Rush - +
Rush StackShopBlogEvents

.npmrc-publish

This is the template that rush init generates for .npmrc-publish:

common/config/rush/.npmrc-publish

# This config file is very similar to common/config/rush/.npmrc, except that .npmrc-publish
# is used by the "rush publish" command, as publishing often involves different credentials
# and registries than other operations.
#
# Before invoking the package manager, Rush will copy this file to "common/temp/publish-home/.npmrc"
# and then temporarily map that folder as the "home directory" for the current user account.
# This enables the same settings to apply for each project folder that gets published.  The copied file
# will omit any config lines that reference environment variables that are undefined in that session;
# this avoids problems that would otherwise result due to a missing variable being replaced by
# an empty string.
#
# * * * SECURITY WARNING * * *
#
# It is NOT recommended to store authentication tokens in a text file on a lab machine, because
# other unrelated processes may be able to read the file.  Also, the file may persist indefinitely,
# for example if the machine loses power.  A safer practice is to pass the token via an
# environment variable, which can be referenced from .npmrc using ${} expansion.  For example:
#
#   //registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}
#

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/npmrc/index.html b/pages/configs/npmrc/index.html index b0ba77f7..b885a9bc 100644 --- a/pages/configs/npmrc/index.html +++ b/pages/configs/npmrc/index.html @@ -6,7 +6,7 @@ .npmrc | Rush - + @@ -25,7 +25,7 @@ package manager's usual precedence will apply instead. Generally this practice is discouraged in a Rush repo, but if used, you may need to create additional .npmrc files.

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/pnpm-config_json/index.html b/pages/configs/pnpm-config_json/index.html index 9a2802e2..4e024dfe 100644 --- a/pages/configs/pnpm-config_json/index.html +++ b/pages/configs/pnpm-config_json/index.html @@ -6,7 +6,7 @@ pnpm-config.json | Rush - + @@ -17,8 +17,8 @@ If you are upgrading an old monorepo, in order to access these new PNPM settings, you must manually delete the "pnpmOptions" setting from rush.json and create the pnpm-config.json file.

This is the template that rush init -generates for pnpm-config.json:

common/config/rush/pnpm-config.json

/**
 * This configuration file provides settings specific to the PNPM package manager.
 * More documentation is available on the Rush website: https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/pnpm-config.schema.json",

  /**
   * If true, then `rush install` and `rush update` will use the PNPM workspaces feature
   * to perform the install, instead of the old model where Rush generated the symlinks
   * for each projects's node_modules folder.
   *
   * When using workspaces, Rush will generate a `common/temp/pnpm-workspace.yaml` file referencing
   * all local projects to install. Rush will also generate a `.pnpmfile.cjs` shim which implements
   * Rush-specific features such as preferred versions.  The user's `common/config/rush/.pnpmfile.cjs`
   * is invoked by the shim.
   *
   * This option is strongly recommended. The default value is false.
   */
  "useWorkspaces": true,

  /**
   * This setting determines how PNPM chooses version numbers during `rush update`.
   * For example, suppose `lib-x@3.0.0` depends on `"lib-y": "^1.2.3"` whose latest major
   * releases are `1.8.9` and `2.3.4`.  The resolution mode `lowest-direct` might choose
   * `lib-y@1.2.3`, wheres `highest` will choose 1.8.9, and `time-based` will pick the
   * highest compatible version at the time when `lib-x@3.0.0` itself was published (ensuring
   * that the version could have been tested by the maintainer of "lib-x").  For local workspace
   * projects, `time-based` instead works like `lowest-direct`, avoiding upgrades unless
   * they are explicitly requested. Although `time-based` is the most robust option, it may be
   * slightly slower with registries such as npmjs.com that have not implemented an optimization.
   *
   * IMPORTANT: Be aware that PNPM 8.0.0 initially defaulted to `lowest-direct` instead of
   * `highest`, but PNPM reverted this decision in 8.6.12 because it caused confusion for users.
   * Rush version 5.106.0 and newer avoids this confusion by consistently defaulting to
   * `highest` when `resolutionMode` is not explicitly set in pnpm-config.json or .npmrc,
   * regardless of your PNPM version.
   *
   * PNPM documentation: https://pnpm.io/npmrc#resolution-mode
   *
   * Possible values are: `highest`, `time-based`, and `lowest-direct`.
   * The default is `highest`.
   */
  // "resolutionMode": "time-based",

  /**
   * If true, then Rush will add the `--strict-peer-dependencies` command-line parameter when
   * invoking PNPM.  This causes `rush update` to fail if there are unsatisfied peer dependencies,
   * which is an invalid state that can cause build failures or incompatible dependency versions.
   * (For historical reasons, JavaScript package managers generally do not treat this invalid
   * state as an error.)
   *
   * PNPM documentation: https://pnpm.io/npmrc#strict-peer-dependencies
   *
   * The default value is false to avoid legacy compatibility issues.
   * It is strongly recommended to set `strictPeerDependencies=true`.
   */
  // "strictPeerDependencies": true,

  /**
   * Environment variables that will be provided to PNPM.
   */
  // "environmentVariables": {
  //   "NODE_OPTIONS": {
  //     "value": "--max-old-space-size=4096",
  //     "override": false
  //   }
  // },

  /**
   * Specifies the location of the PNPM store.  There are two possible values:
   *
   * - `local` - use the `pnpm-store` folder in the current configured temp folder:
   *   `common/temp/pnpm-store` by default.
   * - `global` - use PNPM's global store, which has the benefit of being shared
   *    across multiple repo folders, but the disadvantage of less isolation for builds
   *    (for example, bugs or incompatibilities when two repos use different releases of PNPM)
   *
   * In both cases, the store path can be overridden by the environment variable `RUSH_PNPM_STORE_PATH`.
   *
   * The default value is `local`.
   */
  // "pnpmStore": "global",

  /**
   * If true, then `rush install` will report an error if manual modifications
   * were made to the PNPM shrinkwrap file without running `rush update` afterwards.
   *
   * This feature protects against accidental inconsistencies that may be introduced
   * if the PNPM shrinkwrap file (`pnpm-lock.yaml`) is manually edited.  When this
   * feature is enabled, `rush update` will append a hash to the file as a YAML comment,
   * and then `rush update` and `rush install` will validate the hash.  Note that this
   * does not prohibit manual modifications, but merely requires `rush update` be run
   * afterwards, ensuring that PNPM can report or repair any potential inconsistencies.
   *
   * To temporarily disable this validation when invoking `rush install`, use the
   * `--bypass-policy` command-line parameter.
   *
   * The default value is false.
   */
  // "preventManualShrinkwrapChanges": true,

  /**
   * The "globalOverrides" setting provides a simple mechanism for overriding version selections
   * for all dependencies of all projects in the monorepo workspace.  The settings are copied
   * into the `pnpm.overrides` field of the `common/temp/package.json` file that is generated
   * by Rush during installation.
   *
   * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
   * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
   * and `globalOverrides` has lowest precedence.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmoverrides
   */
  "globalOverrides": {
    // "example1": "^1.0.0",
    // "example2": "npm:@company/example2@^1.0.0"
  },

  /**
   * The `globalPeerDependencyRules` setting provides various settings for suppressing validation errors
   * that are reported during installation with `strictPeerDependencies=true`.  The settings are copied
   * into the `pnpm.peerDependencyRules` field of the `common/temp/package.json` file that is generated
   * by Rush during installation.
   *
   * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
   * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
   * and `globalOverrides` has lowest precedence.
   *
   * https://pnpm.io/package_json#pnpmpeerdependencyrules
   */
  "globalPeerDependencyRules": {
    // "ignoreMissing": ["@eslint/*"],
    // "allowedVersions": { "react": "17" },
    // "allowAny": ["@babel/*"]
  },

  /**
   * The `globalPackageExtension` setting provides a way to patch arbitrary package.json fields
   * for any PNPM dependency of the monorepo.  The settings are copied into the `pnpm.packageExtensions`
   * field of the `common/temp/package.json` file that is generated by Rush during installation.
   * The `globalPackageExtension` setting has similar capabilities as `.pnpmfile.cjs` but without
   * the downsides of an executable script (nondeterminism, unreliable caching, performance concerns).
   *
   * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
   * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
   * and `globalOverrides` has lowest precedence.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmpackageextensions
   */
  "globalPackageExtensions": {
    // "fork-ts-checker-webpack-plugin": {
    //   "dependencies": {
    //     "@babel/core": "1"
    //   },
    //   "peerDependencies": {
    //     "eslint": ">= 6"
    //   },
    //   "peerDependenciesMeta": {
    //     "eslint": {
    //       "optional": true
    //     }
    //   }
    // }
  },

  /**
   * The `globalNeverBuiltDependencies` setting suppresses the `preinstall`, `install`, and `postinstall`
   * lifecycle events for the specified NPM dependencies.  This is useful for scripts with poor practices
   * such as downloading large binaries without retries or attempting to invoke OS tools such as
   * a C++ compiler.  (PNPM's terminology refers to these lifecycle events as "building" a package;
   * it has nothing to do with build system operations such as `rush build` or `rushx build`.)
   * The settings are copied into the `pnpm.neverBuiltDependencies` field of the `common/temp/package.json`
   * file that is generated by Rush during installation.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmneverbuiltdependencies
   */
  "globalNeverBuiltDependencies": [
    // "fsevents"
  ],

  /**
   * The `globalAllowedDeprecatedVersions` setting suppresses installation warnings for package
   * versions that the NPM registry reports as being deprecated.  This is useful if the
   * deprecated package is an indirect dependency of an external package that has not released a fix.
   * The settings are copied into the `pnpm.allowedDeprecatedVersions` field of the `common/temp/package.json`
   * file that is generated by Rush during installation.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmalloweddeprecatedversions
   *
   * If you are working to eliminate a deprecated version, it's better to specify `allowedDeprecatedVersions`
   * in the package.json file for individual Rush projects.
   */
  "globalAllowedDeprecatedVersions": {
    // "request": "*"
  },


  /**
   * (THIS FIELD IS MACHINE GENERATED)  The "globalPatchedDependencies" field is updated automatically
   * by the `rush-pnpm patch-commit` command.  It is a dictionary, where the key is an NPM package name
   * and exact version, and the value is a relative path to the associated patch file.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmpatcheddependencies
   */
  "globalPatchedDependencies": { },

  /**
   * (USE AT YOUR OWN RISK)  This is a free-form property bag that will be copied into
   * the `common/temp/package.json` file that is generated by Rush during installation.
   * This provides a way to experiment with new PNPM features.  These settings will override
   * any other Rush configuration associated with a given JSON field except for `.pnpmfile.cjs`.
   *
   * USAGE OF THIS SETTING IS NOT SUPPORTED BY THE RUSH MAINTAINERS AND MAY CAUSE RUSH
   * TO MALFUNCTION.  If you encounter a missing PNPM setting that you believe should
   * be supported, please create a GitHub issue or PR.  Note that Rush does not aim to
   * support every possible PNPM setting, but rather to promote a battle-tested installation
   * strategy that is known to provide a good experience for large teams with lots of projects.
   */
  "unsupportedPackageJsonSettings": {
    // "dependencies": {
    //   "not-a-good-practice": "*"
    // },
    // "scripts": {
    //   "do-something": "echo Also not a good practice"
    // },
    // "pnpm": { "futurePnpmFeature": true }
  }
}
© 2023 Microsoft
- +generates for pnpm-config.json:

common/config/rush/pnpm-config.json

/**
 * This configuration file provides settings specific to the PNPM package manager.
 * More documentation is available on the Rush website: https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/pnpm-config.schema.json",

  /**
   * If true, then `rush install` and `rush update` will use the PNPM workspaces feature
   * to perform the install, instead of the old model where Rush generated the symlinks
   * for each projects's node_modules folder.
   *
   * When using workspaces, Rush will generate a `common/temp/pnpm-workspace.yaml` file referencing
   * all local projects to install. Rush will also generate a `.pnpmfile.cjs` shim which implements
   * Rush-specific features such as preferred versions.  The user's `common/config/rush/.pnpmfile.cjs`
   * is invoked by the shim.
   *
   * This option is strongly recommended. The default value is false.
   */
  "useWorkspaces": true,

  /**
   * This setting determines how PNPM chooses version numbers during `rush update`.
   * For example, suppose `lib-x@3.0.0` depends on `"lib-y": "^1.2.3"` whose latest major
   * releases are `1.8.9` and `2.3.4`.  The resolution mode `lowest-direct` might choose
   * `lib-y@1.2.3`, wheres `highest` will choose 1.8.9, and `time-based` will pick the
   * highest compatible version at the time when `lib-x@3.0.0` itself was published (ensuring
   * that the version could have been tested by the maintainer of "lib-x").  For local workspace
   * projects, `time-based` instead works like `lowest-direct`, avoiding upgrades unless
   * they are explicitly requested. Although `time-based` is the most robust option, it may be
   * slightly slower with registries such as npmjs.com that have not implemented an optimization.
   *
   * IMPORTANT: Be aware that PNPM 8.0.0 initially defaulted to `lowest-direct` instead of
   * `highest`, but PNPM reverted this decision in 8.6.12 because it caused confusion for users.
   * Rush version 5.106.0 and newer avoids this confusion by consistently defaulting to
   * `highest` when `resolutionMode` is not explicitly set in pnpm-config.json or .npmrc,
   * regardless of your PNPM version.
   *
   * PNPM documentation: https://pnpm.io/npmrc#resolution-mode
   *
   * Possible values are: `highest`, `time-based`, and `lowest-direct`.
   * The default is `highest`.
   */
  // "resolutionMode": "time-based",

  /**
   * This setting determines whether PNPM will automatically install (non-optional)
   * missing peer dependencies instead of reporting an error.  Doing so conveniently
   * avoids the need to specify peer versions in package.json, but in a large monorepo
   * this often creates worse problems.  The reason is that peer dependency behavior
   * is inherently complicated, and it is easier to troubleshoot consequences of an explicit
   * version than an invisible heuristic.  The original NPM RFC discussion pointed out
   * some other problems with this feature: https://github.com/npm/rfcs/pull/43

   * IMPORTANT: Without Rush, the setting defaults to true for PNPM 8 and newer; however,
   * as of Rush version 5.109.0 the default is always false unless `autoInstallPeers`
   * is specified in pnpm-config.json or .npmrc, regardless of your PNPM version.

   * PNPM documentation: https://pnpm.io/npmrc#auto-install-peers

   * The default value is false.
   */
  // "autoInstallPeers": false,

  /**
   * If true, then Rush will add the `--strict-peer-dependencies` command-line parameter when
   * invoking PNPM.  This causes `rush update` to fail if there are unsatisfied peer dependencies,
   * which is an invalid state that can cause build failures or incompatible dependency versions.
   * (For historical reasons, JavaScript package managers generally do not treat this invalid
   * state as an error.)
   *
   * PNPM documentation: https://pnpm.io/npmrc#strict-peer-dependencies
   *
   * The default value is false to avoid legacy compatibility issues.
   * It is strongly recommended to set `strictPeerDependencies=true`.
   */
  // "strictPeerDependencies": true,

  /**
   * Environment variables that will be provided to PNPM.
   */
  // "environmentVariables": {
  //   "NODE_OPTIONS": {
  //     "value": "--max-old-space-size=4096",
  //     "override": false
  //   }
  // },

  /**
   * Specifies the location of the PNPM store.  There are two possible values:
   *
   * - `local` - use the `pnpm-store` folder in the current configured temp folder:
   *   `common/temp/pnpm-store` by default.
   * - `global` - use PNPM's global store, which has the benefit of being shared
   *    across multiple repo folders, but the disadvantage of less isolation for builds
   *    (for example, bugs or incompatibilities when two repos use different releases of PNPM)
   *
   * In both cases, the store path can be overridden by the environment variable `RUSH_PNPM_STORE_PATH`.
   *
   * The default value is `local`.
   */
  // "pnpmStore": "global",

  /**
   * If true, then `rush install` will report an error if manual modifications
   * were made to the PNPM shrinkwrap file without running `rush update` afterwards.
   *
   * This feature protects against accidental inconsistencies that may be introduced
   * if the PNPM shrinkwrap file (`pnpm-lock.yaml`) is manually edited.  When this
   * feature is enabled, `rush update` will append a hash to the file as a YAML comment,
   * and then `rush update` and `rush install` will validate the hash.  Note that this
   * does not prohibit manual modifications, but merely requires `rush update` be run
   * afterwards, ensuring that PNPM can report or repair any potential inconsistencies.
   *
   * To temporarily disable this validation when invoking `rush install`, use the
   * `--bypass-policy` command-line parameter.
   *
   * The default value is false.
   */
  // "preventManualShrinkwrapChanges": true,

  /**
   * The "globalOverrides" setting provides a simple mechanism for overriding version selections
   * for all dependencies of all projects in the monorepo workspace.  The settings are copied
   * into the `pnpm.overrides` field of the `common/temp/package.json` file that is generated
   * by Rush during installation.
   *
   * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
   * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
   * and `globalOverrides` has lowest precedence.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmoverrides
   */
  "globalOverrides": {
    // "example1": "^1.0.0",
    // "example2": "npm:@company/example2@^1.0.0"
  },

  /**
   * The `globalPeerDependencyRules` setting provides various settings for suppressing validation errors
   * that are reported during installation with `strictPeerDependencies=true`.  The settings are copied
   * into the `pnpm.peerDependencyRules` field of the `common/temp/package.json` file that is generated
   * by Rush during installation.
   *
   * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
   * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
   * and `globalOverrides` has lowest precedence.
   *
   * https://pnpm.io/package_json#pnpmpeerdependencyrules
   */
  "globalPeerDependencyRules": {
    // "ignoreMissing": ["@eslint/*"],
    // "allowedVersions": { "react": "17" },
    // "allowAny": ["@babel/*"]
  },

  /**
   * The `globalPackageExtension` setting provides a way to patch arbitrary package.json fields
   * for any PNPM dependency of the monorepo.  The settings are copied into the `pnpm.packageExtensions`
   * field of the `common/temp/package.json` file that is generated by Rush during installation.
   * The `globalPackageExtension` setting has similar capabilities as `.pnpmfile.cjs` but without
   * the downsides of an executable script (nondeterminism, unreliable caching, performance concerns).
   *
   * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
   * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
   * and `globalOverrides` has lowest precedence.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmpackageextensions
   */
  "globalPackageExtensions": {
    // "fork-ts-checker-webpack-plugin": {
    //   "dependencies": {
    //     "@babel/core": "1"
    //   },
    //   "peerDependencies": {
    //     "eslint": ">= 6"
    //   },
    //   "peerDependenciesMeta": {
    //     "eslint": {
    //       "optional": true
    //     }
    //   }
    // }
  },

  /**
   * The `globalNeverBuiltDependencies` setting suppresses the `preinstall`, `install`, and `postinstall`
   * lifecycle events for the specified NPM dependencies.  This is useful for scripts with poor practices
   * such as downloading large binaries without retries or attempting to invoke OS tools such as
   * a C++ compiler.  (PNPM's terminology refers to these lifecycle events as "building" a package;
   * it has nothing to do with build system operations such as `rush build` or `rushx build`.)
   * The settings are copied into the `pnpm.neverBuiltDependencies` field of the `common/temp/package.json`
   * file that is generated by Rush during installation.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmneverbuiltdependencies
   */
  "globalNeverBuiltDependencies": [
    // "fsevents"
  ],

  /**
   * The `globalAllowedDeprecatedVersions` setting suppresses installation warnings for package
   * versions that the NPM registry reports as being deprecated.  This is useful if the
   * deprecated package is an indirect dependency of an external package that has not released a fix.
   * The settings are copied into the `pnpm.allowedDeprecatedVersions` field of the `common/temp/package.json`
   * file that is generated by Rush during installation.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmalloweddeprecatedversions
   *
   * If you are working to eliminate a deprecated version, it's better to specify `allowedDeprecatedVersions`
   * in the package.json file for individual Rush projects.
   */
  "globalAllowedDeprecatedVersions": {
    // "request": "*"
  },


  /**
   * (THIS FIELD IS MACHINE GENERATED)  The "globalPatchedDependencies" field is updated automatically
   * by the `rush-pnpm patch-commit` command.  It is a dictionary, where the key is an NPM package name
   * and exact version, and the value is a relative path to the associated patch file.
   *
   * PNPM documentation: https://pnpm.io/package_json#pnpmpatcheddependencies
   */
  "globalPatchedDependencies": { },

  /**
   * (USE AT YOUR OWN RISK)  This is a free-form property bag that will be copied into
   * the `common/temp/package.json` file that is generated by Rush during installation.
   * This provides a way to experiment with new PNPM features.  These settings will override
   * any other Rush configuration associated with a given JSON field except for `.pnpmfile.cjs`.
   *
   * USAGE OF THIS SETTING IS NOT SUPPORTED BY THE RUSH MAINTAINERS AND MAY CAUSE RUSH
   * TO MALFUNCTION.  If you encounter a missing PNPM setting that you believe should
   * be supported, please create a GitHub issue or PR.  Note that Rush does not aim to
   * support every possible PNPM setting, but rather to promote a battle-tested installation
   * strategy that is known to provide a good experience for large teams with lots of projects.
   */
  "unsupportedPackageJsonSettings": {
    // "dependencies": {
    //   "not-a-good-practice": "*"
    // },
    // "scripts": {
    //   "do-something": "echo Also not a good practice"
    // },
    // "pnpm": { "futurePnpmFeature": true }
  }
}
© 2023 Microsoft
+ \ No newline at end of file diff --git a/pages/configs/pnpmfile_cjs/index.html b/pages/configs/pnpmfile_cjs/index.html index 44eabb0c..b8d4b42e 100644 --- a/pages/configs/pnpmfile_cjs/index.html +++ b/pages/configs/pnpmfile_cjs/index.html @@ -6,14 +6,14 @@ .pnpmfile.cjs | Rush - +
Rush StackShopBlogEvents

.pnpmfile.cjs

This is the template that rush init generates for the monorepo pnpmfile.js file:

common/config/rush/.pnpmfile.cjs

'use strict';

/**
 * When using the PNPM package manager, you can use pnpmfile.js to workaround
 * dependencies that have mistakes in their package.json file.  (This feature is
 * functionally similar to Yarn's "resolutions".)
 *
 * For details, see the PNPM documentation:
 * https://pnpm.js.org/docs/en/hooks.html
 *
 * IMPORTANT: SINCE THIS FILE CONTAINS EXECUTABLE CODE, MODIFYING IT IS LIKELY TO INVALIDATE
 * ANY CACHED DEPENDENCY ANALYSIS.  After any modification to pnpmfile.js, it's recommended to run
 * "rush update --full" so that PNPM will recalculate all version selections.
 */
module.exports = {
  hooks: {
    readPackage
  }
};

/**
 * This hook is invoked during installation before a package's dependencies
 * are selected.
 * The `packageJson` parameter is the deserialized package.json
 * contents for the package that is about to be installed.
 * The `context` parameter provides a log() function.
 * The return value is the updated object.
 */
function readPackage(packageJson, context) {
  // // The karma types have a missing dependency on typings from the log4js package.
  // if (packageJson.name === '@types/karma') {
  //  context.log('Fixed up dependencies for @types/karma');
  //  packageJson.dependencies['log4js'] = '0.6.38';
  // }

  return packageJson;
}
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/rush-plugin-manifest_json/index.html b/pages/configs/rush-plugin-manifest_json/index.html index ae80a0e5..384e93c8 100644 --- a/pages/configs/rush-plugin-manifest_json/index.html +++ b/pages/configs/rush-plugin-manifest_json/index.html @@ -6,14 +6,14 @@ rush-plugin-manifest.json (experimental) | Rush - +
Rush StackShopBlogEvents

rush-plugin-manifest.json (experimental)

This is the template for the rush-plugin-manifest.json file that is used when creating a Rush plugin.

<your plugin project>/rush-plugin-manifest.json

/**
 * This file defines the Rush plugins that are provided by this package.
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush-plugin-manifest.schema.json",

  /**
   * An array of one or more plugin definitions provided by this NPM package.
   *
   * For more granular installations, it is recommended for plugins to be implemented by an
   * NPM package that does try to serve other roles such as providing APIs or command-line binaries.
   * The package name should start with "rush-".  The name should end with "-plugin" or "-plugins".
   * For example: "@scope/rush-business-policy-plugin"
   */
  "plugins": [
    {
      /**
       * (Required) The name of the plugin.  The plugin name must be comprised of letters and numbers
       * forming one or more words that are separated by hyphens.  Note that if the plugin has a
       * JSON config file, that filename will be the same as the plugin name.  See "optionsSchema" below
       * for details.
       *
       * If the manifest defines exactly one plugin, then it is suggested to reuse the name from the
       * NPM package.  For example, if the NPM package is "@scope/rush-business-policy-plugin"
       * then the plugin name might be "business-policy" and with config file "business-policy.json".
       */
      "pluginName": "example",

      /**
       * (Required) Provide some documentation that summarizes the problem solved by this plugin,
       * how to invoke it, and what operations it performs.
       */
      "description": "An example plugin",

      /**
       * (Optional) A path to a JavaScript code module that implements the "IRushPlugin" interface.
       * This module can use the "@rushstack/rush-sdk" API to register handlers for Rush events
       * and services.  The module path is relative to the folder containing the "package.json" file.
       */
      // "entryPoint": "lib/example/RushExamplePlugin.js",

      /**
       * (Optional) A path to a "command-line.json" file that defines Rush command line actions
       * and parameters contributed by this plugin.  This config file has the same JSON schema
       * as Rush's "common/config/rush/command-line.json" file.
       */
      // "commandLineJsonFilePath": "lib/example/command-line.json",

      /**
       * (Optional) A path to a JSON schema for validating the config file that end users can
       * create to customize this plugin's behavior.  Plugin config files are stored in the folder
       * "common/config/rush-plugins/" with a filename corresponding to the "pluginName" field
       * from the manifest.  For example: "common/config/rush-plugins/business-policy.json"
       * whose schema is "business-policy.schema.json".
       */
      // "optionsSchema": "lib/example/example.schema.json",

      /**
       * (Optional) A list of associated Rush command names such as "build" from "rush build".
       * If specified, then the plugin's "entryPoint" code module be loaded only if
       * one of the specified commands is invoked.  This improves performance by avoiding
       * loading the code module when it is not needed.  If "associatedCommands" is
       * not specified, then the code module will always be loaded.
       */
      // "associatedCommands": [ "build" ]
    }
  ]
}

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/rush-plugins_json/index.html b/pages/configs/rush-plugins_json/index.html index 5e845181..121f8a47 100644 --- a/pages/configs/rush-plugins_json/index.html +++ b/pages/configs/rush-plugins_json/index.html @@ -6,14 +6,14 @@ rush-plugins.json (experimental) | Rush - +
Rush StackShopBlogEvents

rush-plugins.json (experimental)

This is the template for the rush-plugins.json file that is used to enable Rush plugins.

common/config/rush/command-line.json

/**
 * This configuration file manages Rush's plugin feature.
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush-plugins.schema.json",
  "plugins": [
    /**
     * Each item configures a plugin to be loaded by Rush.
     */
    // {
    //   /**
    //    * The name of the NPM package that provides the plugin.
    //    */
    //   "packageName": "@scope/my-rush-plugin",
    //   /**
    //    * The name of the plugin.  This can be found in the "pluginName"
    //    * field of the "rush-plugin-manifest.json" file in the NPM package folder.
    //    */
    //   "pluginName": "my-plugin-name",
    //   /**
    //    * The name of a Rush autoinstaller that will be used for installation, which
    //    * can be created using "rush init-autoinstaller".  Add the plugin's NPM package
    //    * to the package.json "dependencies" of your autoinstaller, then run
    //    * "rush update-autoinstaller".
    //    */
    //   "autoinstallerName": "rush-plugins"
    // }
  ]
}

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/rush-project_json/index.html b/pages/configs/rush-project_json/index.html index 41012626..fadeadb9 100644 --- a/pages/configs/rush-project_json/index.html +++ b/pages/configs/rush-project_json/index.html @@ -6,14 +6,14 @@ rush-project.json | Rush - +
Rush StackShopBlogEvents

rush-project.json

This is the template for the optional rush-project.json config file. This file may be provided by a rig package.

<your project>/config/rush-project.json

/**
 * The "config/rush-project.json" file configures Rush-specific settings for an individual project
 * in a Rush monorepo.  More documentation is available on the Rush website: https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush-project.schema.json",

  /**
   * Optionally specifies another JSON config file that this file extends from. This provides a way for standard
   * settings to be shared across multiple projects.
   */
  // "extends": "my-rig/profiles/default/config/rush-project.json",

  /**
   * The incremental analyzer can skip Rush commands for projects whose input files have not changed since
   * the last build.  Normally, every Git-tracked file under the project folder is assumed to be an input.
   * Use "incrementalBuildIgnoredGlobs" to ignore specific files, specified as globs relative to
   * the project folder.  The glob syntax is based on the .gitignore file format.
   */
  "incrementalBuildIgnoredGlobs": [
    // "etc/api-report/*.md"
  ],

  /**
   * Disable caching for this project. The project will never be restored from cache. This may be useful
   * if this project affects state outside of its folder.
   *
   * Default value: false
   */
  // "disableBuildCacheForProject": true,

  /**
   * Options for individual commands and phases.
   */
  "operationSettings": [
    // {
    //   /**
    //    * (Required) The name of the operation.
    //    * This should be a key in the "package.json" file's "scripts" section.
    //    */
    //   "operationName": "build",
    //
    //   /**
    //    * Specify the folders where this operation writes its output files.  If enabled, the Rush build cache
    //    * will restore these folders from the cache.  The strings are folder names under the project root folder.
    //    * These folders should not be tracked by Git.  They must not contain symlinks.
    //    */
    //   "outputFolderNames": [
    //     "lib", "dist"
    //   ],
    //
    //   /**
    //    * Specify a list of glob (minimatch) paths (absolute or relative) pointing to files
    //    * (within or outside the .git repository) that affect the output of this operation.
    //    * If provided, the hash values of these files will become part of the final hash when
    //    * reading and writing from cache.
    //    */
    //   "dependsOnAdditionalFiles": [],
    //
    //   /**
    //    * Specify a list of environment variables that affect the output of this operation.
    //    * If provided, the values of these variables will become part of the hash when reading
    //    * and writing from cache.
    //    */
    //   "dependsOnEnvVars": [ "MY_ENVIRONMENT_VARIABLE" ],
    //
    //   /**
    //    * Disable caching for this operation.  The operation will never be restored from cache.
    //    * This may be useful if this operation affects state outside of its folder.
    //    */
    //   // "disableBuildCacheForOperation": true
    // }
  ]
}

See also​

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/rush_json/index.html b/pages/configs/rush_json/index.html index 1962fe52..4e8673bc 100644 --- a/pages/configs/rush_json/index.html +++ b/pages/configs/rush_json/index.html @@ -6,14 +6,14 @@ rush.json | Rush - +
Rush StackShopBlogEvents

rush.json

This is the template that rush init -generates for rush.json (in the repo root folder):

<repo root>rush.json

/**
 * This is the main configuration file for Rush.
 * For full documentation, please see https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",

  /**
   * (Required) This specifies the version of the Rush engine to be used in this repo.
   * Rush's "version selector" feature ensures that the globally installed tool will
   * behave like this release, regardless of which version is installed globally.
   *
   * The common/scripts/install-run-rush.js automation script also uses this version.
   *
   * NOTE: If you upgrade to a new major version of Rush, you should replace the "v5"
   * 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.82.1",

  /**
   * The next field selects which package manager should be installed and determines its version.
   * Rush installs its own local copy of the package manager to ensure that your build process
   * is fully isolated from whatever tools are present in the local environment.
   *
   * Specify one of: "pnpmVersion", "npmVersion", or "yarnVersion".  See the Rush documentation
   * for details about these alternatives.
   */
  "pnpmVersion": "6.7.1",

  // "npmVersion": "6.14.15",
  // "yarnVersion": "1.9.4",

  /**
   * Older releases of the Node.js engine may be missing features required by your system.
   * Other releases may have bugs.  In particular, the "latest" version will not be a
   * Long Term Support (LTS) version and is likely to have regressions.
   *
   * Specify a SemVer range to ensure developers use a Node.js version that is appropriate
   * for your repo.
   *
   * LTS schedule: https://nodejs.org/en/about/releases/
   * LTS versions: https://nodejs.org/en/download/releases/
   */
  "nodeSupportedVersionRange": ">=12.13.0 <13.0.0 || >=14.15.0 <15.0.0 || >=16.13.0 <17.0.0",

  /**
   * Odd-numbered major versions of Node.js are experimental.  Even-numbered releases
   * spend six months in a stabilization period before the first Long Term Support (LTS) version.
   * For example, 8.9.0 was the first LTS version of Node.js 8.  Pre-LTS versions are not recommended
   * for production usage because they frequently have bugs.  They may cause Rush itself
   * to malfunction.
   *
   * Rush normally prints a warning if it detects a pre-LTS Node.js version.  If you are testing
   * pre-LTS versions in preparation for supporting the first LTS version, you can use this setting
   * to disable Rush's warning.
   */
  // "suppressNodeLtsWarning": 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.
   */
  // "ensureConsistentVersions": true,

  /**
   * 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,
   * we've found that teams will often use subfolders to create islands that isolate
   * their work from others ("shipping the org").  This hinders collaboration and code sharing.
   *
   * 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", "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
   * of projects.  In practice, you will find that the folder hierarchy needs to be rebalanced
   * occasionally, but if that's painful, it's a warning sign that your development style may
   * discourage refactoring.  Reorganizing the categories should be an enlightening discussion
   * that brings people together, and maybe also identifies poor coding practices (e.g. file
   * references that reach into other project's folders without using Node.js module resolution).
   *
   * The defaults are projectFolderMinDepth=1 and projectFolderMaxDepth=2.
   *
   * To remove these restrictions, you could set projectFolderMinDepth=1
   * and set projectFolderMaxDepth to a large number.
   */
  // "projectFolderMinDepth": 2,
  // "projectFolderMaxDepth": 2,

  /**
   * Today the npmjs.com registry enforces fairly strict naming rules for packages, but in the early
   * days there was no standard and hardly any enforcement.  A few large legacy projects are still using
   * nonstandard package names, and private registries sometimes allow it.  Set "allowMostlyStandardPackageNames"
   * to true to relax Rush's enforcement of package names.  This allows upper case letters and in the future may
   * relax other rules, however we want to minimize these exceptions.  Many popular tools use certain punctuation
   * characters as delimiters, based on the assumption that they will never appear in a package name; thus if we relax
   * the rules too much it is likely to cause very confusing malfunctions.
   *
   * The default value is false.
   */
  // "allowMostlyStandardPackageNames": true,

  /**
   * This feature helps you to review and approve new packages before they are introduced
   * to your monorepo.  For example, you may be concerned about licensing, code quality,
   * performance, or simply accumulating too many libraries with overlapping functionality.
   * The approvals are tracked in two config files "browser-approved-packages.json"
   * and "nonbrowser-approved-packages.json".  See the Rush documentation for details.
   */
  // "approvedPackagesPolicy": {
  //   /**
  //    * The review categories allow you to say for example "This library is approved for usage
  //    * in prototypes, but not in production code."
  //    *
  //    * Each project can be associated with one review category, by assigning the "reviewCategory" field
  //    * in the "projects" section of rush.json.  The approval is then recorded in the files
  //    * "common/config/rush/browser-approved-packages.json" and "nonbrowser-approved-packages.json"
  //    * which are automatically generated during "rush update".
  //    *
  //    * Designate categories with whatever granularity is appropriate for your review process,
  //    * or you could just have a single category called "default".
  //    */
  //   "reviewCategories": [
  //     // Some example categories:
  //     "production", // projects that ship to production
  //     "tools",      // non-shipping projects that are part of the developer toolchain
  //     "prototypes"  // experiments that should mostly be ignored by the review process
  //   ],
  //
  //   /**
  //    * A list of NPM package scopes that will be excluded from review.
  //    * We recommend to exclude TypeScript typings (the "@types" scope), because
  //    * if the underlying package was already approved, this would imply that the typings
  //    * are also approved.
  //    */
  //   // "ignoredNpmScopes": ["@types"]
  // },

  /**
   * If you use Git as your version control system, this section has some additional
   * optional features you can use.
   */
  "gitPolicy": {
    /**
     * Work at a big company?  Tired of finding Git commits at work with unprofessional Git
     * emails such as "beer-lover@my-college.edu"?  Rush can validate people's Git email address
     * before they get started.
     *
     * Define a list of regular expressions describing allowable e-mail patterns for Git commits.
     * 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 backslashes, and ordinary periods should be "\\.".
     */
    // "allowedEmailRegExps": [
    //   "[^@]+@users\\.noreply\\.github\\.com",
    //   "rush-bot@example\\.org"
    // ],

    /**
     * When Rush reports that the address is malformed, the notice can include an example
     * of a recommended email.  Make sure it conforms to one of the allowedEmailRegExps
     * expressions.
     */
    // "sampleEmail": "example@users.noreply.github.com",

    /**
     * The commit message to use when committing changes during 'rush publish'.
     *
     * For example, if you want to prevent these commits from triggering a CI build,
     * you might configure your system's trigger to look for a special string such as "[skip-ci]"
     * in the commit message, and then customize Rush's message to contain that string.
     */
    // "versionBumpCommitMessage": "Bump versions [skip ci]",

    /**
     * The commit message to use when committing changes during 'rush version'.
     *
     * For example, if you want to prevent these commits from triggering a CI build,
     * you might configure your system's trigger to look for a special string such as "[skip-ci]"
     * in the commit message, and then customize Rush's message to contain that string.
     */
    // "changeLogUpdateCommitMessage": "Update changelogs [skip ci]",

    /**
     * The commit message to use when commiting changefiles during 'rush change --commit'
     *
     * If no commit message is set it will default to 'Rush change'
     */
     // "changefilesCommitMessage": "Rush change"
  },

  "repository": {
    /**
     * The URL of this Git repository, used by "rush change" to determine the base branch for your PR.
     *
     * The "rush change" command needs to determine which files are affected by your PR diff.
     * If you merged or cherry-picked commits from the main branch into your PR branch, those commits
     * should be excluded from this diff (since they belong to some other PR).  In order to do that,
     * Rush needs to know where to find the base branch for your PR.  This information cannot be
     * determined from Git alone, since the "pull request" feature is not a Git concept.  Ideally
     * Rush would use a vendor-specific protocol to query the information from GitHub, Azure DevOps, etc.
     * But to keep things simple, "rush change" simply assumes that your PR is against the "main" branch
     * of the Git remote indicated by the repository.url setting in rush.json.  If you are working in
     * a GitHub "fork" of the real repo, this setting will be different from the repository URL of your
     * your PR branch, and in this situation "rush change" will also automatically invoke "git fetch"
     * to retrieve the latest activity for the remote main branch.
     */
    // "url": "https://github.com/microsoft/rush-example",

    /**
     * The default branch name. This tells "rush change" which remote branch to compare against.
     * The default value is "main"
     */
    // "defaultBranch": "main",

    /**
     * The default remote. This tells "rush change" which remote to compare against if the remote URL is
     * not set or if a remote matching the provided remote URL is not found.
     */
    // "defaultRemote": "origin"
  },

  /**
   * Event hooks are customized script actions that Rush executes when specific events occur
   */
  "eventHooks": {
    /**
     * The list of shell commands to run before the Rush installation starts
     */
    "preRushInstall": [
      // "common/scripts/pre-rush-install.js"
    ],

    /**
     * The list of shell commands to run after the Rush installation finishes
     */
    "postRushInstall": [],

    /**
     * The list of shell commands to run before the Rush build command starts
     */
    "preRushBuild": [],

    /**
     * The list of shell commands to run after the Rush build command finishes
     */
    "postRushBuild": []
  },

  /**
   * 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
   * problems with your toolchain or Rush itself.  THIS TELEMETRY IS NOT SHARED WITH MICROSOFT.
   * It is written into JSON files in the common/temp folder.  It's up to you to write scripts
   * that read these JSON files and do something with them.  These scripts are typically registered
   * in the "eventHooks" section.
   */
  // "telemetryEnabled": false,

  /**
   * Allows creation of hotfix changes. This feature is experimental so it is disabled by default.
   * If this is set, 'rush change' only allows a 'hotfix' change type to be specified. This change type
   * will be used when publishing subsequent changes from the monorepo.
   */
  // "hotfixChangeEnabled": false,

  /**
    * This is an optional, but recommended, list of allowed tags that can be applied to Rush projects
    * using the "tags" setting in this file.  This list is useful for preventing mistakes such as misspelling,
    * and it also provides a centralized place to document your tags.  If "allowedProjectTags" list is
    * not specified, then any valid tag is allowed.  A tag name must be one or more words
    * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,
    * ".", and "@" characters.
    */
  // "allowedProjectTags": [ "tools", "frontend-team", "1.0.0-release" ],

  /**
   * (Required) This is the inventory of projects to be managed by Rush.
   *
   * Rush does not automatically scan for projects using wildcards, for a few reasons:
   * 1. Depth-first scans are expensive, particularly when tools need to repeatedly collect the list.
   * 2. On a caching CI machine, scans can accidentally pick up files left behind from a previous build.
   * 3. It's useful to have a centralized inventory of all projects and their important metadata.
   */
  "projects": [
    // {
    //   /**
    //    * The NPM package name of the project (must match package.json)
    //    */
    //   "packageName": "my-app",
    //
    //   /**
    //    * The path to the project folder, relative to the rush.json config file.
    //    */
    //   "projectFolder": "apps/my-app",
    //
    //   /**
    //    * An optional category for usage in the "browser-approved-packages.json"
    //    * and "nonbrowser-approved-packages.json" files.  The value must be one of the
    //    * strings from the "reviewCategories" defined above.
    //    */
    //   "reviewCategory": "production",
    //
    //   /**
    //    * A list of Rush project names that are to be installed from NPM
    //    * instead of linking to the local project.
    //    *
    //    * If a project's package.json specifies a dependency that is another Rush project
    //    * in the monorepo workspace, normally Rush will locally link its folder instead of
    //    * installing from NPM.  If you are using PNPM workspaces, this is indicated by
    //    * a SemVer range such as "workspace:^1.2.3".  To prevent mistakes, Rush reports
    //    * an error if the "workspace:" protocol is missing.
    //    *
    //    * Locally linking ensures that regressions are caught as early as possible and is
    //    * a key benefit of monorepos.  However there are occasional situations where
    //    * installing from NPM is needed.  A classic example is a cyclic dependency.
    //    * Imagine three Rush projects: "my-toolchain" depends on "my-tester", which depends
    //    * on "my-library".  Suppose that we add "my-toolchain" to the "devDependencies"
    //    * of "my-library" so it can be built by our toolchain.  This cycle creates
    //    * a problem -- Rush can't build a project using a not-yet-built dependency.
    //    * We can solve it by adding "my-toolchain" to the "decoupledLocalDependencies"
    //    * of "my-library", so it builds using the last published release.  Choose carefully
    //    * which package to decouple; some choices are much easier to manage than others.
    //    *
    //    * (In older Rush releases, this setting was called "cyclicDependencyProjects".)
    //    */
    //   "decoupledLocalDependencies": [
    //     // "my-toolchain"
    //   ],
    //
    //   /**
    //    * If true, then this project will be ignored by the "rush check" command.
    //    * The default value is false.
    //    */
    //   // "skipRushCheck": false,
    //
    //   /**
    //    * A flag indicating that changes to this project will be published to npm, which affects
    //    * the Rush change and publish workflows. The default value is false.
    //    * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.
    //    */
    //   // "shouldPublish": false,
    //
    //   /**
    //    * Facilitates postprocessing of a project's files prior to publishing.
    //    *
    //    * If specified, the "publishFolder" is the relative path to a subfolder of the project folder.
    //    * The "rush publish" command will publish the subfolder instead of the project folder.  The subfolder
    //    * must contain its own package.json file, which is typically a build output.
    //    */
    //   // "publishFolder": "temp/publish",
    //
    //   /**
    //    * An optional version policy associated with the project.  Version policies are defined
    //    * in "version-policies.json" file.  See the "rush publish" documentation for more info.
    //    * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.
    //    */
    //   // "versionPolicyName": "",
    //
    //   /**
    //    * An optional set of custom tags that can be used to select this project.  For example,
    //    * adding "my-custom-tag" will allow this project to be selected by the
    //    * command "rush list --only tag:my-custom-tag".  The tag name must be one or more words
    //    * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,
    //    * ".", and "@" characters.
    //    */
    //   // "tags": [ "1.0.0-release", "frontend-team" ]
    // },
    //
    // {
    //   "packageName": "my-controls",
    //   "projectFolder": "libraries/my-controls",
    //   "reviewCategory": "production",
    //   "tags": [ "frontend-team" ]
    // },
    //
    // {
    //   "packageName": "my-toolchain",
    //   "projectFolder": "tools/my-toolchain",
    //   "reviewCategory": "tools",
    //   "tags": [ "tools" ]
    // }
  ]
}
© 2023 Microsoft
- +generates for rush.json (in the repo root folder):

<repo root>rush.json

/**
 * This is the main configuration file for Rush.
 * For full documentation, please see https://rushjs.io
 */
{
  "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",

  /**
   * (Required) This specifies the version of the Rush engine to be used in this repo.
   * Rush's "version selector" feature ensures that the globally installed tool will
   * behave like this release, regardless of which version is installed globally.
   *
   * The common/scripts/install-run-rush.js automation script also uses this version.
   *
   * NOTE: If you upgrade to a new major version of Rush, you should replace the "v5"
   * 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.110.0",

  /**
   * The next field selects which package manager should be installed and determines its version.
   * Rush installs its own local copy of the package manager to ensure that your build process
   * is fully isolated from whatever tools are present in the local environment.
   *
   * Specify one of: "pnpmVersion", "npmVersion", or "yarnVersion".  See the Rush documentation
   * for details about these alternatives.
   */
  "pnpmVersion": "7.33.5",

  // "npmVersion": "6.14.15",
  // "yarnVersion": "1.9.4",

  /**
   * Older releases of the Node.js engine may be missing features required by your system.
   * Other releases may have bugs.  In particular, the "latest" version will not be a
   * Long Term Support (LTS) version and is likely to have regressions.
   *
   * Specify a SemVer range to ensure developers use a Node.js version that is appropriate
   * for your repo.
   *
   * LTS schedule: https://nodejs.org/en/about/releases/
   * LTS versions: https://nodejs.org/en/download/releases/
   */
  "nodeSupportedVersionRange": ">=14.15.0 <15.0.0 || >=16.13.0 <17.0.0 || >=18.15.0 <19.0.0",

  /**
   * If the version check above fails, Rush will display a message showing the current
   * node version and the supported version range. You can use this setting to provide
   * additional instructions that will display below the warning, if there's a specific
   * tool or script you'd like the user to use to get in line with the expected version.
   */
  // "nodeSupportedVersionInstructions": "Run 'nvs use' to switch to the expected node version.",

  /**
   * Odd-numbered major versions of Node.js are experimental.  Even-numbered releases
   * spend six months in a stabilization period before the first Long Term Support (LTS) version.
   * For example, 8.9.0 was the first LTS version of Node.js 8.  Pre-LTS versions are not recommended
   * for production usage because they frequently have bugs.  They may cause Rush itself
   * to malfunction.
   *
   * Rush normally prints a warning if it detects a pre-LTS Node.js version.  If you are testing
   * pre-LTS versions in preparation for supporting the first LTS version, you can use this setting
   * to disable Rush's warning.
   */
  // "suppressNodeLtsWarning": 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.
   */
  // "ensureConsistentVersions": true,

  /**
   * 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,
   * we've found that teams will often use subfolders to create islands that isolate
   * their work from others ("shipping the org").  This hinders collaboration and code sharing.
   *
   * 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", "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
   * of projects.  In practice, you will find that the folder hierarchy needs to be rebalanced
   * occasionally, but if that's painful, it's a warning sign that your development style may
   * discourage refactoring.  Reorganizing the categories should be an enlightening discussion
   * that brings people together, and maybe also identifies poor coding practices (e.g. file
   * references that reach into other project's folders without using Node.js module resolution).
   *
   * The defaults are projectFolderMinDepth=1 and projectFolderMaxDepth=2.
   *
   * To remove these restrictions, you could set projectFolderMinDepth=1
   * and set projectFolderMaxDepth to a large number.
   */
  // "projectFolderMinDepth": 2,
  // "projectFolderMaxDepth": 2,

  /**
   * Today the npmjs.com registry enforces fairly strict naming rules for packages, but in the early
   * days there was no standard and hardly any enforcement.  A few large legacy projects are still using
   * nonstandard package names, and private registries sometimes allow it.  Set "allowMostlyStandardPackageNames"
   * to true to relax Rush's enforcement of package names.  This allows upper case letters and in the future may
   * relax other rules, however we want to minimize these exceptions.  Many popular tools use certain punctuation
   * characters as delimiters, based on the assumption that they will never appear in a package name; thus if we relax
   * the rules too much it is likely to cause very confusing malfunctions.
   *
   * The default value is false.
   */
  // "allowMostlyStandardPackageNames": true,

  /**
   * This feature helps you to review and approve new packages before they are introduced
   * to your monorepo.  For example, you may be concerned about licensing, code quality,
   * performance, or simply accumulating too many libraries with overlapping functionality.
   * The approvals are tracked in two config files "browser-approved-packages.json"
   * and "nonbrowser-approved-packages.json".  See the Rush documentation for details.
   */
  // "approvedPackagesPolicy": {
  //   /**
  //    * The review categories allow you to say for example "This library is approved for usage
  //    * in prototypes, but not in production code."
  //    *
  //    * Each project can be associated with one review category, by assigning the "reviewCategory" field
  //    * in the "projects" section of rush.json.  The approval is then recorded in the files
  //    * "common/config/rush/browser-approved-packages.json" and "nonbrowser-approved-packages.json"
  //    * which are automatically generated during "rush update".
  //    *
  //    * Designate categories with whatever granularity is appropriate for your review process,
  //    * or you could just have a single category called "default".
  //    */
  //   "reviewCategories": [
  //     // Some example categories:
  //     "production", // projects that ship to production
  //     "tools",      // non-shipping projects that are part of the developer toolchain
  //     "prototypes"  // experiments that should mostly be ignored by the review process
  //   ],
  //
  //   /**
  //    * A list of NPM package scopes that will be excluded from review.
  //    * We recommend to exclude TypeScript typings (the "@types" scope), because
  //    * if the underlying package was already approved, this would imply that the typings
  //    * are also approved.
  //    */
  //   // "ignoredNpmScopes": ["@types"]
  // },

  /**
   * If you use Git as your version control system, this section has some additional
   * optional features you can use.
   */
  "gitPolicy": {
    /**
     * Work at a big company?  Tired of finding Git commits at work with unprofessional Git
     * emails such as "beer-lover@my-college.edu"?  Rush can validate people's Git email address
     * before they get started.
     *
     * Define a list of regular expressions describing allowable e-mail patterns for Git commits.
     * 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 backslashes, and ordinary periods should be "\\.".
     */
    // "allowedEmailRegExps": [
    //   "[^@]+@users\\.noreply\\.github\\.com",
    //   "rush-bot@example\\.org"
    // ],

    /**
     * When Rush reports that the address is malformed, the notice can include an example
     * of a recommended email.  Make sure it conforms to one of the allowedEmailRegExps
     * expressions.
     */
    // "sampleEmail": "example@users.noreply.github.com",

    /**
     * The commit message to use when committing changes during 'rush publish'.
     *
     * For example, if you want to prevent these commits from triggering a CI build,
     * you might configure your system's trigger to look for a special string such as "[skip-ci]"
     * in the commit message, and then customize Rush's message to contain that string.
     */
    // "versionBumpCommitMessage": "Bump versions [skip ci]",

    /**
     * The commit message to use when committing changes during 'rush version'.
     *
     * For example, if you want to prevent these commits from triggering a CI build,
     * you might configure your system's trigger to look for a special string such as "[skip-ci]"
     * in the commit message, and then customize Rush's message to contain that string.
     */
    // "changeLogUpdateCommitMessage": "Update changelogs [skip ci]",

    /**
     * The commit message to use when commiting changefiles during 'rush change --commit'
     *
     * If no commit message is set it will default to 'Rush change'
     */
     // "changefilesCommitMessage": "Rush change"
  },

  "repository": {
    /**
     * The URL of this Git repository, used by "rush change" to determine the base branch for your PR.
     *
     * The "rush change" command needs to determine which files are affected by your PR diff.
     * If you merged or cherry-picked commits from the main branch into your PR branch, those commits
     * should be excluded from this diff (since they belong to some other PR).  In order to do that,
     * Rush needs to know where to find the base branch for your PR.  This information cannot be
     * determined from Git alone, since the "pull request" feature is not a Git concept.  Ideally
     * Rush would use a vendor-specific protocol to query the information from GitHub, Azure DevOps, etc.
     * But to keep things simple, "rush change" simply assumes that your PR is against the "main" branch
     * of the Git remote indicated by the repository.url setting in rush.json.  If you are working in
     * a GitHub "fork" of the real repo, this setting will be different from the repository URL of your
     * your PR branch, and in this situation "rush change" will also automatically invoke "git fetch"
     * to retrieve the latest activity for the remote main branch.
     */
    // "url": "https://github.com/microsoft/rush-example",

    /**
     * The default branch name. This tells "rush change" which remote branch to compare against.
     * The default value is "main"
     */
    // "defaultBranch": "main",

    /**
     * The default remote. This tells "rush change" which remote to compare against if the remote URL is
     * not set or if a remote matching the provided remote URL is not found.
     */
    // "defaultRemote": "origin"
  },

  /**
   * Event hooks are customized script actions that Rush executes when specific events occur
   */
  "eventHooks": {
    /**
     * A list of shell commands to run before "rush install" or "rush update" starts installation
     */
    "preRushInstall": [
      // "common/scripts/pre-rush-install.js"
    ],

    /**
     * A list of shell commands to run after "rush install" or "rush update" finishes installation
     */
    "postRushInstall": [],

    /**
     * A list of shell commands to run before "rush build" or "rush rebuild" starts building
     */
    "preRushBuild": [],

    /**
     * A list of shell commands to run after "rush build" or "rush rebuild" finishes building
     */
    "postRushBuild": [],

    /**
     * A list of shell commands to run before the "rushx" command starts
     */
    "preRushx": [],

    /**
     * A list of shell commands to run after the "rushx" command finishes
     */
    "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
   * problems with your toolchain or Rush itself.  THIS TELEMETRY IS NOT SHARED WITH MICROSOFT.
   * It is written into JSON files in the common/temp folder.  It's up to you to write scripts
   * that read these JSON files and do something with them.  These scripts are typically registered
   * in the "eventHooks" section.
   */
  // "telemetryEnabled": false,

  /**
   * Allows creation of hotfix changes. This feature is experimental so it is disabled by default.
   * If this is set, 'rush change' only allows a 'hotfix' change type to be specified. This change type
   * will be used when publishing subsequent changes from the monorepo.
   */
  // "hotfixChangeEnabled": false,

  /**
    * This is an optional, but recommended, list of allowed tags that can be applied to Rush projects
    * using the "tags" setting in this file.  This list is useful for preventing mistakes such as misspelling,
    * and it also provides a centralized place to document your tags.  If "allowedProjectTags" list is
    * not specified, then any valid tag is allowed.  A tag name must be one or more words
    * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,
    * ".", and "@" characters.
    */
  // "allowedProjectTags": [ "tools", "frontend-team", "1.0.0-release" ],

  /**
   * (Required) This is the inventory of projects to be managed by Rush.
   *
   * Rush does not automatically scan for projects using wildcards, for a few reasons:
   * 1. Depth-first scans are expensive, particularly when tools need to repeatedly collect the list.
   * 2. On a caching CI machine, scans can accidentally pick up files left behind from a previous build.
   * 3. It's useful to have a centralized inventory of all projects and their important metadata.
   */
  "projects": [
    // {
    //   /**
    //    * The NPM package name of the project (must match package.json)
    //    */
    //   "packageName": "my-app",
    //
    //   /**
    //    * The path to the project folder, relative to the rush.json config file.
    //    */
    //   "projectFolder": "apps/my-app",
    //
    //   /**
    //    * An optional category for usage in the "browser-approved-packages.json"
    //    * and "nonbrowser-approved-packages.json" files.  The value must be one of the
    //    * strings from the "reviewCategories" defined above.
    //    */
    //   "reviewCategory": "production",
    //
    //   /**
    //    * A list of Rush project names that are to be installed from NPM
    //    * instead of linking to the local project.
    //    *
    //    * If a project's package.json specifies a dependency that is another Rush project
    //    * in the monorepo workspace, normally Rush will locally link its folder instead of
    //    * installing from NPM.  If you are using PNPM workspaces, this is indicated by
    //    * a SemVer range such as "workspace:^1.2.3".  To prevent mistakes, Rush reports
    //    * an error if the "workspace:" protocol is missing.
    //    *
    //    * Locally linking ensures that regressions are caught as early as possible and is
    //    * a key benefit of monorepos.  However there are occasional situations where
    //    * installing from NPM is needed.  A classic example is a cyclic dependency.
    //    * Imagine three Rush projects: "my-toolchain" depends on "my-tester", which depends
    //    * on "my-library".  Suppose that we add "my-toolchain" to the "devDependencies"
    //    * of "my-library" so it can be built by our toolchain.  This cycle creates
    //    * a problem -- Rush can't build a project using a not-yet-built dependency.
    //    * We can solve it by adding "my-toolchain" to the "decoupledLocalDependencies"
    //    * of "my-library", so it builds using the last published release.  Choose carefully
    //    * which package to decouple; some choices are much easier to manage than others.
    //    *
    //    * (In older Rush releases, this setting was called "cyclicDependencyProjects".)
    //    */
    //   "decoupledLocalDependencies": [
    //     // "my-toolchain"
    //   ],
    //
    //   /**
    //    * If true, then this project will be ignored by the "rush check" command.
    //    * The default value is false.
    //    */
    //   // "skipRushCheck": false,
    //
    //   /**
    //    * A flag indicating that changes to this project will be published to npm, which affects
    //    * the Rush change and publish workflows. The default value is false.
    //    * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.
    //    */
    //   // "shouldPublish": false,
    //
    //   /**
    //    * Facilitates postprocessing of a project's files prior to publishing.
    //    *
    //    * If specified, the "publishFolder" is the relative path to a subfolder of the project folder.
    //    * The "rush publish" command will publish the subfolder instead of the project folder.  The subfolder
    //    * must contain its own package.json file, which is typically a build output.
    //    */
    //   // "publishFolder": "temp/publish",
    //
    //   /**
    //    * An optional version policy associated with the project.  Version policies are defined
    //    * in "version-policies.json" file.  See the "rush publish" documentation for more info.
    //    * NOTE: "versionPolicyName" and "shouldPublish" are alternatives; you cannot specify them both.
    //    */
    //   // "versionPolicyName": "",
    //
    //   /**
    //    * An optional set of custom tags that can be used to select this project.  For example,
    //    * adding "my-custom-tag" will allow this project to be selected by the
    //    * command "rush list --only tag:my-custom-tag".  The tag name must be one or more words
    //    * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,
    //    * ".", and "@" characters.
    //    */
    //   // "tags": [ "1.0.0-release", "frontend-team" ]
    // },
    //
    // {
    //   "packageName": "my-controls",
    //   "projectFolder": "libraries/my-controls",
    //   "reviewCategory": "production",
    //   "tags": [ "frontend-team" ]
    // },
    //
    // {
    //   "packageName": "my-toolchain",
    //   "projectFolder": "tools/my-toolchain",
    //   "reviewCategory": "tools",
    //   "tags": [ "tools" ]
    // }
  ]
}
© 2023 Microsoft
+ \ No newline at end of file diff --git a/pages/configs/version-policies_json/index.html b/pages/configs/version-policies_json/index.html index 5d1bb7bf..9a2263eb 100644 --- a/pages/configs/version-policies_json/index.html +++ b/pages/configs/version-policies_json/index.html @@ -6,14 +6,14 @@ version-policies.json | Rush - +
Rush StackShopBlogEvents

version-policies.json

This is the template that rush init generates for version-policies.json:

common/config/rush/version-policies.json

/**
 * This is configuration file is used for advanced publishing configurations with Rush.
 * More documentation is available on the Rush website: https://rushjs.io
 */

/**
 * A list of version policy definitions.  A "version policy" is a custom package versioning
 * strategy that affects "rush change", "rush version", and "rush publish".  The strategy applies
 * to a set of projects that are specified using the "versionPolicyName" field in rush.json.
 */
[
  // {
  //   /**
  //    * (Required) Indicates the kind of version policy being defined ("lockStepVersion" or "individualVersion").
  //    *
  //    * The "lockStepVersion" mode specifies that the projects will use "lock-step versioning".  This
  //    * strategy is appropriate for a set of packages that act as selectable components of a
  //    * unified product.  The entire set of packages are always published together, and always share
  //    * the same NPM version number.  When the packages depend on other packages in the set, the
  //    * SemVer range is usually restricted to a single version.
  //    */
  //   "definitionName": "lockStepVersion",
  //
  //   /**
  //    * (Required) The name that will be used for the "versionPolicyName" field in rush.json.
  //    * This name is also used command-line parameters such as "--version-policy"
  //    * and "--to-version-policy".
  //    */
  //   "policyName": "MyBigFramework",
  //
  //   /**
  //    * (Required) The current version.  All packages belonging to the set should have this version
  //    * in the current branch.  When bumping versions, Rush uses this to determine the next version.
  //    * (The "version" field in package.json is NOT considered.)
  //    */
  //   "version": "1.0.0",
  //
  //   /**
  //    * (Required) The type of bump that will be performed when publishing the next release.
  //    * When creating a release branch in Git, this field should be updated according to the
  //    * type of release.
  //    *
  //    * Valid values are: "prerelease", "release", "minor", "patch", "major"
  //    */
  //   "nextBump": "prerelease",
  //
  //   /**
  //    * (Optional) If specified, all packages in the set share a common CHANGELOG.md file.
  //    * This file is stored with the specified "main" project, which must be a member of the set.
  //    *
  //    * If this field is omitted, then a separate CHANGELOG.md file will be maintained for each
  //    * package in the set.
  //    */
  //   "mainProject": "my-app",
  //
  //   /**
  //    * (Optional) If enabled, the "rush change" command will prompt the user for their email address
  //    * and include it in the JSON change files.  If an organization maintains multiple repos, tracking
  //    * this contact information may be useful for a service that automatically upgrades packages and
  //    * needs to notify engineers whose change may be responsible for a downstream build break.  It might
  //    * also be useful for crediting contributors.  Rush itself does not do anything with the collected
  //    * email addresses.  The default value is "false".
  //    */
  //   // "includeEmailInChangeFile": true
  // },
  //
  // {
  //   /**
  //    * (Required) Indicates the kind of version policy being defined ("lockStepVersion" or "individualVersion").
  //    *
  //    * The "individualVersion" mode specifies that the projects will use "individual versioning".
  //    * This is the typical NPM model where each package has an independent version number
  //    * and CHANGELOG.md file.  Although a single CI definition is responsible for publishing the
  //    * packages, they otherwise don't have any special relationship.  The version bumping will
  //    * depend on how developers answer the "rush change" questions for each package that
  //    * is changed.
  //    */
  //   "definitionName": "individualVersion",
  //
  //   "policyName": "MyRandomLibraries",
  //
  //   /**
  //    * (Optional) This can be used to enforce that all packages in the set must share a common
  //    * major version number, e.g. because they are from the same major release branch.
  //    * It can also be used to discourage people from accidentally making "MAJOR" SemVer changes
  //    * inappropriately.  The minor/patch version parts will be bumped independently according
  //    * to the types of changes made to each project, according to the "rush change" command.
  //    */
  //   "lockedMajor": 3,
  //
  //   /**
  //    * (Optional) When publishing is managed by Rush, by default the "rush change" command will
  //    * request changes for any projects that are modified by a pull request. These change entries
  //    * will produce a CHANGELOG.md file. If you author your CHANGELOG.md manually or announce updates
  //    * in some other way, set "exemptFromRushChange" to true to tell "rush change" to ignore the projects
  //    * belonging to this version policy.
  //    */
  //   "exemptFromRushChange": false,
  //
  //   // "includeEmailInChangeFile": true
  // }
];
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/configs/version_policies_json/index.html b/pages/configs/version_policies_json/index.html index 5ccd6e84..7c31abb8 100644 --- a/pages/configs/version_policies_json/index.html +++ b/pages/configs/version_policies_json/index.html @@ -6,13 +6,13 @@ version_policies_json | Rush - +
Rush StackShopBlogEvents

Redirecting...

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/contributing/index.html b/pages/contributing/index.html index 9da7ba03..f445b957 100644 --- a/pages/contributing/index.html +++ b/pages/contributing/index.html @@ -6,7 +6,7 @@ Contributing | Rush - + @@ -15,7 +15,7 @@ rushstack-websites GitHub repo.

For general instructions for building Rush and guidelines for submitting PRs, please read the Contributing documentation for the Rush Stack monorepo.

The relevant monorepo project folders are:

  • apps/rush - the command line interface front end
  • libraries/rush-lib - the automation API and "engine" where all the logic is implemented

Testing Rush builds​

Once you have coded your fix and built your branch (as described in the general Contributing notes), you will want to test your development build of Rush.

Rush features a mechanism called the version selector, which reads rushVersion from rush.json and then automatically installs and invokes that specific version of the engine. Thus if we launch your build of @microsoft/rush, it will not actually run your modified code. To bypass the version selector, we need to invoke the @microsoft/rush-lib engine directly:

cd rushstack/libraries/rush-lib

node ./lib/start.js --help

If you want to make it easy invoke your test build from other locations, we recommend to create a testrush command.

For Bash on Mac OS or Linux:

# Substitute the full path to your own build of rush-lib:
alias testrush="node ~/git/rushstack/libraries/rush-lib/lib/start.js"

For Windows, we might create testrush.cmd and add it to our system PATH:

@ECHO OFF
REM Substitute the full path to your own build of rush-lib:
node "C:\Git\rushstack\apps\rush-lib\lib\start.js" %*

Debugging Rush​

The same approach is used to debug Rush using the VS Code debugger. Create a debugger configuration file like this:

rushstack/libraries/rush-lib/.vscode/launch.json

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug Rush",
      "program": "${workspaceFolder}/lib/start.js",
      "args": [ "list", "--json" ],  // <====== specify your Rush command line arguments here
      "cwd": "(repo folder that you want to debug)"  // <===== specify your target working folder here
    }
  ]
}

After saving this file, in VS Code click "View" --> "Run" and choose your "Debug Rush" configuration from the list. Then click "Run" --> "Start Debugging" to start debugging. Breakpoints and TypeScript source maps should work correctly.

Building without unit tests​

Rush builds using the Heft toolchain. You can invoke the heft command-line directly for better additional options.

# Full incremental build of Rush and its dependencies, including unit tests
rush build --to rush-lib --verbose

# Do a quick build of "rush-lib" only without unit tests
cd rushstack/libraries/rush-lib

rushx build
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/developer/everyday_commands/index.html b/pages/developer/everyday_commands/index.html index 9e7c2c66..9516a030 100644 --- a/pages/developer/everyday_commands/index.html +++ b/pages/developer/everyday_commands/index.html @@ -6,13 +6,13 @@ Everyday commands | Rush - +
Rush StackShopBlogEvents

Everyday commands

Your daily workflow only needs a few Rush commands:

rush update​

Remember to run rush update whenever a package.json file has changed. In other words:

  • After pulling new changes from git (e.g. git pull)
  • After manually editing any project's package.json file in any way
  • After editing any common/config files that affect versions (e.g. pnpmfile.js, common-versions.json, etc.)

The rush update operation may change some files under common/config. If so, you should commit those changes to Git and include them in your PR. When in doubt, run rush update -- if everything is already up to date, it won't take any time!

What rush update does:

  1. Rush checks/applies various policies that sometimes update files under common/config.
  2. Rush compares all of your project package.json files against the repository's common shrinkwrap file to see if it's valid.
  3. If it's outdated, the package manager updates the shrinkwrap file.
  4. Either way, the package manager installs all dependencies into the common/temp/node_modules folder.
  5. Finally, Rush constructs a local node_modules folder for each project, by making symlinks into common/temp/node_modules. (This is the same operation as rush link.)

What is this "shrinkwrap file"?

Most projects don't specify an exact version such as 1.2.3 for a dependency, but instead specify SemVer range such as 1.x or ^1.2.3. By itself, this would mean that what gets installed depends on the latest version at the time. Such nondeterminism is bad: It would be maddening for a Git branch that built on Monday to mysteriously be failing on Tuesday because of a new release of a library. The shrinkwrap file solves this problem by storing a complete installation plan in a large file that is tracked by Git.

The shrinkwrap file has different names depending on the package manager that your repo is using: shrinkwrap.yaml, npm-shrinkwrap.json, or yarn.lock

You will notice that automated CI jobs use rush install instead of rush update. The difference is that rush install won't update any files. Instead, it will fail your PR build if something is out of date, to let you know that you forgot to run rush update or forgot to commit the result. (Some people choose to use rush install as their everyday command, in order to catch unintended changes to the shrinkwrap file.)

rush rebuild​

Once you've pulled the latest changes, it's time to compile everything. rush rebuild does a full, clean build of every project in the repository.

If your toolchain supports incremental builds, you can also use rush build to build only the projects that have changed.

rushx​

If you want to build just one project, you can use the rushx command. You run it under the project folder that you want to operate on. The rushx command is analogous to npm run, but with slightly less typing, slightly better error reporting, and command-line help.

rush check​

After editing a package.json file, you can run rush check to see if multiple projects are depending on different versions of the same library. In a monorepo environment, that is undesirable. Many repos will use rush check as a CI build step, so they can fail your PR build if you introduce side-by-side versions.

rush change​

If you work on libraries that get published as NPM packages, your repo probably requires you to include change log entries as part of your PR. You will know because your PR build will fail on the rush change --verify step.

To write change logs, first commit any pending work to Git. Then type rush change from anywhere under your repo working folder. This command will examine your Git history to determine which project folders have diffs. Based on that, it will prompt you to write a change log entry for each one. Each change log entry gets stored in a separate file under common/changes. You should add and commit these files to Git.

Later, Rush's automated publishing workflow will inspect these files to determine which packages need to be published. It will delete the files and copy your messages into the package's CHANGELOG.md file.

👉 See Authoring change logs for tips about writing change logs.

Common scenarios

That's it! Those are all the commonly used Rush commands.

Combining everything, a typical daily incantation might look like this:

# Pull the latest changes from Git
git pull

# Install NPM packages as needed
rush update

# Do a clean rebuild of everything
rush rebuild

# Work on one project
cd ./my-project

# Let's assume there is a "start" script in the package.json.
# (To see the available commands, type "rushx" by itself.)
rushx start
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/developer/modifying_package_json/index.html b/pages/developer/modifying_package_json/index.html index ff0c15f3..c1f04d21 100644 --- a/pages/developer/modifying_package_json/index.html +++ b/pages/developer/modifying_package_json/index.html @@ -6,7 +6,7 @@ Modifying package.json | Rush - + @@ -20,7 +20,7 @@ rush upgrade-interactive command. It will walk you through selecting projects and choosing which versions to upgrade:

rush upgrade-interactive screenshot

Choosing the project

rush upgrade-interactive screenshot

Choosing the dependencies to upgrade

pnpm outdated​

To create a report about outdated dependencies, you can also use the pnpm outdated command. Note that when invoking PNPM commands in a Rush monorepo, you must use the rush-pnpm CLI helper.

rush-pnpm outdated screenshot

Invoking rush-pnpm outdated

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/developer/new_developer/index.html b/pages/developer/new_developer/index.html index 7156f7c9..417558ea 100644 --- a/pages/developer/new_developer/index.html +++ b/pages/developer/new_developer/index.html @@ -6,13 +6,13 @@ Getting started as a developer | Rush - +
Rush StackShopBlogEvents

Getting started as a developer

Prerequisites​

In order to use Rush, you will need the NodeJS engine. We recommend the latest LTS version, because non-stable NodeJS releases frequently have bugs. You might consider installing via nvm-windows or nvm (Mac/Linux), which allows you to easily switch between different NodeJS versions that might be required for different projects that you work on.

You also need to install the Rush tool itself. It's pretty easy. From your shell or command prompt, type this:

npm install -g @microsoft/rush

NOTE: If this command fails because your user account does not have permissions to access NPM's global folder, you may need to fix your NPM configuration.

To see Rush's command line help, you can type:

rush -h

The command-line help is also published online in the Command Reference.

A couple caveats​

Before we get started, a couple important points to keep in mind:

1. Avoid certain commands in a Rush repo​

Rush optimizes by installing all of your dependency packages in a central folder, and then uses symlinks to create the "node_modules" folder for each of your projects.

Avoid using package manager commands that install/link dependencies. For example, npm run will work fine, but these commands will get confused by Rush's symlinks: npm install, npm update, npm link, npm dedupe, etc. (The same goes for other package managers: Avoid commands such as pnpm install or yarn install.) If you want to use those commands, first run rush unlink to delete the symlinks created by Rush.

If you use git clean -dfx to clean up your folder, be aware that it handles symlinks poorly. To avoid trouble, always run rush unlink before using git clean -dfx.

Afterwards you can run rush update to recreate the symlinks. (There is a standalone rush link command, but it's rarely needed.)

2. If you suspect your install is corrupted...​

Rush's package management commands are "incremental", which means they save time by skipping steps that appear to be unnecessary. Since Rush runs in automated build environments, we have many safeguards to ensure these checks are accurate. However when debugging or tinkering with packages on your local machine, sometimes your NPM "node_modules" folder can get into a bad state, causing strange errors.

If you suspect your install is corrupted, try running rush update --purge. This will force a full reinstall of your packages, and usually get you back into a good state.

© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/developer/other_commands/index.html b/pages/developer/other_commands/index.html index 619a4813..074f1ccb 100644 --- a/pages/developer/other_commands/index.html +++ b/pages/developer/other_commands/index.html @@ -6,13 +6,13 @@ Other helpful commands | Rush - +
Rush StackShopBlogEvents

Other helpful commands

Installing the latest SemVer-compatible version of everything​

Normally rush update only makes the minimal incremental changes necessary to satisfy the project package.json files. If you want to update everything to the latest version, you would do this:

# This effectively deletes the old shrinkwrap file and re-solves everything
# using the latest compatible versions as specified in package.json files.
# Note that the package.json files themselves are not modified.
rush update --full

For everyday work, --full can introduce unrelated breaks in your PR branch, for example if one of the dependencies didn't perfectly follow the SemVer rules. This isn't too much of a concern for small repos. For a large monorepo, we recommended to use rush update for everyday work, and then run rush update --full periodically as a separate workflow by a CI job or designated person.

Faster ways to build​

  • If you're only working on a few projects: Let's say your Git repo contains 50 projects, but you really only work on the widget and widget-demo projects. You can ask Rush to build only those two projects, plus the libraries that they depend on: rush rebuild --to widget --to widget-demo

  • If you changed a library: Let's say your Git repo contains 50 projects, and you just fixed some bugs in the widget library. You need to run unit tests for all the projects that use this library, and anything that depends on them, but it would be wasteful to rebuild everything else. To rebuild just the downstream projects: rush rebuild --from widget

The full set of project selection parameters are described in the article Selecting subsets of projects.

A faster way to install​

If your repo is using PNPM with the new useWorkspaces=true mode enabled in your rush.json file, you can use a feature called "filtered installs". This feature reduces installation times by only installing the subset of NPM packages required to build a specific project.

For example:

# Only install the NPM packages needed to build "my-project" and the other
# Rush projects that it depends on:
rush install --to my-project

# Like with "rush build", you can use "." to refer to the project from your
# shell's current working directory:
cd my-project
rush install --to .

# Here's how to install dependencies required to do "rush build --from my-project"
rush install --from my-project

Getting back to a clean state​

After working with Rush, maybe you want to get back to a clean state, e.g. so you can zip up a folder. Here's a couple commands to do that:

# Remove all the symlinks created by Rush:
rush unlink

# Remove all the temporary files created by Rush, including deleting all
# the NPM packages that were installed in your common folder:
rush purge
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/developer/project_tags/index.html b/pages/developer/project_tags/index.html index c1d3e8e0..4b8c6ad8 100644 --- a/pages/developer/project_tags/index.html +++ b/pages/developer/project_tags/index.html @@ -6,7 +6,7 @@ Using project tags | Rush - + @@ -17,7 +17,7 @@ accidentally misspells a tag, or if they use an old tag that is now obsolete, it may take a while to discover this mistake. You can use the "allowedProjectTags" setting to define a fixed list tags to be used in your monorepo. This also provides a centralized place to document their meanings.

rush.json

  . . .
  /**
    * This is an optional, but recommended, list of allowed tags that can be applied to Rush projects
    * using the "tags" setting in this file.  This list is useful for preventing mistakes such as misspelling,
    * and it also provides a centralized place to document your tags.  If "allowedProjectTags" list is
    * not specified, then any valid tag is allowed.  A tag name must be one or more words
    * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,
    * ".", and "@" characters.
    */
  "allowedProjectTags": [
    // Apply this tag to all Rush projects that are CLI tools
    "tools",

    // Apply this tag to all projects owned by our company's frontend team
    "frontend-team",

    // Use this to tag projects to be included in the QA test pass
    // for the upcoming product launch.
    "1.0.0-release"
  ],  . . .
© 2023 Microsoft
- + \ No newline at end of file diff --git a/pages/developer/selecting_subsets/index.html b/pages/developer/selecting_subsets/index.html index 39fb5057..17bf1199 100644 --- a/pages/developer/selecting_subsets/index.html +++ b/pages/developer/selecting_subsets/index.html @@ -6,7 +6,7 @@ Selecting subsets of projects | Rush - + @@ -55,7 +55,7 @@ will select A, B, and C
  • Note that Rush does not provide any parameter that would reduce the selection. This is an intentional design choice; in #1241 we'll implement personal tags for building up more complex selections.)

    • Here's a more complex combined command-line:

    rush build --only A --impacted-by-except B --to F

    The projects selected by this example are A, C, D, E, and F:

    rush build --only A --impacted-by-except B --to F

    See also​

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/developer/tab_completion/index.html b/pages/developer/tab_completion/index.html index 8fc3fefa..38212b14 100644 --- a/pages/developer/tab_completion/index.html +++ b/pages/developer/tab_completion/index.html @@ -6,7 +6,7 @@ Configuring tab completion | Rush - + @@ -18,7 +18,7 @@ For more information, see How to create your profile and Profiles and execution policy.

    Add the following code to your profile:

    # PowerShell parameter completion shim for the Rush CLI
    Register-ArgumentCompleter -Native -CommandName rush -ScriptBlock {
      param($commandName, $commandAst, $cursorPosition)
        [string]$value = $commandAst.ToString()
        # Handle input like `rush install; rush bui` + Tab
        [int]$position = [Math]::Min($cursorPosition, $value.Length)

        rush tab-complete --position $position --word "$value" | ForEach-Object {
          [System.Management.Automation.CompletionResult]::new($_, $_, 'ParameterValue', $_)
        }
     }

    Bash​

    To enable tab completion for Bash, add the following code to your .bashrc file:

    # bash parameter completion for the Rush CLI

    _rush_bash_complete()
    {
      local word=${COMP_WORDS[COMP_CWORD]}

      local completions
      completions="$(rush tab-complete --position "${COMP_POINT}" --word "${COMP_LINE}" 2>/dev/null)"
      if [ $? -ne 0 ]; then
        completions=""
      fi

      COMPREPLY=( $(compgen -W "$completions" -- "$word") )
    }

    complete -f -F _rush_bash_complete rush

    Fish​

    To enable tab completion for Fish shell, add the following code to the file ~/.config/fish/completions/rush.fish:

    # Fish parameter completions for the Rush CLI
    complete rush --no-files

    function __fish_rush
        set -l position (string length (commandline -cp))
        set -l word (commandline -opc)
        rush tab-complete --word "$word" --position "$position"
    end

    complete rush -x -a "(__fish_rush)"
    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/extensibility/api/index.html b/pages/extensibility/api/index.html index 3cdcff98..754ce633 100644 --- a/pages/extensibility/api/index.html +++ b/pages/extensibility/api/index.html @@ -6,13 +6,13 @@ The "rush-lib" API | Rush - +
    Rush StackShopBlogEvents

    The "rush-lib" API

    Rush provides an API for use by automation scripts. It is documented in the integrated API reference for all Rush Stack projects:

         API Reference: @microsoft/rush-lib package

    Below are some usage examples.

    Although these code samples are presented as plain JavaScript, we strongly recommend to use TypeScript and model your scripts as regular Rush projects. It is more work to set up initially, but it generally saves time and simplifies maintenance in the long run.

    Reading the rush.json configuration​

    Rather than trying to load rush.json as a JSON file, it is recommended to use the RushConfiguration class which provides a richer set of data views.

    For example, this script will show all the Rush projects and their folders:

    const rushLib = require('@microsoft/rush-lib');

    // loadFromDefaultLocation() will search parent folders to find "rush.json" and then
    // take care of parsing it and loading related config files.
    const rushConfiguration = rushLib.RushConfiguration.loadFromDefaultLocation({
      startingFolder: process.cwd()
    });

    for (const project of rushConfiguration.projects) {
      console.log(project.packageName + ':');
      console.log('  ' + project.projectRelativeFolder);
    }

    Modifying package.json files​

    If you want to modify a package.json file, the PackageJsonEditor class provides helpful validation and normalization:

    const rushLib = require('@microsoft/rush-lib');

    const rushConfiguration = rushLib.RushConfiguration.loadFromDefaultLocation({
      startingFolder: process.cwd()
    });

    // This will find "@rushstack/ts-command-line" in rush.json, without needing to specify the NPM scope
    const project = rushConfiguration.findProjectByShorthandName('ts-command-line');

    // Add lodash as an optional dependency
    project.packageJsonEditor.addOrUpdateDependency('lodash', '4.17.15', 'optionalDependencies');

    // Save the modified package.json file
    project.packageJsonEditor.saveIfModified();

    Generating a README.md summary​

    For a more realistic example, the repo-toolbox/src/ReadmeAction.ts tool uses these APIs to generate the README.md inventory for the Rush Stack monorepo.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/extensibility/creating_plugins/index.html b/pages/extensibility/creating_plugins/index.html index c3460fad..4f100b69 100644 --- a/pages/extensibility/creating_plugins/index.html +++ b/pages/extensibility/creating_plugins/index.html @@ -6,7 +6,7 @@ Creating Rush plugins (experimental) | Rush - + @@ -30,7 +30,7 @@ is that the plugin's config file should be stored in the folder common/config/rush-plugins with the same filename as the "pluginName" field from the manifest.

    Here's a complete example of this naming pattern:

    Plugin componentExample naming pattern
    NPM package name:@your-company/rush-policy-plugins
    "pluginName" in rush-plugin-manifest.json:"email-policy"
    end user config file:<repo>/common/config/rush-plugins/email-policy.json
    config file JSON schema:src/schemas/email-policy.schema.json
    code module:src/RushEmailPolicyPlugin.ts

    To enable Rush's automatic validation of your plugin's config file, specify the optionsSchema setting in your plugin manifest:

    rush-policy-plugins/rush-plugin-manifest.json

        . . .
        /**
         * (Optional) A path to a JSON schema for validating the config file that end users can
         * create to customize this plugin's behavior.  Plugin config files are stored in the folder
         * "common/config/rush-plugins/" with a filename corresponding to the "pluginName" field
         * from the manifest.  For example: "common/config/rush-plugins/business-policy.json"
         * whose schema is "business-policy.schema.json".
         */
        "optionsSchema": "lib/schemas/email-policy.schema.json",
        . . .

    See also​

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/help/faq/index.html b/pages/help/faq/index.html index 339ee7e5..58916141 100644 --- a/pages/help/faq/index.html +++ b/pages/help/faq/index.html @@ -6,7 +6,7 @@ Frequently Asked Questions (FAQ) | Rush - + @@ -22,7 +22,7 @@ .gitattributes file (and you may also need to commit a change to the affected files to work around a GitHub caching issue):

    *.json  linguist-language=JSON-with-Comments

    For a discussion of some other possibilities, see issue #1088.

    How to clean up Rush's installation to avoid interfering with other tools?​

    Generally it's recommended to perform all monorepo management using Rush. The symlinks that Rush creates under the project node_modules folders may confuse other tools such as NPM or Yarn, causing them to malfunction because they expect a different installation model. Sometimes this is unavoidable, however. For example, when migrating an existing repo to use Rush however, the CI system may need to reuse an existing working folder to build different branches that use different installation models. To prevent interference, your CI job will first need to invoke a command that deletes the old files from the previous installation model.

    For Yarn or NPM, a command like git clean -dfx is generally sufficient. (THIS DELETES FILES -- read the manual before invoking!)

    For cleaning up a Rush installation, git clean is NOT recommended because it does not handle symlinks reliably. Instead, use the rush purge command to delete the node_modules folders created by Rush.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/help/support/index.html b/pages/help/support/index.html index 64c70f44..61eaa4d9 100644 --- a/pages/help/support/index.html +++ b/pages/help/support/index.html @@ -6,7 +6,7 @@ Getting support | Rush - + @@ -17,7 +17,7 @@ chat room. We carefully review each submission before merging, which is time consuming work. The maintainers are all people who manage large corporate monorepos with regular daily distractions, so PRs frequently get overlooked. Your contributions are greatly appreciated -- we do want to get that PR reviewed!

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/intro/get_started/index.html b/pages/intro/get_started/index.html index 9f732d4c..4d6d58b0 100644 --- a/pages/intro/get_started/index.html +++ b/pages/intro/get_started/index.html @@ -6,13 +6,13 @@ Getting started | Rush - +
    Rush StackShopBlogEvents

    Getting started

    3 minute demo​

    Want to see Rush in action? The only prerequisite you need is NodeJS.

    From your shell, install Rush like this:

    npm install -g @microsoft/rush

    For command-line help, do this:

    rush -h

    To see Rush build some real projects, try running these commands:

    git clone https://github.com/microsoft/rushstack
    cd rushstack

    # Install the NPM packages:
    # (If you don't have a GitHub email configured, add the "--bypass-policy" option.)
    rush update

    # Incremental install:
    rush update  # <-- instantaneous!

    # Force all projects to be rebuilt:
    rush rebuild

    # Incremental build:
    rush build    # <-- instantaneous!

    # Use "--verbose" to view the console logs for each project as it is built.
    # Projects build in parallel processes, but their logs are collated.
    rush rebuild --verbose

    Let's get started!​

    Choose your tutorial scenario...

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/intro/welcome/index.html b/pages/intro/welcome/index.html index 27479d00..59794e6a 100644 --- a/pages/intro/welcome/index.html +++ b/pages/intro/welcome/index.html @@ -6,13 +6,13 @@ Welcome to Rush! | Rush - +
    Rush StackShopBlogEvents

    Welcome to Rush!

    Rush

    Rush makes life easier for JavaScript developers who build and publish many NPM packages at once. If you're looking to consolidate all your projects into a single repo, you came to the right place! Rush is a fast, professional solution for managing this scenario. It gives you:

    • A single NPM install: In one step, Rush installs all the dependencies for all your projects into a common folder. This is not just a "package.json" file at the root of your repo (which might set you up to accidentally require() a sibling's dependencies). Instead, Rush uses symlinks to reconstruct an accurate "node_modules" folder for each project, without any of the limitations or glitches that seem to plague other approaches.

      👉 This algorithm supports the PNPM, NPM, and Yarn package managers.

    • Automatic local linking: Inside a Rush repo, all your projects are automatically symlinked to each other. When you make a change, you can see the downstream effects without publishing anything, and without any npm link headaches. If you don't want certain projects to get linked, that's supported, too.

    • Fast builds: Rush detects your dependency graph and builds your projects in the right order. If two packages don't directly depend on each other, Rush parallelizes their build as separate NodeJS processes (and shows live console output in a readable order). In practice this multi-process approach can yield more significant speedups than all those async functions in your single-process toolchain.

    • Subset and incremental builds: If you only plan to work with a few projects from your repo, rush rebuild --to <project> does a clean build of just your upstream dependencies. After you make changes, rush rebuild --from <project> does a clean build of only the affected downstream projects. And if your toolchain is package-deps-hash enabled, rush build delivers a powerful cross-project incremental build (that also supports subset builds).

    • Cyclic dependencies: If you have hammers that build hammer-factory-factories, Rush has you covered! When a package indirectly depends on an older version of itself, projects in the cycle use the last published version, whereas other projects still get the latest bits.

    • Bulk publishing: When it's time to do a release, Rush can detect which packages have changes, automatically bump all the appropriate version numbers, and run npm publish in each folder. If you like, configure your server to automatically run rush publish every hour.

    • Changelog tracking: Whenever a PR is created, you can require developers to provide a major/minor/patch log entry for the affected projects. During publishing, these changes will be automatically aggregated into a nicely formatted CHANGELOG.md file.

    • Enterprise policies: Want to review new libraries before developers add them to package.json, but avoid hassling people about already approved cases? Want to enforce that all your projects depend on the same library version numbers? Are unprofessional personal e-mail addresses accidentally showing up in your company's Git history? Rush can help maintain a consistent ecosystem when you've got many developers and many projects in the mix.

    • Lots more! Rush was created by the platform team for Microsoft SharePoint. We build hundreds of production NPM packages every day, from internal and public Git repositories, for third party SDKs and live services with millions of users. If there's an important package management problem that needs solvin', it's likely to end up as a feature for Rush.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/intro/why_mono/index.html b/pages/intro/why_mono/index.html index e1a21f61..8903c2b1 100644 --- a/pages/intro/why_mono/index.html +++ b/pages/intro/why_mono/index.html @@ -6,13 +6,13 @@ Why one big repo⁈ | Rush - +
    Rush StackShopBlogEvents

    Why one big repo⁈

    Open source NPM packages seem to be developed in lots of small GitHub repos. Shouldn't I do that?

    Sure, if you're building isolated components, and it's not too important how they fit together. But business software doesn't seem to work that way. It's more like this:

    Most people start out by building a single web application, not a bunch of libraries. After your application ships, it keeps growing in size. Then one day you need to share some code with a different project, and you realize you've got a big rat's nest. Time to refactor!

    Clearly you must split this thing up into manageable components. NPM packages are the way to do that in JavaScript. Looking around, the convention seems to be "one GitHub repo for each NPM package." During a heroic week or two, you create 10 Git repos, split up your code, and give it a try...

    ...but working with 10 Git repos turns out to be a big pain! There are just so many headaches:

    • Tunnel vision: If a colleague mostly does their work in repos #5 and #6, they seem to completely ignore pull requests from the other 8 repos. New repos spring into existence every day without you even knowing about it.

    • Cascading publishing: Propagating a fix from lib3 down to your application project requires updating/building/publishing many Git repos in the right order: lib3 --> lib2 --> lib1 --> application. When lib3 has frequent churn, this becomes really tedious. How will people even remember the right order to publish? The internet has lots of bodies to throw at this problem, but you have limited people, and they're very busy.

    • Downstream victims: When Bob publishes a change to lib3, it can take a while before all downstream projects get upgraded to use it. If there's a regression, it might be a week before Alice tries to run "npm update" in lib1 and discovers the problem. By then, maybe Bob has left for his backpacking trip across Europe. Why should Alice shoulder the burden of fixing someone else's regression? Seems like every time she upgrades, something is broken!

    • Linking madness: The workaround is to use npm link to symlink your application directly to lib3 for testing. But NPM creates symlinks via a global folder, which causes trouble if you need to work with multiple branches of lib3 on the same laptop. And with 10+ libraries, it's hard to remember what is symlinked to what.

    The "one repo per package" model makes sense for isolated projects that are maintained by uncoordinated strangers. (Also, most of those libraries get updated fairly infrequently, which makes the problem easier.) Whereas in our example, everyone works at the same company, and the "libraries" act more like components of an integrated architecture. Code gets churned a lot, and a change in one place can easily break another part of the system. Building multiple projects together lets you run all the unit tests for every change, which moves responsibility for fixes where it belongs: To the person who originally introduced the change.

    The emergent principle becomes "one Git repo per team", or even better "as few Git repos as possible to get the job done".

    monorepo block diagram

    Lots of people who build large scale business software seem to end up with all their code in one big "monorepo". JavaScript is just the last guy to join the party.

    The big concern with this strategy is obviously build times. JavaScript tools are slower than compiled languages. If one project takes 1 minute to build, and you have 75 projects, in theory you could be looking at a ridiculous 75 minute build time. It seems intimidating, but with an industrial strength toolchain you can scale very far before build times become an issue. Most of our roadmap for Rush and Heft is focused on build times, and we're optimistic that there's still plenty of room for optimizations. With subset/incremental builds, you can in theory avoid rebuilding everything unless a change really does affect everything -- and for that kind of change, it's hard to argue that finding breaks early isn't worth the price of waiting for a longer build.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/add_to_repo/index.html b/pages/maintainer/add_to_repo/index.html index 9ebd0351..a2ed9e21 100644 --- a/pages/maintainer/add_to_repo/index.html +++ b/pages/maintainer/add_to_repo/index.html @@ -6,7 +6,7 @@ Adding projects to a repo | Rush - + @@ -25,7 +25,7 @@ If an NPM dependency is not declared in your package.json file, a runtime error may occur if your project tries to import it. These phantom dependency errors are one of the most common issues when migrating an existing project into a Rush monorepo. Generally the fix is simply to add the missing dependency to your package.json file.

    The rush scan command is a quick way to detect these problems.

    Step 7: Adding more projects​

    You can add more projects by following the same operations from Step 4. In our example, we would add my-controls next (because it depends on my-toolchain), and then my-application last (because it depends on everything). We proactively added a couple more category folders ("libraries" and "apps") since we expect more of these types of things in our scenario. The filled out "projects" section looks like this:

      "projects": [
        {
          "packageName": "my-app",
          "projectFolder": "apps/my-app"
        },

        {
          "packageName": "my-controls",
          "projectFolder": "libraries/my-controls",
          "reviewCategory": "production"
        },

        {
          "packageName": "my-toolchain",
          "projectFolder": "tools/my-toolchain",
          "reviewCategory": "tools"
        }
      ]

    Once you have all your projects added and building without errors, you may consider enabling other optional features. The config files contain lots of snippets that you can uncomment to get started. The rush-example repo uses some of these snippets.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/autoinstallers/index.html b/pages/maintainer/autoinstallers/index.html index 354d523d..84d4104d 100644 --- a/pages/maintainer/autoinstallers/index.html +++ b/pages/maintainer/autoinstallers/index.html @@ -6,7 +6,7 @@ Autoinstallers | Rush - + @@ -43,7 +43,7 @@ You should redo this step whenever you modify the package.json file.

    # Create or update common/autoinstallers/my-autoinstaller/pnpm-lock.yaml
    # This file should be committed and tracked by Git.
    rush update-autoinstaller --name my-autoinstaller

  • Commit the updated files to git

    git add common/autoinstallers/my-autoinstaller/

    git commit -m "Updated autoinstaller"

    • To associate an autoinstaller with a custom command, specify its name in the autoinstallerName field in command-line.json.

    To associate an autoinstaller with a Rush plugin, see the Creating Rush plugins documentation.

    Maintaining an autoinstaller​

    • To modify an autoinstaller, edit its package.json file.

      # This will also upgrade any indirect dependencies.
      rush update-autoinstaller --name my-autoinstaller

      # Commit the updated pnpm-lock.yaml
      git commit -m "Updated autoinstaller"

    • To delete the autoinstaller, simply delete its folder:

      # BE CAREFUL WHEN RECURSIVELY DELETING FOLDERS
      rm -Rf common/autoinstallers/my-autoinstaller

      # Commit the changes to Git
      git add common/autoinstallers

      git commit -m "Deleted autoinstaller"

    See also​

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/build_cache/index.html b/pages/maintainer/build_cache/index.html index 42000fc8..b16cf840 100644 --- a/pages/maintainer/build_cache/index.html +++ b/pages/maintainer/build_cache/index.html @@ -6,7 +6,7 @@ Enabling the build cache | Rush - + @@ -24,8 +24,7 @@ to cloud storage, and individual users are granted read-only access. For example, each time a PR is merged into the main branch, the CI system builds that baseline and uploads it to cloud storage. Even for a user who is doing git clone for the first time, their rush build will be very fast.

    Enabling the local disk cache​

    The build cache feature is enabled using the build-cache.json -config file. You can copy the template from the website or use rush init to create this file.

    To enable the basic local disk cache, add these two settings:

    common/config/rush/build-cache.json

    {
      . . .
      /**
       * (Required) EXPERIMENTAL - Set this to true to enable the build cache feature.
       *
       * See https://rushjs.io/pages/maintainer/build_cache/ for details about this experimental feature.
       */
      "buildCacheEnabled": true,

      /**
       * (Required) Choose where project build outputs will be cached.
       *
       * Possible values: "local-only", "azure-blob-storage", "amazon-s3"
       */
      "cacheProvider": "local-only",

      . . .
    }

    Upgrade note: Early releases of this feature were enabled using the "buildCache": true setting -in experiments.json. This has been superseded by "buildCacheEnabled" in build-cache.json.

    Configuring project output folders​

    With only this change, if you run rush rebuild --verbose, you will see this warning:

    Project does not have a rush-project.json configuration file, or one provided by a rig,
    so it does not support caching.

    The build cache needs to know which folders should be stored in the tar archive. Those details vary between +config file. You can copy the template from the website or use rush init to create this file.

    To enable the basic local disk cache, add these two settings:

    common/config/rush/build-cache.json

    {
      . . .
      /**
       * (Required) Set this to true to enable the build cache feature.
       *
       * See https://rushjs.io/pages/maintainer/build_cache/ for details about this feature.
       */
      "buildCacheEnabled": true,

      /**
       * (Required) Choose where project build outputs will be cached.
       *
       * Possible values: "local-only", "azure-blob-storage", "amazon-s3"
       */
      "cacheProvider": "local-only",

      . . .
    }

    Configuring project output folders​

    With only this change, if you run rush rebuild --verbose, you will see this warning:

    Project does not have a rush-project.json configuration file, or one provided by a rig,
    so it does not support caching.

    The build cache needs to know which folders should be stored in the tar archive. Those details vary between toolchains, and are thus configured separately for each project using the rush-project.json config file.

    For example:

    <your-project>/config/rush-project.json

    {
      . . .

      /**
       * Specify the folders where your toolchain writes its output files.  If enabled, the Rush build cache will
       * restore these folders from the cache.
       *
       * The strings are folder names under the project root folder.  These folders should not be tracked by Git.
       * They must not contain symlinks.
       */
      "projectOutputFolderNames": ["lib", "dist"]
      . . .
    }

    Configuring project inputs​

    By default, the following inputs are incorporated into Rush's cache key. In other words, if any of these things changes, then the project must be rebuilt:

    • the hash of the source files that are under the project's folder, ignoring any files excluded by .gitignore

    • the hashes of source files under other workspace projects that are dependencies of the project
      @@ -40,7 +39,7 @@ It monitors file writes during the build to identify inputs that are not part of your cache key.

      Testing the build cache​

      Now you should see projects being cached as shown in this sample log output:

      rush build --verbose
      . . .

      ==[ example-project ]==============================================[ 1 of 5 ]==

      This project was not found in the build cache.

      Invoking: heft test --clean

      . . .

      Caching build output folders: lib

      Successfully set cache entry.

      "example-project" completed successfully in 11.27 seconds.

      When we run the same command a second time, Rush extracts the archive instead of invoking the build task:

      rush build --verbose
      . . .

      ==[ example-project ]==============================================[ 1 of 5 ]==

      Build cache hit.

      Clearing cached folders: lib, dist

      Successfully restored output from the build cache.

      example-project was restored from the build cache.

      Note that rush rebuild will not read from cache, only rush build does. To disable writing from cache during rush rebuild, set the RUSH_BUILD_CACHE_WRITE_ALLOWED environment variable to 0.

      By default, the cached tar archives are stored under your common/temp/build-cache folder (and thus will be cleaned by rush purge). It is safe to delete these files.

      Enabling cloud storage​

      Currently the cacheProvider setting provides three choices:

      • "local-only": no cloud storage; archives are only kept on a local disk folder
      • "azure-blob-storage": Microsoft Azure blob storage container
      • "amazon-s3": Amazon S3 bucket

      (The above providers are modeled as Rush plugins. -Custom build cache storage providers can be implemented in the same way.)

      As one example, here's how to configure an Azure blob container:

      common/config/rush/build-cache.json

      {
        . . .
        /**
         * (Required) EXPERIMENTAL - Set this to true to enable the build cache feature.
         *
         * See https://rushjs.io/pages/maintainer/build_cache/ for details about this experimental feature.
         */
        "buildCacheEnabled": true,

        /**
         * (Required) Choose where project build outputs will be cached.
         *
         * Possible values: "local-only", "azure-blob-storage", "amazon-s3"
         */
        "cacheProvider": "azure-blob-storage",

        /**
         * Use this configuration with "cacheProvider"="azure-blob-storage"
         */
        "azureBlobStorageConfiguration": {
          /**
           * (Required) The name of the the Azure storage account to use for build cache.
           */
          "storageAccountName": "example",

          /**
           * The name of the container in the Azure storage account to use for build cache.
           */
          "storageContainerName": "my-container"

          /**
           * If set to true, allow writing to the cache. Defaults to false.
           */
          "isCacheWriteAllowed": false

        . . .

      Note that we have set "isCacheWriteAllowed": false to prevent regular users from writing to the container. +Custom build cache storage providers can be implemented in the same way.)

      As one example, here's how to configure an Azure blob container:

      common/config/rush/build-cache.json

      {
        . . .
        /**
         * (Required) Set this to true to enable the build cache feature.
         *
         * See https://rushjs.io/pages/maintainer/build_cache/ for details about this feature.
         */
        "buildCacheEnabled": true,

        /**
         * (Required) Choose where project build outputs will be cached.
         *
         * Possible values: "local-only", "azure-blob-storage", "amazon-s3"
         */
        "cacheProvider": "azure-blob-storage",

        /**
         * Use this configuration with "cacheProvider"="azure-blob-storage"
         */
        "azureBlobStorageConfiguration": {
          /**
           * (Required) The name of the the Azure storage account to use for build cache.
           */
          "storageAccountName": "example",

          /**
           * The name of the container in the Azure storage account to use for build cache.
           */
          "storageContainerName": "my-container"

          /**
           * If set to true, allow writing to the cache. Defaults to false.
           */
          "isCacheWriteAllowed": false

        . . .

      Note that we have set "isCacheWriteAllowed": false to prevent regular users from writing to the container. (Later, we will use an environment variable to override this for our CI job.)

      User authentication​

      If security is not a priority for your repo, you can simplify user setup by configuring your storage container to allow unauthenticated anonymous access. The container is accessed via an HTTPS URL containing randomized hashes which are difficult to guess without access to your Git repo. This provides rudimentary @@ -57,7 +56,7 @@ page for your storage account.

      AWS​

      For Amazon S3, RUSH_BUILD_CACHE_CREDENTIAL will be your AWS Access Key ID and AWS Secret Access Key separated by a colon, such as: <AccessKeyID>:<SecretAccessKey>. You can also pass temporary session tokens required when assuming an IAM role: <AccessKeyID>:<SecretAccessKey>:<SessionToken>.

      If RUSH_BUILD_CACHE_CREDENTIAL is not set, the build cache will attempt to read the environment vars AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN that are commonly set via the AWS CLI or other CI tooling. However, RUSH_BUILD_CACHE_CREDENTIAL will always take precedence if it exists.

      The build cache feature is still under development. Feedback is welcome!

      Some relevant GitHub issues to follow:

      © 2023 Microsoft
      - + \ No newline at end of file diff --git a/pages/maintainer/cobuilds/index.html b/pages/maintainer/cobuilds/index.html index e86af0c5..3664d2be 100644 --- a/pages/maintainer/cobuilds/index.html +++ b/pages/maintainer/cobuilds/index.html @@ -6,7 +6,7 @@ Cobuilds (experimental) | Rush - + @@ -106,7 +106,7 @@ of the operation's execution result and the corresponding cache_id. Before attempting to acquire a lock, a machine will first query this completion result information. If there is a completion result available, the result is reused based on the parsed information.

      • See also​

      © 2023 Microsoft
      - + \ No newline at end of file diff --git a/pages/maintainer/custom_commands/index.html b/pages/maintainer/custom_commands/index.html index 96470e2a..d3d50bfe 100644 --- a/pages/maintainer/custom_commands/index.html +++ b/pages/maintainer/custom_commands/index.html @@ -6,7 +6,7 @@ Custom commands | Rush - + @@ -16,7 +16,7 @@ a script defined in each project's package.json file, or a single script file specified by the (optional) shellCommand field.

    • global command: These commands run once for the entire repo, by executing a single script file specified by the (required) shellCommand field.

    You can also define your own command-line "parameters". A parameter can be associated with one or more commands via its associatedCommands list. You can even associate your custom parameters with Rush's own built-in build and rebuild commands. In the above example, we associate the --ship parameter with rush build, rush rebuild, and our custom rush import-strings.

    Currently three kinds of parameterKind are supported:

    • flag parameter: A "flag" is a simple switch, for example --production.
    • string parameter: A parameter that includes a text string argument, for example --title "Hello, world!".
    • string list parameter: A string parameter that can be specified multiple times, for example --category docs --category dashboard
    • choice parameter: Similar to a string but the argument must come from a list of supported alternatives, for example --locale fr-fr.
    • integer parameter: A parameter that includes an integer argument, for example --pull-request 1234.
    • integer list parameter: An integer parameter that can be specified multiple times, for example --pr 1234 --pr 1235 --pr 1236

    More parameter kinds may be supported in the future. (They are parsed using the ts-command-line library which supports other parameter kinds that could be exposed.)

    Using custom commands and options​

    Your custom definitions and their descriptions will be incorporated into Rush's command-line help (when invoked under your repo working folder). Continuing the above example, if we run rush import-strings --help we'll now see something like this:

    Rush Multi-Project Build Tool 5.1.0 - https://rushjs.io

    usage: rush import-strings [-h] [-p COUNT] [-t PROJECT1]
                               [--to-version-policy VERSION_POLICY_NAME]
                               [-f PROJECT2] [-v] [-s]
                               [--locale {en-us,fr-fr,es-es,zh-cn}]

    Requests translated strings from the translation service and imports them
    into each project.

    Optional arguments:
      -h, --help            Show this help message and exit.
      -p COUNT, --parallelism COUNT
                            Specify the number of concurrent build processes The
                            value "max" can be specified to indicate the number
                            of CPU cores. If this parameter omitted, the default
                            value depends on the operating system and number of
                            CPU cores.
      -t PROJECT1, --to PROJECT1
                            Run command in the specified project and all of its
                            dependencies
      --to-version-policy VERSION_POLICY_NAME
                            Run command in all projects with the specified
                            version policy and all of their dependencies
      -f PROJECT2, --from PROJECT2
                            Run command in all projects that directly or
                            indirectly depend on the specified project
      -v, --verbose         Display the logs during the build, rather than just
                            displaying the build status summary
      -s, --ship            Perform a production build, including minification
                            and localization steps
      --locale {en-us,fr-fr,es-es,zh-cn}
                            Selects a single instead of the default locale
                            (en-us) for non-ship builds or all locales for ship
                            builds.

    How to implement a custom command/parameter? For global commands, Rush simply invokes their shellCommand and passes the parameters along. For bulk commands, Rush can alternatively look for a corresponding script name in your package.json file. Suppose we have something like this:

    example/package.json

    {
      "name": "example",
      "version": "1.0.0",
      "main": "lib/index.js",
      "typings": "lib/index.d.ts",
      "scripts": {
        "import-strings": "./node_modules/.bin/loc-importer",
        "build": "./node_modules/.bin/heft build"
      }
    }

    If we run rush import-strings --locale fr-fr, then Rush will read the "import-strings" script body and execute it like this:

    ./node_modules/.bin/loc-importer --locale fr-fr

    (Rush directly executes it using your shell; it does not rely on npm run.) Since this choice parameter has a default value, if we run rush import-strings, then loc-importer is executed like this:

    ./node_modules/.bin/loc-importer --locale en-us

    In other words, Rush's custom parameters are simply appended to the package.json script body. This means you may run into trouble if your script body uses shell expressions such as "rimraf ./lib && rimraf ./temp" which don't support these parameters, or need them to be inserted in the middle of the string. This is by design: We don't recommend writing nontrivial build scripts inside a JSON string. Instead, it's better to move this operation into a proper script file that can be commented and reviewed. As your monorepo grows, you'll probably also want to move that script into a reusable library that can be shared across projects.

    See also​

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/custom_tips/index.html b/pages/maintainer/custom_tips/index.html index 04607bba..c3d03093 100644 --- a/pages/maintainer/custom_tips/index.html +++ b/pages/maintainer/custom_tips/index.html @@ -6,7 +6,7 @@ Custom tips (experimental) | Rush - + @@ -22,7 +22,7 @@ rush-lib/src/api/CustomTipsConfiguration.ts, so feel free to create a pull request proposing new tips.

    Custom tip identifiers​

    TIP_PNPM_INVALID_NODE_VERSION​

    Corresponds to PNPM's ERR_PNPM_INVALID_NODE_VERSION.

    TIP_PNPM_MISMATCHED_RELEASE_CHANNEL​

    Corresponds to PNPM's ERR_PNPM_MISMATCHED_RELEASE_CHANNEL.

    TIP_PNPM_NO_MATCHING_VERSION​

    Corresponds to PNPM's ERR_PNPM_NO_MATCHING_VERSION.

    TIP_PNPM_NO_MATCHING_VERSION_INSIDE_WORKSPACE​

    Corresponds to PNPM's ERR_PNPM_NO_MATCHING_VERSION_INSIDE_WORKSPACE.

    TIP_PNPM_OUTDATED_LOCKFILE​

    Corresponds to PNPM's ERR_PNPM_OUTDATED_LOCKFILE.

    TIP_PNPM_PEER_DEP_ISSUES​

    Corresponds to PNPM's ERR_PNPM_PEER_DEP_ISSUES.

    TIP_PNPM_TARBALL_INTEGRITY​

    Corresponds to PNPM's ERR_PNPM_TARBALL_INTEGRITY

    TIP_PNPM_UNEXPECTED_STORE​

    Corresponds to PNPM's ERR_PNPM_UNEXPECTED_STORE.

    TIP_RUSH_INCONSISTENT_VERSIONS​

    This message is printed by rush install or rush update when projects have inconsistent dependency versions, only if ensureConsistentVersions is enabled in rush.json.

    Example Rush output:

    Found 5 mis-matching dependencies!

    See also​

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/deploying/index.html b/pages/maintainer/deploying/index.html index c516aeee..06c8dd21 100644 --- a/pages/maintainer/deploying/index.html +++ b/pages/maintainer/deploying/index.html @@ -6,7 +6,7 @@ Deploying projects | Rush - + @@ -44,7 +44,7 @@ We will create two config files:

    • common/config/rush/deploy.json - the default scenario file, which we'll use for app1
    • common/config/rush/deploy-app2-example.json -- the app2-example scenario, which we will use for app2

    Both of these files can be created using rush init-deploy:

    # Create common/config/rush/deploy.json
    rush init-deploy --project app1

    # Create common/config/rush/deploy-app2-example.json
    rush init-deploy --project app2 --scenario app2-example

    After editing deploy-app2-example.json to specify "linkCreation": "script", we can now use the --scenario parameter with rush deploy:

    # Copy app1 and its dependencies to /mnt/deploy/app1
    # Uses scenario file: common/config/rush/deploy.json
    rush deploy --target-folder /mnt/deploy/app1

    # Copy app2 and its dependencies to /mnt/deploy/app2
    # Uses scenario file: common/config/rush/deploy-app2-example.json
    rush deploy --target-folder /mnt/deploy/app2 --scenario app2-example

    Note that the --project parameter is not needed with rush deploy because each config file has only one project in its "deploymentProjectNames" array.

    See also​

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/enabling_ci_builds/index.html b/pages/maintainer/enabling_ci_builds/index.html index 4773d3d5..b56bcae7 100644 --- a/pages/maintainer/enabling_ci_builds/index.html +++ b/pages/maintainer/enabling_ci_builds/index.html @@ -6,7 +6,7 @@ Enabling CI builds | Rush - + @@ -36,7 +36,7 @@ to invoke the Rush tool:

    .github/workflows/ci.yml

    name: CI
    on:
      push:
        branches: ['main']
      pull_request:
        branches: ['main']
    jobs:
      build:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v3
            with:
              fetch-depth: 2
          - name: Git config user
            uses: snow-actions/git-config-user@v1.0.0
            with:
              name: # Service Account's Name
              email: # Service Account's Email Address
          - uses: actions/setup-node@v3
            with:
              node-version: 16
          - name: Verify Change Logs
            run: node common/scripts/install-run-rush.js change --verify
          - name: Rush Install
            run: node common/scripts/install-run-rush.js install
          - name: Rush rebuild
            run: node common/scripts/install-run-rush.js rebuild --verbose --production

    For an example of an equivalent setup using an Azure DevOps build pipeline, take a look at the build.yaml file, in the monorepo where Rush is developed.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/enabling_prettier/index.html b/pages/maintainer/enabling_prettier/index.html index 5bba9cd4..2cfdfdfb 100644 --- a/pages/maintainer/enabling_prettier/index.html +++ b/pages/maintainer/enabling_prettier/index.html @@ -6,7 +6,7 @@ Enabling Prettier | Rush - + @@ -47,7 +47,7 @@ To do this, create a file called pre-commit in the common/git-hooks folder:

    common/git-hooks/pre-commit

    #!/bin/sh
    # Called by "git commit" with no arguments.  The hook should
    # exit with non-zero status after issuing an appropriate message if
    # it wants to stop the commit.

    # Invoke the "rush prettier" custom command to reformat files whenever they
    # are committed. The command is defined in common/config/rush/command-line.json
    # and uses the "rush-prettier" autoinstaller.
    node common/scripts/install-run-rush.js prettier || exit $?

  • Make the file executable: chmod +x pre-commit

  • To actually install the hook, run rush install.

  • Before finally merging your PR, you may want to run prettier . --write one last time to reformat any files that may have been modified before we installed the hook.

    • You're done! Whenever changes are committed to Git, they will now be automatically prettified.

    Installing prettier plugins​

    Prettier supports plugins, which can add new languages or formatting rules. If you choose to add prettier plugins to your setup, special care must be taken to ensure that all of the tooling that might call prettier will be able to load your prettier configuration:

    • rush prettier as configured in the steps above
    • Editors (VSCode, Webstorm, Sublime, etc.) that are configured to format on save
    • Jest and heft test, which use prettier to format snapshots

    Here's an example, using the prettier-plugin-packagejson plugin:

    1. First, add the plugin package to your autoinstaller package.json file -- if configured as above, this will be common/autoinstallers/rush-prettier/package.json.

      {
        "dependencies": {
          "prettier-plugin-packagejson": "^2.2.18"
        }
      }

    2. Update your autoinstaller's lockfile:

      rush update-autoinstaller --name rush-prettier

    3. Add the full path of your plugin folder to the plugins array in .prettierrc.js:

      module.exports = {
        // ... your other configuration goes here ...
        // ,

        plugins: ['./common/autoinstallers/rush-prettier/node_modules/prettier-plugin-packagejson']
      };

    4. Commit your autoinstaller and prettierrc changes.

    Note that after pulling this change, local developers will need to run rush prettier at least once to install the updated autoinstaller -- otherwise, their format-on-save functions and jest snapshot formatting may stop working. In practice this will fix itself after they perform at least one git commit and run the git hooks, but it may be worth notifying your team any time you do update prettier plugins this way.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/git_hooks/index.html b/pages/maintainer/git_hooks/index.html index 0294eb89..6b3be891 100644 --- a/pages/maintainer/git_hooks/index.html +++ b/pages/maintainer/git_hooks/index.html @@ -6,7 +6,7 @@ Installing Git hooks | Rush - + @@ -31,7 +31,7 @@ in your .git/hooks/ folder.

    Invoking Prettier during "git commit"​

    The Prettier tool ensures that source files follow consistent conventions for syntax issues like spacing and commas. By configuring a git commit hook to invoke Prettier automatically, you can apply these fixes without any effort on the developer's part.

    The Enabling Prettier article provides step-by-step instructions.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/npm_registry_auth/index.html b/pages/maintainer/npm_registry_auth/index.html index 7bc2b2b4..ab94aef6 100644 --- a/pages/maintainer/npm_registry_auth/index.html +++ b/pages/maintainer/npm_registry_auth/index.html @@ -6,7 +6,7 @@ NPM registry authentication | Rush - + @@ -33,7 +33,7 @@ artifactory.json config file. The file template contains documentation for other optional settings that can be used to customize the dialogue.

    See also​

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/package_managers/index.html b/pages/maintainer/package_managers/index.html index bc8f2ea5..0b6d5b85 100644 --- a/pages/maintainer/package_managers/index.html +++ b/pages/maintainer/package_managers/index.html @@ -6,13 +6,13 @@ NPM vs PNPM vs Yarn | Rush - +
    Rush StackShopBlogEvents

    NPM vs PNPM vs Yarn

    Before you can start installing a JavaScript library, you need to choose which package manager you will use. (Our community loves flexibility and choices, so of course there's not just one!) Rush supports the three most popular package managers. In chronological order:

    • NPM: the tool that pioneered the packaging standard and registry protocol used by most JavaScript package managers today. The tool's developers also maintain the npmjs.com registry, which is currently the most popular place to distribute open source JavaScript libraries.

    • Yarn: a complete rewrite of the NPM tool that preserves the same installation model, but promises faster installations, better reliability, and some cool new features (e.g. Yarn workspaces) that facilitate large scale development.

    • PNPM: A fundamentally new installation model that solves the "phantom dependency" and "NPM doppelganger"" problems, while cleverly making use of symlinks to remain 100% compatible with the NodeJS module resolution standard.

    Which one should I use with Rush?​

    The answer depends on your needs. The Rush developers don't endorse a particular package manager, but here are some observations based on our experience from managing our own monorepos:

    Considerations for NPM​

    • NPM is the most compatible choice, and the most forgiving for dealing with "bad" packages.

    • If you choose NPM, you may need to use an older release. NPM 5.x and 6.x are both known to have unresolved regressions that cause trouble in Rush repos. NPM 4.5.0 is the most recent version that's known to work very reliably, but unfortunately it's pretty old. (We'd greatly appreciate community help improving this situation. We're using GitHub issue #886 to track this effort.)

      Before reporting a Rush bug involving the NPM package manager, first try downgrading to "npmVersion": "4.5.0". If that eliminates the repro, then your issue is likely an NPM regression and may not be fixable in the Rush code base. We still accept these issues, but we track them differently.

    Considerations for PNPM​

    • PNPM is the only option that solves the NPM doppelgangers problem. In a complex monorepo, doppelgangers sometimes cause a lot of trouble, so PNPM has an important advantage in this regard.

    • Although PNPM's symlinking strategy correctly follows the modern NodeJS module resolution standard, many legacy packages do not, which causes compatibility problems. Teams who migrate existing projects from Yarn/NPM to PNPM often encounter "bad packages" that need workarounds or fixes. The incompatibilities generally reflect real problems with those packages: (1) forgetting to list dependencies in the package.json file, or (2) implementing homebrew module resolution without handling symlinks according to the standard. Most "bad" packages have straightforward fixes, but it may seem daunting for a small team. (The PNPM Discord chat room is a great resource for help, though.)

    • PNPM is newer and less widely used than NPM or Yarn, but it's a solid piece of software. Microsoft uses PNPM in Rush repos with hundreds of projects and hundreds of PRs per day, and we've found it to be very fast and reliable.

    • PNPM is currently the only option that supports the --strict-peer-dependencies protection (see "strictPeerDependencies" in rush.json).

    Considerations for Yarn​

    • Rush's support for Yarn is relatively new and unproven, so we're eager to hear about issues and get them fixed.

    • Yarn installs faster than NPM (although somewhat slower than PNPM).

    • Yarn's "workspaces" are not used in a Rush repo, since they rely on an installation model that doesn't protect against phantom dependencies. Rush's linking strategy is mostly equivalent to workspaces, however.

    Specifying your package manager​

    To change your package manager, edit the rush.json file and uncomment one of the three fields (npmVersion, pnpmVersion, or yarnVersion):

    rush.json

    /**
      * The next field selects which package manager should be installed and determines its version.
      * Rush installs its own local copy of the package manager to ensure that your build process
      * is fully isolated from whatever tools are present in the local environment.
      *
      * Specify one of: "pnpmVersion", "npmVersion", or "yarnVersion".  See the Rush documentation
      * for details about these alternatives.
      */
    "pnpmVersion": "2.15.1",

    // "npmVersion": "4.5.0",
    // "yarnVersion": "1.9.4",

    After changing the setting, delete your old shrinkwrap file and other package manager specific files from the common/config/rush folder. (Otherwise Rush will complain about unsupported config files.) Then run rush update --full --purge. That's it!

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/phased_builds/index.html b/pages/maintainer/phased_builds/index.html index 433e7285..1667898a 100644 --- a/pages/maintainer/phased_builds/index.html +++ b/pages/maintainer/phased_builds/index.html @@ -6,7 +6,7 @@ Enabling phased builds | Rush - + @@ -15,7 +15,7 @@ script is a single operation.

    Phased builds are a way to increase parallelism, by defining individual operations as phases that can be executed on a project. As an example, if project B depends on project A, we could first build project A, and then begin building project B while running the unit tests for project A in parallel.

    NOTE: Phased builds are built on top of, and require, the build cache feature -- if you haven't already enabled the build cache for your monorepo, see Enabling build cache.

    Enable the experiment​

    In common/config/rush/experiments.json, enable the "phasedCommands" experiment.

    {
      "phasedCommands": true
    }

    Define phases​

    In common/config/rush/command-line.json, add a section "phases", as follows:

    {
      "phases": [
        {
          /**
           * The name of the phase. Note that this value must start with the \"_phase:\" prefix.
           */
          "name": "_phase:build",

          /**
           * The dependencies of this phase.
           */
          "dependencies": {
            "upstream": ["_phase:build"]
          },

          /**
           * Normally Rush requires that each project's package.json has a \"scripts\" entry matching the phase name. To disable this check, set \"ignoreMissingScript\" to true.
           */
          "ignoreMissingScript": true,

          /**
           * By default, Rush returns a nonzero exit code if errors or warnings occur during a command. If this option is set to \"true\", Rush will return a zero exit code if warnings occur during the execution of this phase.
           */
          "allowWarningsOnSuccess": false
        },
        {
          "name": "_phase:test",
          "dependencies": {
            "self": ["_phase:build"]
          },
          "ignoreMissingScript": true,
          "allowWarningsOnSuccess": false
        }
      ]
    }

    In this example, we define two phases -- _phase:build and _phase:test. The _phase:build operation depends on the _phase:build operation of its upstream projects (using the traditional Rush dependency graph). The _phase:test operation does not depend on any upstream projects, but requires the _phase:build operation of its own project to be completed first. Note that phase names must start with _phase:.

    Individual projects can choose not to implement a phase (if ignoreMissingScript is enabled), but they cannot define their own phases, or change the dependencies of phases. This ensures that phases will behave consistently within your monorepo, regardless of what subset of projects you are building.

    Redefine the build and test commands​

    In common/config/rush/command-line.json, in the "commands" section, redefine the "build" command to be a phased command instead of a bulk command, and specify what phases you would like it to run. In the example below we also define a "test" command.

    {
      "commands": [
        {
          "commandKind": "phased",
          "name": "build",
          "phases": ["_phase:build"],
          "enableParallelism": true,
          "incremental": true
        },

        // No need to define "rebuild", by default, it is the same as build
        // but with incremental=false.

        {
          "commandKind": "phased",
          "name": "test",
          "summary": "Build and test all projects.",
          "phases": ["_phase:build", "_phase:test"],
          "enableParallelism": true,
          "incremental": true
        },

        {
          "commandKind": "phased",
          "name": "retest",
          "summary": "Build and test all projects.",
          "phases": ["_phase:build", "_phase:test"],
          "enableParallelism": true,
          "incremental": false
        }
      ]
    }

    This command definition shows off another useful feature of phased builds: we can create our "phase" building blocks and then build commands out of them. Instead of rush build running builds and tests for all projects, we can define rush build to mean "build everything without tests", and rush test to mean "build everything and run tests".

    Assign parameters to phases​

    If you have defined any custom parameters for your build command in command-line.json, you'll now need to associate them to phases, so Rush knows which phases can accept your parameter.

    Here are some examples:

    {
      "parameters": [
        {
          "longName": "--production",
          "parameterKind": "flag",
          "description": "Perform a production build, including minification and localization steps",
          "associatedCommands": ["build", "rebuild", "test", "retest"],
          "associatedPhases": ["_phase:build"]
        },
        {
          "longName": "--update-snapshots",
          "parameterKind": "flag",
          "description": "Update unit test snapshots for all projects",
          "associatedCommands": ["test", "retest"],
          "associatedPhases": ["_phase:test"]
        }
      ]
    }

    Here, we've defined one flag (--production) that can be specified on all 4 variations of our build command, but it will only be passed to the build phase. And, we've defined anothe flag (--update-snapshots) that can be specified only on the test and retest commands, and is only passed to the test phase.

    So, if we were to execute this command:

    rush test --production --update-snapshots

    Rush will pass the --production parameter to the _phase:build script for each project, and then pass the --update-snapshots parameter to the _phase:test script for each project.

    Add the phase scripts to your projects​

    Within the package.json file for every project in your monorepo, add the new _phase: scripts:

    {
      "scripts": {
        "_phase:build": "heft build --clean",
        "_phase:test": "heft test --no-build",
        "build": "heft build --clean",
        "test": "heft test --clean"
      }
    }

    The example above attempts to align developer expectations for the build and test commands:

    • Moving into the project folder and running rushx build cleans and builds the project, without testing.
    • Moving into the project folder and running rushx test cleans, builds, and tests the project.
    • Running rush build --only <project> cleans and builds the project, without testing.
    • Running rush test --only <project> cleans, builds, and tests the project.

    Where possible, for any custom phases you define, keep this pattern in mind -- what's important isn't that phases are implemented identically to rushx commands, but rather that rush <something> and rushx <something> produce similar results, if applicable.

    Some projects may not have any meaningful work to do for a phase, in which case you can define it as an empty operation (""), or leave it off entirely, if ignoreMissingScript was specified in the phase definition.

    Define per-phase output folder names​

    Within the rush-project.json configuration file of each project (or, preferably, each rig profile), redefine your operationSettings so that each folder is specified in only one phase. For example:

    {
      "operationSettings": [
        // Old configuration (before phases)
        {
          "operationName": "build",
          "outputFolderNames": ["lib", "lib-commonjs", "dist", "temp"]
        },
        // New configuration (after phases)
        {
          "operationName": "_phase:build",
          "outputFolderNames": ["lib", "lib-commonjs", "dist"]
        },
        {
          "operationName": "_phase:test",
          "outputFolderNames": ["temp/coverage", "temp/jest-reports"]
        }
      ]
    }

    Note how there's no overlap between the output folders specified by _phase:build and _phase:test -- this is an important new requirement for phased builds. In general, it's not possible for Rush to reliably cache the output of an operation if that output can be modified by a different operation, so you should structure your operations such that if _phase:build produces a "lib" folder, no other operation will put output in that folder.

    The phased builds feature is still under development. Feedback is welcome!

    Some relevant GitHub issues to follow:

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/publishing/index.html b/pages/maintainer/publishing/index.html index 0ed242e4..bd7d370d 100644 --- a/pages/maintainer/publishing/index.html +++ b/pages/maintainer/publishing/index.html @@ -6,13 +6,13 @@ Publishing packages | Rush - +
    Rush StackShopBlogEvents

    How to use Rush in your build flow to automate publishing of updated packages

    There are two stages in a Rush publishing flow. The first stage is during development. Developers are asked to provide change files to track changes that deserve a space in change log. The second stage is at publishing time. Rush can be used to gather all change files to increase version, update change log, and publish new packages to a npm registry.

    1. Track Changes​

    Only changes to public packages need to be tracked. People can control which package should get published and which package should not get published in rush.json by specifying field shouldPublish. Once public packages have been defined, repo admins can enforce developers to provide change files if they have modified any public packages. Developers can use a tool to generate change files after answering a few questions.

    How to enforce developers to provide change files​

    rush change --verify

    This command fails if a developer modifies a public package without providing related change files. It is recommended to add this command as a step of CI builds so that build fails when change files are missing.

    How a developer generates change files​

    rush change

    Running rush change will prompt a developer with a few questions and generate appropriate change files after questions have been answered. A change file contains what type of version increase this change needs and a description of the change. The change file should be committed with related changes into the repo.

    2. Publish packages​

    rush publish

    When it is time to publish updated packages, rush publish is the command that increases package version and publish updated packages. It does quite a few things internally to make it happen: gather all change files to figure out what kind of version increase is needed, what packages need to have version increase, increase the versions of dependencies, clean up change files, and so on.

    This command should have its own build definition. So people can just trigger it to run when it is time to publish packages.

    rush publish is configurable to serve difference purposes. For example, it supports a dry run mode so that the changes can be verified and tested before real publishing. More usage cases are listed here:

    Dry run mode​

    rush publish has several flavors of dry runs that allow you to execute intermediate steps of the publish process without actually publishing to an npm registry. This can be useful for testing as well as for creating version bumps and changelogs in situations where this is no external package repository in use for publishing.

    rush publish

    When run without any parameters, this does the whole process in a read-only mode, which means the changes are not saved to disk, not committed to the source repository, and packages are not really published. It is useful if you want to check if the version increases and change log updates look right for you.

    rush publish --apply

    In this mode the changes are added to the changelog files and the package.json files are updated with new version numbers and written to disk, but nothing is actually committed to the source repository or published. This is useful if you want to review or edit any of these files before committing to the source repository or publishing to the package repository.

    rush publish --apply --target-branch targetBranch

    In this mode, the changes above are actually committed to a new git branch (prefixed with publish-) that is based off of targetBranch. Running this command with targetBranch set to the branch specified in repository.defaultBranch will effectively do everything that a "live" publish would do (including commits to git source), short of actually publishing to an npm repository.

    Publish mode​

    There are extra parameters for configuring the publishing process: which registry to publish to, what token to use, and whether to include commit details.

    rush publish --apply --target-branch targetBranch --publish

    This command increases versions, commit changes to targetBranch, and publish packages to a registry based on environmental npm registry value.

    rush publish --apply --target-branch targetBranch --publish --registry registryUrl --npm-auth-token npmToken

    In addition to what previous command can do, this command allows packages to be published to the specified registry with a specified npm token.

    rush publish --apply --target-branch targetBranch --publish --registry registryUrl --npm-auth-token npmToken --add-commit-details

    In addition to what previous command can do, This command will include commit details in the change logs.

    Pack mode​

    Instead of publishing, you also have the option to pack the outputs locally into .tgz files.

    rush publish --pack --include-all --publish

    Note: Any command that uses the --publish flag will disable dry mode, which allows writing the file contents to the disk.

    You can also use this command in combination with --release-folder to hint where the files should be outputted.

    3. Version Policy​

    Version policy is a new concept introduced into Rush to solve the problem of how to notify packages to do different types of version increase when the number of packages is large. For example, @microsoft/rush and @microsoft/rush-lib are always published together and use the same version. Those two versions should always be increased together. Another example is that developers can create different branches to service different major versions. People should not be able to modify the major version in that branch. Version policy solves this kind of problems by defining different policies, one enforcing that rush and rush-lib always have the same version and the other locking the major version in a branch.

    What is a version policy?​

    A version policy is set of rules that define how the version should be increased. It is defined in common/config/rush/version-policies.json. An example can be found in here. A public package specifies what version policy it is associated with by providing versionPolicyName in rush.json. An example can be found in Rush and Rush-lib configuration. Multiple packages can use one version policy if they all follow the same rules. When a package is associated with a version policy, it becomes public and can be published when rush publish runs.

    The schema of version-policies.json is defined here.

    Two types of version policies​

    There are currently two types of version policies supported: lockstep version policy and individual version policy. Projects using one lockstep version policy all have the same version. Projects using an individual version policy get version increased according to their change files and the restrictions of the policy. For example, if an individual version policy has a locked major version, all packages using this policy will have their major version locked.

    [
      {
        "policyName": "myPublic",
        "definitionName": "lockStepVersion",
        "version": "1.0.0-dev.6",
        "nextBump": "prerelease"
      },
      {
        "policyName": "myInternal",
        "definitionName": "individualVersion",
        "lockedMajor": 3
      }
    ]

    Publishing process when version policies are used​

    You need two steps to publish your packages when version policies are used. The first step is to increase the package versions. And the second step is to publish the packages. The reason to break up publishing into two steps is that it is very often that you need to test the packages after version increase and before package publishing.

    Command to increase version​

    rush version --bump

    Running rush version --bump will increase package versions based on their associated version policies.

    Command to publish packages​

    rush publish --include-all

    Running rush publish --include-all will publish all the public packages that have version increased.

    4. Summary​

    In summary, you can use Rush to automate the whole publishing flow for your repo.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/recommended_settings/index.html b/pages/maintainer/recommended_settings/index.html index 144fdb8a..5600a065 100644 --- a/pages/maintainer/recommended_settings/index.html +++ b/pages/maintainer/recommended_settings/index.html @@ -6,7 +6,7 @@ Recommended settings | Rush - + @@ -34,7 +34,7 @@ peer dependencies, which is an invalid state that can cause build failures or incompatible dependency versions. (For historical reasons, JavaScript package managers generally do not treat this invalid state as an error.)

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/setup_new_repo/index.html b/pages/maintainer/setup_new_repo/index.html index c954a802..0efdfbe0 100644 --- a/pages/maintainer/setup_new_repo/index.html +++ b/pages/maintainer/setup_new_repo/index.html @@ -6,13 +6,13 @@ Setting up a new repo | Rush - +
    Rush StackShopBlogEvents

    Setting up a new repo

    This tutorial walks through the process of consolidating several projects into a new Rush monorepo. (If you'd like to see a fully worked out sample based on these steps, take a look at the rush-example repo on GitHub.)

    For this example, suppose we have 3 project folders, like this:

    • my-app: a web application
    • my-controls: a control library used by the application
    • my-toolchain: a NodeJS build tool used to compile the other projects

    Initially each of these projects is in its own folder. They are built using a cumbersome procedure like this:

    ~$ cd my-toolchain
    ~/my-toolchain$ npm run build
    ~/my-toolchain$ npm link
    ~/my-toolchain$ cd ../my-controls
    ~/my-controls$ npm link my-toolchain
    ~/my-controls$ npm run build
    ~/my-controls$ npm link
    ~/my-controls$ cd ../my-app
    ~/my-app$ npm link my-toolchain
    ~/my-app$ npm link my-controls
    ~/my-app$ npm run build

    Let's Rushify these projects!

    Step 1: Check your Rush version​

    Before we get started, make sure you have the latest Rush release installed globally:

    ~$ npm install -g @microsoft/rush

    NOTE: If this command fails because your user account does not have permissions to access NPM's global folder, you may need to fix your NPM configuration.

    Step 2: Use "rush init" to initialize your repo​

    Let's assume you already created an empty GitHub repo that we will copy these projects into. Clone your repo somewhere and then run rush init to generate Rush's config files:

    ~$ git clone https://github.com/my-team/my-repo
    ~$ cd my-repo
    ~/my-repo$ rush init

    It will generate these files (see Config file reference for more info):

    FileWhat it does
    rush.jsonThe main configuration file for Rush
    .gitattributes(Delete this file if you're not using Git.)
    Tells Git not to perform merging operations for shrinkwrap files, because it is unsafe.
    .gitignore(Delete this file if you're not using Git.)
    Tells Git not to track temporary files created by Rush.
    .github/workflows/ci.yml(Delete this file if you're not using GitHub Actions.)
    Configures the GitHub Actions service to perform PR builds using Rush.
    common/config/rush/.npmrcRush uses this file to configure the package registry, regardless of whether the package manager is PNPM, NPM, or Yarn.
    common/config/rush/.npmrc-publishRush uses this file instead of .npmrc when publishing NPM packages.
    common/config/rush/.pnpmfile.cjs(Delete this file if you've chosen to use NPM or Yarn instead of PNPM.)
    Used to workaround problems with dependencies that have mistakes in their package.json file.
    common/config/rush/artifactory.json(Delete this file if you're not using Artifactory.)
    Used to define a custom rush setup experience for configuring Artifactory credentials.
    common/config/rush/build-cache.jsonUsed to configure Rush's cloud build cache.
    common/config/rush/command-line.jsonYou can use this to define custom commands/parameters that will become part of the Rush command-line.
    common/config/rush/common-versions.jsonUsed to specify NPM dependency version selections that affect all projects in a Rush repo.
    common/config/rush/experiments.jsonUsed to enable experimental features of Rush.
    common/config/rush/pnpm-config.jsonUsed to configure how the PNPM package manager behaves during rush install and rush update.
    common/config/rush/rush-plugins.jsonUsed to enable plugins for Rush.
    common/config/rush/version-policies.jsonUsed to define advanced publishing configurations.
    git-hooks/commit-msg.sampleA template for defining Git hooks that will be activated by rush install.

    NOTE: If any of these files already exists in your branch, rush init will issue a warning and will NOT overwrite the existing files.

    Next, add the generated files to Git and commit them to your branch:

    ~/my-repo$ git add .
    ~/my-repo$ git commit -m "Initialize Rush repo"

    Step 3: Customize your configuration​

    The template files have lots of documentation and commented example snippets. We suggest you look over them to familiarize yourself with the basic options and features.

    You can change your options at any time, but there are a few settings in rush.json that you should think about in advance:

    • Choose a package manager: The template defaults to using PNPM, but you can also use NPM or Yarn. See NPM vs PNPM vs Yarn for guidance.

    • Check your Rush version: Make sure your rushVersion setting is the latest version, which is shown in the NPM registry.

    • Check other version fields: Also check that you're using recent stable releases for any other applicable fields such as pnpmVersion, npmVersion, yarnVersion, nodeSupportedVersionRange

    • Decide whether to use the "category folders" model: See the comments in rush.json regarding projectFolderMinDepth and projectFolderMaxDepth, and make a plan for how project folders will be organized in the monorepo

    • Configure your registry access: The initial .npmrc file is configured to use the public NPM registry. If you will be using a private registry, you should update the common/config/rush/.npmrc file.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/setup_policies/index.html b/pages/maintainer/setup_policies/index.html index fe31427b..9f1b0a84 100644 --- a/pages/maintainer/setup_policies/index.html +++ b/pages/maintainer/setup_policies/index.html @@ -6,7 +6,7 @@ Enabling policies | Rush - + @@ -14,7 +14,7 @@
    Rush StackShopBlogEvents

    Enabling policies

    The rush-schema.json JSON schema defines some additional settings you can specify in rush.json.

    projectFolderMinDepth: Controlling folder size​

    Rush repositories can grow very big. When you have lots of projects (and maybe several repositories), it's very useful to impose a standard structure that makes it immediately obvious which folders contain buildable projects. We suggest a convention like this:

    • In the repo, top-level folders are "category folders" (e.g. "~/demo/libraries")
    • Project folders are always nested under a category folder (e.g. "~/demo/libraries/lib1")
    • A project folder must always be at the second level (e.g. we forbid nesting such as "~/demo/libraries/lib1/lib2")
    • Cross-project files are always stored in the common folder (e.g. "~/demo/common/docs", "~demo/common/scripts", etc.)
    • There are no exceptions to these rules

    If we want to adopt this policy for our demo repo, we can move the projects into category folders like this:

    ~/demo/apps/application
    ~/demo/libraries/lib1
    ~/demo/libraries/lib2

    ...and then enforce that projects must be a the second level using these settings in ~/demo/rush.json:

      // The minimum folder depth for the projectFolder field.
      // (The default value is 1, i.e. no slashes in the path name.)
      "projectFolderMinDepth": 2,
      // The maximum folder depth for the projectFolder field.
      // (The default value is 2, i.e. a single slash in the path name.)
      "projectFolderMaxDepth": 2,

    allowedEmailRegExps: Avoiding private e-mail addresses​

    Git requires every commit to be accompanied by a name and e-mail address. However, there is no validation of these fields, and their defaults are pulled from a global setting on your PC that's easy to forget about. When using Git for work, people often accidentally commit using an unintended e-mail address that looks... not so professional. If the repo is hosted on GitHub, these e-mail addresses immediately become queryable via the GitHub REST API, easy pickings for unscrupulous spammers. (The privacy settings for your GitHub account don't affect "git commit".)

    Rush can help, though. The "gitPolicy" setting in rush.json allows you to specify a list of acceptable e-mail patterns for a repository. The patterns are regular expressions. (Since they are inside a JSON string literal, note that backslashes must be double-escaped.)

      "gitPolicy": {
        // A list of regular expressions describing allowable e-mail patterns
        // for Git commits.  They are case-insensitive anchored JavaScript RegExps.
        // Example: ".*@example\\.com"
        "allowedEmailRegExps": [
          // Require GitHub scrubbed e-mails
          "[^@]+@users\\.noreply\\.github\\.com"
        ],

        // An example valid e-mail address for "Mr. Example" that conforms to one
        // of the allowedEmailRegExps.  Example: "mr-example@contoso.com"
        "sampleEmail": "mrexample@users.noreply.github.com"
      },

    Whenever the developer runs rush install, Rush will check that their e-mail address follows one of the patterns. If not, it displays a warning like this:

    rush install
    Rush Multi-Package Build Tool

    Checking Git policy for this repository.

    Hey there!  To keep things tidy, this repo asks you to submit your Git commmits
    using an e-mail like this pattern:

        [^@]+@users\.noreply\.github\.com

    ...but yours is configured like this:

        Bob <bobbles@somewhere.sketchy.int>

    To fix it, you can use commands like this:

        git config --local user.name "Mr. Example"
        git config --local user.email "mrexample@users.noreply.github.com"

    Aborting, so you can go fix your settings.  (Or use --bypass-policy to skip.)

    approvedPackagesPolicy: Reviewing new NPM dependencies​

    Are there certain people on your team who constantly find exciting new libraries and add them to your package.json? This can quickly get out of hand, especially in environments that require legal or security reviews for external code. The approvedPackagesPolicy feature allows you to detect when new NPM dependencies are introduced.

    Since different levels of scrutiny are often required (e.g. for a shipping product, versus an intern project, versus an internal library), we distinguish "review categories". This allows us to approve a package once for an entire category of projects, while still being alerted when the dependency is used somewhere else.

    Continuing the example scenario from Setting up a new repo, here's how we would update rush.json to define some review categories for "published" versus "internal" projects:

    {
      "rushVersion": "4.0.0",
      "npmVersion": "5.5.1",
      "nodeSupportedVersionRange": ">=8.9.0 <9.0.0",

      "approvedPackagesPolicy": {
        "reviewCategories": [ "published", "internal" ],
        // We don't need to review @types packages, because we can assume
        // the untyped package should already have been approved
        "ignoredNpmScopes": [ "@types" ]
      },

      "projects": [
        {
          "packageName": "application",
          "projectFolder": "application",
          "reviewCategory": "internal"
        },
        {
          "packageName": "lib1",
          "projectFolder": "lib1",
          "reviewCategory": "internal"
        },
        {
          "packageName": "lib2",
          "projectFolder": "lib2",
          "reviewCategory": "published"
        }
      ]
    }

    When you run rush install, it will create two files that report your dependencies. These files should be added to Git and can be configured so that changes require approval:

    • ~/demo/common/config/rush/browser-approved-packages.json: Packages approved for usage in a web browser. This is generally the stricter of the two types, so by default all new packages are added to this file. For web browser dependencies, the review discussion typically focuses on: How big is the minified code? What's the license? Are there security issues?
    • ~/demo/common/config/rush/nonbrowser-approved-packages.json: Packages approved for usage everywhere except in a web browser. This review discussion typically focuses on: How much clutter will it pull into our node_modules folder? Do we already have an equivalent package? Is there any real code in there, or is it a just a flimsy wrapper for another package?

    After running rush install, the browser-approved-packages.json file might look like this:

    {
      "packages": [
        {
          "name": "@rushstack/heft",
          "allowedCategories": [ "internal" ]
        },
        {
          "name": "@rushstack/node-library-build",
          "allowedCategories": [ "internal", "published" ]
        },
        {
          "name": "semver",
          "allowedCategories": [ "internal", "published" ]
        }
      ]
    }

    For example, this file is showing that the external dependency @rushstack/heft was found in the package.json file for an "internal" project (let's say ~/demo/lib1) but not any "public" project (such as ~/demo/application).

    Rush has no way to detect whether an NPM package is for the browser or not. Since these are all non-browser files, you must manually move them to the other file browser-approved-packages.json.

    How approvals work​

    Whenever rush install is run, the content in these files will be broadened to match the current contents of package.json. This file should be committed to Git. When the developer creates a pull request, the PR diff can be used e.g. to trigger a special approval.

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/maintainer/using_rush_plugins/index.html b/pages/maintainer/using_rush_plugins/index.html index 9a2f6ec5..3b4950ed 100644 --- a/pages/maintainer/using_rush_plugins/index.html +++ b/pages/maintainer/using_rush_plugins/index.html @@ -6,7 +6,7 @@ Using Rush plugins (experimental) | Rush - + @@ -24,7 +24,7 @@ packages are currently built-in to Rush and enabled automatically. For now, you should NOT register them in rush-plugins.json.

    This is a temporary accommodation while the plugin framework is still experimental. In the next major release of Rush, the build cache packages will need to be configured in standard way.

    Third-party plugins​

    Here's a gallery of some community contributed plugins.

    NPM PackageDescription
    rush-archive-project-pluginArchive Rush projects that are no longer maintained
    rush-github-action-build-cache-pluginSave and restore the build cache in Github actions
    rush-init-project-pluginInitialize new Rush projects
    rush-lint-staged-pluginIntegrate lint-staged with a Rush monorepo
    rush-print-log-if-error-pluginPrint a project's entire log file when an error occurs
    rush-sort-package-jsonSort the package.json file entries for Rush projects
    rush-upgrade-self-pluginA helper for upgrading to the latest release of Rush

    If you created an interesting plugin for Rush, let us know in a GitHub issue. Thanks!

    See also​

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/pages/news/index.html b/pages/news/index.html index cd0f6f6a..2fbfe4df 100644 --- a/pages/news/index.html +++ b/pages/news/index.html @@ -6,7 +6,7 @@ What's new | Rush - + @@ -15,7 +15,7 @@ CHANGELOG.md.

    Rush is maintained by the Rush Stack developer community. For roadmaps and updates from the team, please visit the Rush Stack News page.

    The Rush Hour monthly video call is the easiest way to find out what's happening with Rush Stack:

    • Sign up using the Events page.
    • If you missed an event, the Past Events archive often includes a green Meeting Notes button with a summary of important points.

    Announcements​

    Follow us on Mastodon (@rushstack@fosstodon.org) or Twitter (@rushstack).

    Mastodon feed for @rushstack@fosstodon.org
    . . .
    •   •   •
    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/search/index.html b/search/index.html index 2070a862..aa5cbfb7 100644 --- a/search/index.html +++ b/search/index.html @@ -6,13 +6,13 @@ Search the documentation | Rush - +
    Rush StackShopBlogEvents

    Search the documentation

    © 2023 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/404.html b/zh-cn/404.html index dee98b2f..28a2b1c2 100644 --- a/zh-cn/404.html +++ b/zh-cn/404.html @@ -6,13 +6,13 @@ 未找到页面 | Rush - +
    Rush StackShopBlogEvents

    未找到页面

    我们没有找到您正在寻找的页面。

    请联系本站点的拥有者并附上原始链接以便让他们知道他们的链接失效了。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/assets/js/a5cc47f5.27cb9e29.js b/zh-cn/assets/js/a5cc47f5.0c6954d0.js similarity index 99% rename from zh-cn/assets/js/a5cc47f5.27cb9e29.js rename to zh-cn/assets/js/a5cc47f5.0c6954d0.js index 1642a948..7212ef3a 100644 --- a/zh-cn/assets/js/a5cc47f5.27cb9e29.js +++ b/zh-cn/assets/js/a5cc47f5.0c6954d0.js @@ -1 +1 @@ -"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[8010],{158:(e,t,r)=>{r.d(t,{Zo:()=>c,kt:()=>k});var n=r(6393);function a(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function o(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,n)}return r}function p(e){for(var t=1;t=0||(a[r]=e[r]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(a[r]=e[r])}return a}var s=n.createContext({}),l=function(e){var t=n.useContext(s),r=t;return e&&(r="function"==typeof e?e(t):p(p({},t),e)),r},c=function(e){var t=l(e.components);return n.createElement(s.Provider,{value:t},e.children)},u="mdxType",m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},h=n.forwardRef((function(e,t){var r=e.components,a=e.mdxType,o=e.originalType,s=e.parentName,c=i(e,["components","mdxType","originalType","parentName"]),u=l(r),h=a,k=u["".concat(s,".").concat(h)]||u[h]||m[h]||o;return r?n.createElement(k,p(p({ref:t},c),{},{components:r})):n.createElement(k,p({ref:t},c))}));function k(e,t){var r=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=r.length,p=new Array(o);p[0]=h;var i={};for(var s in t)hasOwnProperty.call(t,s)&&(i[s]=t[s]);i.originalType=e,i[u]="string"==typeof e?e:a,p[1]=i;for(var l=2;l{r.r(t),r.d(t,{assets:()=>c,contentTitle:()=>s,default:()=>k,frontMatter:()=>i,metadata:()=>l,toc:()=>u});var n=r(9122),a=r(2501),o=(r(6393),r(158)),p=["components"],i={title:"\u6b22\u8fce\u4f7f\u7528 Rush"},s=void 0,l={unversionedId:"pages/intro/welcome",id:"pages/intro/welcome",title:"\u6b22\u8fce\u4f7f\u7528 Rush",description:"Rush \u53ef\u4ee5\u8ba9 JavaScript \u5f00\u53d1\u8005\u66f4\u8f7b\u677e\u5730\u540c\u65f6\u6784\u5efa\u3001\u53d1\u5e03\u591a\u4e2a NPM \u5305\u3002\u5982\u679c\u4f60\u6b63\u5728\u5c06\u4f60\u7684\u6240\u6709\u9879\u76ee\u6574\u5408\u5230\u4e00\u4e2a\u4ed3\u5e93\u5185\uff0c\u90a3\u4e48\u4f60\u6765\u5bf9\u5730\u65b9\u4e86\uff01Rush \u662f\u4e00\u4e2a\u5feb\u901f\u3001\u4e13\u4e1a\u7684\u89e3\u51b3\u65b9\u6848\uff0c\u5b83\u53ef\u4ee5\u5e2e\u52a9\u4f60\uff1a",source:"@site/i18n/zh-cn/docusaurus-plugin-content-docs/current/pages/intro/welcome.md",sourceDirName:"pages/intro",slug:"/pages/intro/welcome",permalink:"/zh-cn/pages/intro/welcome",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/intro/welcome.md",tags:[],version:"current",frontMatter:{title:"\u6b22\u8fce\u4f7f\u7528 Rush"},sidebar:"docsSidebar",next:{title:"\u4e3a\u4ec0\u4e48\u4f7f\u7528\u4e00\u4e2a\u5927\u4ed3\u5e93\uff1f\uff01",permalink:"/zh-cn/pages/intro/why_mono"}},c={},u=[],m={toc:u},h="wrapper";function k(e){var t=e.components,r=(0,a.Z)(e,p);return(0,o.kt)(h,(0,n.Z)({},m,r,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("img",{src:"/images/rush.svg",alt:"Rush",title:"Rush",style:{width:"12rem",paddingBottom:"1rem"}}),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"Rush")," \u53ef\u4ee5\u8ba9 JavaScript \u5f00\u53d1\u8005\u66f4\u8f7b\u677e\u5730\u540c\u65f6\u6784\u5efa\u3001\u53d1\u5e03\u591a\u4e2a NPM \u5305\u3002\u5982\u679c\u4f60\u6b63\u5728\u5c06\u4f60\u7684\u6240\u6709\u9879\u76ee\u6574\u5408\u5230\u4e00\u4e2a\u4ed3\u5e93\u5185\uff0c\u90a3\u4e48\u4f60\u6765\u5bf9\u5730\u65b9\u4e86\uff01Rush \u662f\u4e00\u4e2a\u5feb\u901f\u3001\u4e13\u4e1a\u7684\u89e3\u51b3\u65b9\u6848\uff0c\u5b83\u53ef\u4ee5\u5e2e\u52a9\u4f60\uff1a"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("strong",{parentName:"li"},"\u4ec5\u9700\u4e00\u6b21 NPM \u5b89\u88c5:"),' \u4ec5\u9700\u4e00\u6b65\uff0cRush \u4fbf\u53ef\u4ee5\u5c06\u4f60\u9879\u76ee\u7684\u6240\u6709\u4f9d\u8d56\u5b89\u88c5\u5230\u4e00\u4e2a\u516c\u5171\u6587\u4ef6\u5939\u4e0b\uff0c\u8be5\u6587\u4ef6\u5939\u5e76\u4e0d\u50cf "package.json" \u4e00\u6837\u4f4d\u4e8e\u9879\u76ee\u7684\u6839\u76ee\u5f55\uff08\u653e\u5230\u6839\u76ee\u5f55\u7684\u8bbe\u8ba1\u53ef\u80fd\u5b58\u5728\u5e7b\u5f71\u4f9d\u8d56\u7684\u95ee\u9898\uff09\uff0c\u76f8\u53cd\uff0cRush \u4f7f\u7528\u7b26\u53f7\u94fe\u63a5\u6765\u4e3a\u6bcf\u4e2a\u9879\u76ee\u91cd\u65b0\u6784\u5efa\u4e00\u4e2a\u51c6\u786e\u7684 "node_modules" \u6587\u4ef6\u3002')),(0,o.kt)("p",null,"\u23f5 ",(0,o.kt)("strong",{parentName:"p"},"\u8be5\u7b97\u6cd5\u652f\u6301 ",(0,o.kt)("a",{parentName:"strong",href:"/zh-cn/pages/maintainer/package_managers"},"PNPM, NPM, and Yarn")," \u7b49\u5305\u7ba1\u7406\u5de5\u5177.")),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("strong",{parentName:"li"},"\u672c\u5730\u81ea\u52a8\u94fe\u63a5\uff1a")," \u5728 Rush \u4ed3\u5e93\u5185\u7684\u6240\u6709\u9879\u76ee\u4e4b\u95f4\u88ab\u81ea\u52a8\u94fe\u63a5\uff0c\u5f53\u4ee3\u7801\u53d1\u751f\u53d8\u52a8\u65f6\uff0c\u4f60\u53ef\u4ee5\u5728\u4e0d\u53d1\u5e03\u7684\u60c5\u51b5\u4e0b\u770b\u5230\u4e0b\u6e38\u6240\u6709\u7684\u53d8\u52a8\uff0c\u540c\u65f6\uff0c\u4e5f\u4e0d\u4f1a\u56f0\u6270\u4e8e ",(0,o.kt)("inlineCode",{parentName:"li"},"npm link")," \u5982\u4f55\u4f7f\u7528\uff1b\u5982\u679c\u4f60\u4e0d\u60f3\u8ba9\u67d0\u4e00\u4e2a\u4ed3\u5e93\u88ab\u94fe\u63a5\uff0c\u90a3\u4e5f\u5f88\u5bb9\u6613\u505a\u5230\u3002")),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"\u5feb\u901f\u6784\u5efa\uff1a")," Rush \u4f1a\u68c0\u6d4b\u4f9d\u8d56\u56fe\uff0c\u5e76\u6309\u7167\u6b63\u786e\u7684\u987a\u5e8f\u6784\u5efa\u4f60\u7684\u9879\u76ee\u3002\u5982\u679c\u4e24\u4e2a\u5e93\u6ca1\u6709\u88ab\u4e92\u76f8\u4f9d\u8d56\uff0cRush \u4f1a\u4f7f\u7528\u72ec\u7acb\u7684 NodeJS \u8fdb\u7a0b\u6765\u5e76\u884c\u6784\u5efa\uff08\u540c\u65f6\u8fd9\u4e9b\u5e76\u884c\u7684\u8fdb\u7a0b\u4f1a\u4ee5 ",(0,o.kt)("a",{parentName:"p",href:"https://www.npmjs.com/package/@rushstack/stream-collator"},"\u53ef\u8bfb\u7684\u987a\u5e8f")," \u4e0b\u663e\u793a\u63a7\u5236\u53f0\u8f93\u51fa\uff09\u3002\u5728\u5b9e\u8df5\u4e2d\uff0c\u8fd9\u79cd\u591a\u8fdb\u7a0b\u65b9\u5f0f\u53ef\u4ee5\u6bd4\u6240\u6709\u5f02\u6b65\u51fd\u6570\u8fd0\u884c\u5728\u5728\u5355\u7ebf\u7a0b\u7684 Gulpfile \u4e2d\u63d0\u4f9b\u663e\u8457\u7684\u901f\u5ea6\u63d0\u5347\u3002"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u5b50\u96c6\u6784\u5efa\u548c\u589e\u91cf\u6784\u5efa\uff1a")," \u5982\u679c\u4f60\u4ec5\u4ec5\u60f3\u6784\u5efa\u4e00\u90e8\u5206\u9879\u76ee\uff0c\u53ef\u4ee5\u4f7f\u7528 ",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild --to ")," \u6765\u5b9e\u73b0\u4e00\u4e2a\u4ec5\u5305\u542b\u4e0a\u6e38\u4f9d\u8d56\u7684\u6e05\u7406\u5f0f\u6784\u5efa\uff0c\u5b83\u4f1a\u91cd\u65b0\u6784\u5efa\u8be5 project \u53ca\u5176\u4f9d\u8d56\u7684\u9879\u76ee\uff1b",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild --from ")," \u53ef\u4ee5\u5b9e\u73b0\u4e00\u4e2a\u4ec5\u5305\u542b\u4e0b\u6e38\u4f9d\u8d56\u7684\u6e05\u7406\u5f0f\u6784\u5efa\uff0c\u5b83\u4f1a\u91cd\u65b0\u6784\u5efa\u8be5 project \u4ee5\u53ca\u6240\u6709\u4f9d\u8d56\u8be5 project \u7684\u9879\u76ee\u3002\u5982\u679c\u4f60\u7684\u5de5\u5177\u94fe\u542f\u7528\u4e86 ",(0,o.kt)("a",{parentName:"p",href:"https://www.npmjs.com/package/@rushstack/package-deps-hash"},"package-deps-hash"),", ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," \u4f1a\u751f\u6210\u4e00\u4e2a\u5f3a\u6709\u529b\u7684\u8de8\u9879\u76ee\u589e\u91cf\u6784\u5efa\uff08\u4e5f\u652f\u6301\u5b50\u96c6\u6784\u5efa\uff09\u3002")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u5faa\u73af\u4f9d\u8d56\uff1a")," \u5f53\u4e00\u4e2a\u5e93\u95f4\u63a5\u4f9d\u8d56\u81ea\u5df1\u7684\u65e7\u7248\u672c\u65f6\uff0c\u5904\u4e8e\u5faa\u73af\u4e2d\u7684\u9879\u76ee\u4f1a\u4f7f\u7528\u6700\u540e\u4e00\u4e2a\u53d1\u5e03\u7684\u7248\u672c\uff0c\u800c\u5176\u4ed6\u9879\u76ee\u4ecd\u7136\u4f1a\u83b7\u5f97\u6700\u65b0\u7684\u7248\u672c\u3002")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u6279\u91cf\u53d1\u5e03\uff1a")," \u53d1\u5e03\u65f6\uff0cRush \u53ef\u4ee5\u68c0\u6d4b\u54ea\u4e9b\u5305\u53d1\u751f\u4e86\u53d8\u52a8\uff0c\u540c\u65f6\u4f1a\u81ea\u52a8\u7684\u63d0\u9ad8\u76f8\u5e94\u7684\u7248\u672c\u53f7\uff0c\u5e76\u5728\u6bcf\u4e2a\u6587\u4ef6\u5939\u90a3\u6267\u884c ",(0,o.kt)("inlineCode",{parentName:"p"},"npm publish"),", \u5982\u679c\u4f60\u559c\u6b22\uff0c\u4f60\u53ef\u4ee5\u914d\u7f6e\u4f60\u7684\u670d\u52a1\u5668\uff0c\u8ba9\u5b83\u6bcf\u5c0f\u65f6\u81ea\u52a8\u6267\u884c ",(0,o.kt)("inlineCode",{parentName:"p"},"rush publish"),"\u3002")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u8ddf\u8e2a\u66f4\u65b0\u65e5\u5fd7\uff1a")," \u6bcf\u5f53\u521b\u5efa\u4e00\u4e2a PR, \u4f60\u53ef\u4ee5\u8981\u6c42\u5f00\u53d1\u8005\u4e3a\u53d7\u5230\u5f71\u54cd\u7684\u9879\u76ee\u63d0\u4f9b\u4e00\u4e2a major/minor/path \u7684\u66f4\u65b0\u6761\u76ee\u3002\u53d1\u5e03\u65f6\uff0c\u8fd9\u4e9b\u65e5\u5fd7\u4f1a\u88ab\u4ee5\u4f18\u96c5\u7684\u683c\u5f0f\u6574\u5408\u5230 ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/microsoft/rushstack/blob/main/libraries/node-core-library/CHANGELOG.md"},"CHANGELOG.md")," \u6587\u4ef6\u4e2d.")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u4f01\u4e1a\u7ea7\u653f\u7b56"),"\uff1a\u60f3\u8981\u5728\u67d0\u4e2a\u4f9d\u8d56\u88ab\u52a0\u8fdb package.json \u524d\u5bf9\u8be5\u4f9d\u8d56\u8fdb\u884c\u5ba1\u6838\uff0c\u4f46\u662f\u53c8\u62c5\u5fc3\u91cd\u590d\u7684\u95ee\u9898\uff1f\u60f3\u8981\u8ba9\u4f60\u7684\u9879\u76ee\u5185\u7684\u6240\u6709\u4f9d\u8d56\u90fd\u6709\u76f8\u540c\u7248\u672c\uff1f\u662f\u5426\u6709\u4e0d\u4e13\u4e1a\u7684\u79c1\u4eba\u90ae\u7bb1\u6df7\u5165\u5230\u4e86\u4f60\u516c\u53f8\u7684 Git \u5386\u53f2\u4e2d\uff1fRush \u53ef\u4ee5\u8ba9\u591a\u4eba\u5f00\u53d1\u548c\u591a\u9879\u76ee\u6df7\u5408\u65f6\u4fdd\u6301\u4e00\u81f4\u7684\u751f\u6001\u3002"))),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"\u8fd8\u6709\u66f4\u591a\uff01")," Rush \u7531 ",(0,o.kt)("a",{parentName:"p",href:"http://aka.ms/spfx"},"Microsoft SharePoint")," \u56e2\u961f\u521b\u5efa\u3002\u6211\u4eec\u6bcf\u5929\u6784\u5efa\u6570\u767e\u4e2a\u9002\u7528\u4e8e\u751f\u4ea7\u73af\u5883\u7684 NPM \u5305\uff0c\u4ece\u5185\u90e8\u5230\u5f00\u6e90\u7684 Git \u4ed3\u5e93\uff0c\u670d\u52a1\u7b2c\u4e09\u65b9 SDK \u548c\u5b9e\u65f6\u670d\u52a1\u7684\u767e\u4e07\u7528\u6237\u3002\u5982\u679c\u5728\u5305\u7ba1\u7406\u4e0a\u5b58\u5728\u9700\u8981\u89e3\u51b3\u7684\u91cd\u8981\u95ee\u9898\uff0c\u90a3\u4e48\u5f88\u6709\u53ef\u80fd\u88ab Rush \u7684\u67d0\u4e2a\u529f\u80fd\u7279\u4e60\u60ef\u89e3\u51b3\u3002"))}k.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkrushjs_io=self.webpackChunkrushjs_io||[]).push([[8010],{158:(e,t,r)=>{r.d(t,{Zo:()=>c,kt:()=>k});var n=r(6393);function a(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function o(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,n)}return r}function p(e){for(var t=1;t=0||(a[r]=e[r]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(a[r]=e[r])}return a}var s=n.createContext({}),l=function(e){var t=n.useContext(s),r=t;return e&&(r="function"==typeof e?e(t):p(p({},t),e)),r},c=function(e){var t=l(e.components);return n.createElement(s.Provider,{value:t},e.children)},u="mdxType",m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},h=n.forwardRef((function(e,t){var r=e.components,a=e.mdxType,o=e.originalType,s=e.parentName,c=i(e,["components","mdxType","originalType","parentName"]),u=l(r),h=a,k=u["".concat(s,".").concat(h)]||u[h]||m[h]||o;return r?n.createElement(k,p(p({ref:t},c),{},{components:r})):n.createElement(k,p({ref:t},c))}));function k(e,t){var r=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=r.length,p=new Array(o);p[0]=h;var i={};for(var s in t)hasOwnProperty.call(t,s)&&(i[s]=t[s]);i.originalType=e,i[u]="string"==typeof e?e:a,p[1]=i;for(var l=2;l{r.r(t),r.d(t,{assets:()=>c,contentTitle:()=>s,default:()=>k,frontMatter:()=>i,metadata:()=>l,toc:()=>u});var n=r(9122),a=r(2501),o=(r(6393),r(158)),p=["components"],i={title:"\u6b22\u8fce\u4f7f\u7528 Rush"},s=void 0,l={unversionedId:"pages/intro/welcome",id:"pages/intro/welcome",title:"\u6b22\u8fce\u4f7f\u7528 Rush",description:"Rush \u53ef\u4ee5\u8ba9 JavaScript \u5f00\u53d1\u8005\u66f4\u8f7b\u677e\u5730\u540c\u65f6\u6784\u5efa\u3001\u53d1\u5e03\u591a\u4e2a NPM \u5305\u3002\u5982\u679c\u4f60\u6b63\u5728\u5c06\u4f60\u7684\u6240\u6709\u9879\u76ee\u6574\u5408\u5230\u4e00\u4e2a\u4ed3\u5e93\u5185\uff0c\u90a3\u4e48\u4f60\u6765\u5bf9\u5730\u65b9\u4e86\uff01Rush \u662f\u4e00\u4e2a\u5feb\u901f\u3001\u4e13\u4e1a\u7684\u89e3\u51b3\u65b9\u6848\uff0c\u5b83\u53ef\u4ee5\u5e2e\u52a9\u4f60\uff1a",source:"@site/i18n/zh-cn/docusaurus-plugin-content-docs/current/pages/intro/welcome.md",sourceDirName:"pages/intro",slug:"/pages/intro/welcome",permalink:"/zh-cn/pages/intro/welcome",draft:!1,editUrl:"https://github.com/microsoft/rushstack-websites/tree/main/websites/rushjs.io/docs/pages/intro/welcome.md",tags:[],version:"current",frontMatter:{title:"\u6b22\u8fce\u4f7f\u7528 Rush"},sidebar:"docsSidebar",next:{title:"\u4e3a\u4ec0\u4e48\u4f7f\u7528\u4e00\u4e2a\u5927\u4ed3\u5e93\uff1f\uff01",permalink:"/zh-cn/pages/intro/why_mono"}},c={},u=[],m={toc:u},h="wrapper";function k(e){var t=e.components,r=(0,a.Z)(e,p);return(0,o.kt)(h,(0,n.Z)({},m,r,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("img",{src:"/images/rush.svg",alt:"Rush",title:"Rush",style:{width:"12rem",paddingBottom:"1rem"}}),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"Rush")," \u53ef\u4ee5\u8ba9 JavaScript \u5f00\u53d1\u8005\u66f4\u8f7b\u677e\u5730\u540c\u65f6\u6784\u5efa\u3001\u53d1\u5e03\u591a\u4e2a NPM \u5305\u3002\u5982\u679c\u4f60\u6b63\u5728\u5c06\u4f60\u7684\u6240\u6709\u9879\u76ee\u6574\u5408\u5230\u4e00\u4e2a\u4ed3\u5e93\u5185\uff0c\u90a3\u4e48\u4f60\u6765\u5bf9\u5730\u65b9\u4e86\uff01Rush \u662f\u4e00\u4e2a\u5feb\u901f\u3001\u4e13\u4e1a\u7684\u89e3\u51b3\u65b9\u6848\uff0c\u5b83\u53ef\u4ee5\u5e2e\u52a9\u4f60\uff1a"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("strong",{parentName:"li"},"\u4ec5\u9700\u4e00\u6b21 NPM \u5b89\u88c5:"),' \u4ec5\u9700\u4e00\u6b65\uff0cRush \u4fbf\u53ef\u4ee5\u5c06\u4f60\u9879\u76ee\u7684\u6240\u6709\u4f9d\u8d56\u5b89\u88c5\u5230\u4e00\u4e2a\u516c\u5171\u6587\u4ef6\u5939\u4e0b\uff0c\u8be5\u6587\u4ef6\u5939\u5e76\u4e0d\u50cf "package.json" \u4e00\u6837\u4f4d\u4e8e\u9879\u76ee\u7684\u6839\u76ee\u5f55\uff08\u653e\u5230\u6839\u76ee\u5f55\u7684\u8bbe\u8ba1\u53ef\u80fd\u5b58\u5728\u5e7b\u5f71\u4f9d\u8d56\u7684\u95ee\u9898\uff09\uff0c\u76f8\u53cd\uff0cRush \u4f7f\u7528\u7b26\u53f7\u94fe\u63a5\u6765\u4e3a\u6bcf\u4e2a\u9879\u76ee\u91cd\u65b0\u6784\u5efa\u4e00\u4e2a\u51c6\u786e\u7684 "node_modules" \u6587\u4ef6\u3002')),(0,o.kt)("p",null,"\u23f5 ",(0,o.kt)("strong",{parentName:"p"},"\u8be5\u7b97\u6cd5\u652f\u6301 ",(0,o.kt)("a",{parentName:"strong",href:"/zh-cn/pages/maintainer/package_managers"},"PNPM, NPM, and Yarn")," \u7b49\u5305\u7ba1\u7406\u5de5\u5177.")),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("strong",{parentName:"li"},"\u672c\u5730\u81ea\u52a8\u94fe\u63a5\uff1a")," \u5728 Rush \u4ed3\u5e93\u5185\u7684\u6240\u6709\u9879\u76ee\u4e4b\u95f4\u88ab\u81ea\u52a8\u94fe\u63a5\uff0c\u5f53\u4ee3\u7801\u53d1\u751f\u53d8\u52a8\u65f6\uff0c\u4f60\u53ef\u4ee5\u5728\u4e0d\u53d1\u5e03\u7684\u60c5\u51b5\u4e0b\u770b\u5230\u4e0b\u6e38\u6240\u6709\u7684\u53d8\u52a8\uff0c\u540c\u65f6\uff0c\u4e5f\u4e0d\u4f1a\u56f0\u6270\u4e8e ",(0,o.kt)("inlineCode",{parentName:"li"},"npm link")," \u5982\u4f55\u4f7f\u7528\uff1b\u5982\u679c\u4f60\u4e0d\u60f3\u8ba9\u67d0\u4e00\u4e2a\u4ed3\u5e93\u88ab\u94fe\u63a5\uff0c\u90a3\u4e5f\u5f88\u5bb9\u6613\u505a\u5230\u3002")),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"\u5feb\u901f\u6784\u5efa\uff1a")," Rush \u4f1a\u68c0\u6d4b\u4f9d\u8d56\u56fe\uff0c\u5e76\u6309\u7167\u6b63\u786e\u7684\u987a\u5e8f\u6784\u5efa\u4f60\u7684\u9879\u76ee\u3002\u5982\u679c\u4e24\u4e2a\u5e93\u6ca1\u6709\u88ab\u4e92\u76f8\u4f9d\u8d56\uff0cRush \u4f1a\u4f7f\u7528\u72ec\u7acb\u7684 NodeJS \u8fdb\u7a0b\u6765\u5e76\u884c\u6784\u5efa\uff08\u540c\u65f6\u8fd9\u4e9b\u5e76\u884c\u7684\u8fdb\u7a0b\u4f1a\u4ee5 ",(0,o.kt)("a",{parentName:"p",href:"https://www.npmjs.com/package/@rushstack/stream-collator"},"\u53ef\u8bfb\u7684\u987a\u5e8f")," \u4e0b\u663e\u793a\u63a7\u5236\u53f0\u8f93\u51fa\uff09\u3002\u5728\u5b9e\u8df5\u4e2d\uff0c\u8fd9\u79cd\u591a\u8fdb\u7a0b\u65b9\u5f0f\u53ef\u4ee5\u6bd4\u6240\u6709\u5f02\u6b65\u51fd\u6570\u8fd0\u884c\u5728\u5728\u5355\u7ebf\u7a0b\u7684 Gulpfile \u4e2d\u63d0\u4f9b\u663e\u8457\u7684\u901f\u5ea6\u63d0\u5347\u3002"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u5b50\u96c6\u6784\u5efa\u548c\u589e\u91cf\u6784\u5efa\uff1a")," \u5982\u679c\u4f60\u4ec5\u4ec5\u60f3\u6784\u5efa\u4e00\u90e8\u5206\u9879\u76ee\uff0c\u53ef\u4ee5\u4f7f\u7528 ",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild --to ")," \u6765\u5b9e\u73b0\u4e00\u4e2a\u4ec5\u5305\u542b\u4e0a\u6e38\u4f9d\u8d56\u7684\u6e05\u7406\u5f0f\u6784\u5efa\uff0c\u5b83\u4f1a\u91cd\u65b0\u6784\u5efa\u8be5 project \u53ca\u5176\u4f9d\u8d56\u7684\u9879\u76ee\uff1b",(0,o.kt)("inlineCode",{parentName:"p"},"rush rebuild --from ")," \u53ef\u4ee5\u5b9e\u73b0\u4e00\u4e2a\u4ec5\u5305\u542b\u4e0b\u6e38\u4f9d\u8d56\u7684\u6e05\u7406\u5f0f\u6784\u5efa\uff0c\u5b83\u4f1a\u91cd\u65b0\u6784\u5efa\u8be5 project \u4ee5\u53ca\u6240\u6709\u4f9d\u8d56\u8be5 project \u7684\u9879\u76ee\u3002\u5982\u679c\u4f60\u7684\u5de5\u5177\u94fe\u542f\u7528\u4e86 ",(0,o.kt)("a",{parentName:"p",href:"https://www.npmjs.com/package/@rushstack/package-deps-hash"},"package-deps-hash"),", ",(0,o.kt)("inlineCode",{parentName:"p"},"rush build")," \u4f1a\u751f\u6210\u4e00\u4e2a\u5f3a\u6709\u529b\u7684\u8de8\u9879\u76ee\u589e\u91cf\u6784\u5efa\uff08\u4e5f\u652f\u6301\u5b50\u96c6\u6784\u5efa\uff09\u3002")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u5faa\u73af\u4f9d\u8d56\uff1a")," \u5f53\u4e00\u4e2a\u5e93\u95f4\u63a5\u4f9d\u8d56\u81ea\u5df1\u7684\u65e7\u7248\u672c\u65f6\uff0c\u5904\u4e8e\u5faa\u73af\u4e2d\u7684\u9879\u76ee\u4f1a\u4f7f\u7528\u6700\u540e\u4e00\u4e2a\u53d1\u5e03\u7684\u7248\u672c\uff0c\u800c\u5176\u4ed6\u9879\u76ee\u4ecd\u7136\u4f1a\u83b7\u5f97\u6700\u65b0\u7684\u7248\u672c\u3002")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u6279\u91cf\u53d1\u5e03\uff1a")," \u53d1\u5e03\u65f6\uff0cRush \u53ef\u4ee5\u68c0\u6d4b\u54ea\u4e9b\u5305\u53d1\u751f\u4e86\u53d8\u52a8\uff0c\u540c\u65f6\u4f1a\u81ea\u52a8\u7684\u63d0\u9ad8\u76f8\u5e94\u7684\u7248\u672c\u53f7\uff0c\u5e76\u5728\u6bcf\u4e2a\u6587\u4ef6\u5939\u90a3\u6267\u884c ",(0,o.kt)("inlineCode",{parentName:"p"},"npm publish"),", \u5982\u679c\u4f60\u559c\u6b22\uff0c\u4f60\u53ef\u4ee5\u914d\u7f6e\u4f60\u7684\u670d\u52a1\u5668\uff0c\u8ba9\u5b83\u6bcf\u5c0f\u65f6\u81ea\u52a8\u6267\u884c ",(0,o.kt)("inlineCode",{parentName:"p"},"rush publish"),"\u3002")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u8ddf\u8e2a\u66f4\u65b0\u65e5\u5fd7\uff1a")," \u6bcf\u5f53\u521b\u5efa\u4e00\u4e2a PR, \u4f60\u53ef\u4ee5\u8981\u6c42\u5f00\u53d1\u8005\u4e3a\u53d7\u5230\u5f71\u54cd\u7684\u9879\u76ee\u63d0\u4f9b\u4e00\u4e2a major/minor/path \u7684\u66f4\u65b0\u6761\u76ee\u3002\u53d1\u5e03\u65f6\uff0c\u8fd9\u4e9b\u65e5\u5fd7\u4f1a\u88ab\u4ee5\u4f18\u96c5\u7684\u683c\u5f0f\u6574\u5408\u5230 ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/microsoft/rushstack/blob/main/libraries/node-core-library/CHANGELOG.md"},"CHANGELOG.md")," \u6587\u4ef6\u4e2d.")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("p",{parentName:"li"},(0,o.kt)("strong",{parentName:"p"},"\u4f01\u4e1a\u7ea7\u653f\u7b56"),"\uff1a\u60f3\u8981\u5728\u67d0\u4e2a\u4f9d\u8d56\u88ab\u52a0\u8fdb package.json \u524d\u5bf9\u8be5\u4f9d\u8d56\u8fdb\u884c\u5ba1\u6838\uff0c\u4f46\u662f\u53c8\u62c5\u5fc3\u91cd\u590d\u7684\u95ee\u9898\uff1f\u60f3\u8981\u8ba9\u4f60\u7684\u9879\u76ee\u5185\u7684\u6240\u6709\u4f9d\u8d56\u90fd\u6709\u76f8\u540c\u7248\u672c\uff1f\u662f\u5426\u6709\u4e0d\u4e13\u4e1a\u7684\u79c1\u4eba\u90ae\u7bb1\u6df7\u5165\u5230\u4e86\u4f60\u516c\u53f8\u7684 Git \u5386\u53f2\u4e2d\uff1fRush \u53ef\u4ee5\u8ba9\u591a\u4eba\u5f00\u53d1\u548c\u591a\u9879\u76ee\u6df7\u5408\u65f6\u4fdd\u6301\u4e00\u81f4\u7684\u751f\u6001\u3002"))),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"\u8fd8\u6709\u66f4\u591a\uff01")," Rush \u7531 ",(0,o.kt)("a",{parentName:"p",href:"http://aka.ms/spfx"},"Microsoft SharePoint")," \u56e2\u961f\u521b\u5efa\u3002\u6211\u4eec\u6bcf\u5929\u6784\u5efa\u6570\u767e\u4e2a\u9002\u7528\u4e8e\u751f\u4ea7\u73af\u5883\u7684 NPM \u5305\uff0c\u4ece\u5185\u90e8\u5230\u5f00\u6e90\u7684 Git \u4ed3\u5e93\uff0c\u670d\u52a1\u7b2c\u4e09\u65b9 SDK \u548c\u5b9e\u65f6\u670d\u52a1\u7684\u767e\u4e07\u7528\u6237\u3002\u5982\u679c\u5728\u5305\u7ba1\u7406\u4e0a\u5b58\u5728\u9700\u8981\u89e3\u51b3\u7684\u91cd\u8981\u95ee\u9898\uff0c\u90a3\u4e48\u5f88\u6709\u53ef\u80fd\u88ab Rush \u7684\u67d0\u4e2a\u529f\u80fd\u7279\u6027\u89e3\u51b3\u3002"))}k.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/zh-cn/assets/js/runtime~main.253e28f8.js b/zh-cn/assets/js/runtime~main.47a3a2ca.js similarity index 99% rename from zh-cn/assets/js/runtime~main.253e28f8.js rename to zh-cn/assets/js/runtime~main.47a3a2ca.js index 571c5691..90fa7110 100644 --- a/zh-cn/assets/js/runtime~main.253e28f8.js +++ b/zh-cn/assets/js/runtime~main.47a3a2ca.js @@ -1 +1 @@ -(()=>{"use strict";var e,a,d,c,f,b={},t={};function r(e){var a=t[e];if(void 0!==a)return a.exports;var d=t[e]={exports:{}};return b[e].call(d.exports,d,d.exports,r),d.exports}r.m=b,e=[],r.O=(a,d,c,f)=>{if(!d){var b=1/0;for(i=0;i=f)&&Object.keys(r.O).every((e=>r.O[e](d[o])))?d.splice(o--,1):(t=!1,f0&&e[i-1][2]>f;i--)e[i]=e[i-1];e[i]=[d,c,f]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},d=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var f=Object.create(null);r.r(f);var b={};a=a||[null,d({}),d([]),d(d)];for(var t=2&c&&e;"object"==typeof t&&!~a.indexOf(t);t=d(t))Object.getOwnPropertyNames(t).forEach((a=>b[a]=()=>e[a]));return b.default=()=>e,r.d(f,b),f},r.d=(e,a)=>{for(var d in a)r.o(a,d)&&!r.o(e,d)&&Object.defineProperty(e,d,{enumerable:!0,get:a[d]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,d)=>(r.f[d](e,a),a)),[])),r.u=e=>"assets/js/"+({12:"b2dab381",53:"935f2afb",152:"35e870cd",229:"d51f65fe",258:"ec27df8b",346:"ad2b9d68",483:"ea4262d8",600:"17c455d4",772:"bf56ae4d",796:"8d839558",805:"1cad9f42",818:"e05a5acc",893:"84611dc1",903:"e9357c82",927:"1df5d915",967:"7027e4c2",1103:"a0b209c5",1273:"73c245c2",1325:"7e3dcd97",1332:"380a0223",1413:"300c2de1",1502:"2f97c71a",1527:"26d03265",1747:"21532442",1801:"d84d816f",1807:"e48e6b3e",1892:"1962e0ad",1975:"9d7e3736",2188:"271382b6",2253:"278df401",2435:"3ee79011",2728:"3c7632d0",2742:"9605ab48",2868:"f1833d2f",2972:"d684a32d",3159:"a79e7852",3224:"33a22dbe",3230:"4dbe0065",3237:"1df93b7f",3252:"ab35d70b",3423:"5bd5b781",3507:"ea8e34cd",4017:"fab9881a",4024:"7eaee0fe",4070:"c4f4e2a2",4118:"95c818bd",4141:"adc22863",4192:"38f59ed3",4382:"bfb764ba",4442:"94da874f",4475:"a5d153a9",4696:"c1874168",4711:"8b64d730",4732:"3809b696",4738:"d11a7dc9",4864:"8007e6ea",4932:"a2fa2b08",5065:"0d1db017",5066:"3b7f15d6",5101:"3858caba",5215:"6db34b32",5324:"97cc50ca",5833:"f1462f32",6032:"488a4814",6085:"83bcf68e",6108:"ed21afe2",6199:"2ee6c7eb",6505:"f7302dad",6717:"5ae4e7b1",6718:"86709c0f",6782:"514cdfc6",6789:"6b3ab3b2",6790:"6821c247",6851:"48d2b91f",6995:"0b6fcc7a",7182:"9b10ff19",7262:"4178084f",7295:"d1a53368",7411:"675a17f4",7560:"cc4650a7",7682:"aa1eaa5a",7722:"2970f5d1",7865:"eaa53c02",7918:"17896441",7920:"1a4e3797",7957:"c4006fab",8010:"a5cc47f5",8281:"fc7c0786",8453:"63299639",8508:"a0be7566",8668:"9dc47188",8681:"992a8302",8789:"ee2c95d0",8902:"140f2912",9009:"e52302ca",9113:"c36f2b01",9248:"612504fb",9499:"cc8ccd0c",9514:"1be78505",9590:"c774a42a",9746:"a0369338",9780:"53c68a99",9798:"74b61b4b"}[e]||e)+"."+{12:"6581d349",53:"df274282",152:"1ef0a736",229:"b4ea33a7",258:"5a1c55c9",346:"f13fc5ac",483:"eaf91a45",600:"5c3e8e06",772:"8b1fc586",796:"8089270c",805:"fea06099",818:"07945d9e",893:"5fae2c4e",903:"d457e093",927:"b654365f",967:"a9452f65",1103:"105ac300",1273:"03b48e1e",1325:"d9b6af2b",1332:"6430f38f",1413:"fdbb3cfa",1502:"67bb6f28",1527:"db02ef3e",1747:"db84d212",1801:"36796fb9",1807:"79af3204",1892:"5a760e36",1975:"84854e64",2188:"65cf66fd",2253:"c69cd022",2435:"1c1ddab8",2728:"5a9ee506",2742:"4b744bc1",2832:"0d9a94f2",2868:"b01b31e0",2928:"9d23e8f2",2972:"226d0bc4",3159:"0b133955",3224:"b08b75f1",3230:"87d1f980",3237:"00c2849c",3252:"ba325c44",3423:"7b79ac86",3507:"1d9317c7",4017:"af45237d",4024:"405c0c6a",4070:"683cccab",4118:"c60ceac5",4141:"e81c5f16",4192:"49d461d8",4382:"9790a7a8",4391:"e2e60112",4442:"c6094f02",4475:"c05864ce",4696:"80259771",4711:"1c2673fe",4732:"c55c282f",4738:"635c68df",4864:"08a4f7d4",4932:"c1558183",5065:"24933115",5066:"90db2a10",5101:"0de4316b",5215:"65f35c07",5324:"ee34424e",5502:"09e1c67b",5833:"38b522d8",6032:"5b18f22f",6085:"ff938333",6108:"3d9baf36",6199:"3f0a6704",6505:"ade95c91",6717:"3a715437",6718:"569c574e",6782:"a2aa88a1",6789:"8acc913b",6790:"d1d4b355",6851:"e035e8aa",6995:"8132c03d",7182:"834ec4b7",7262:"dd86f358",7295:"42edf404",7411:"b110fa3a",7560:"6478458e",7682:"bd1c8a40",7722:"905f5ba9",7865:"105133aa",7918:"781e8e87",7920:"d74d357c",7957:"bc42c9e6",8010:"27cb9e29",8281:"654ba5f2",8453:"e5268f3d",8508:"046a3fe1",8668:"4c4d5432",8681:"9dc54de8",8789:"80569f64",8902:"7ea1f672",8988:"5a29583b",9009:"b95a96fe",9042:"eabad492",9113:"cc9cd26f",9248:"674c93fb",9485:"879ad254",9499:"8e79d3c1",9514:"8ffd2c13",9590:"430c1054",9746:"e64ee89e",9780:"9530c411",9798:"ddc57431",9970:"6f0174d1"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),c={},f="rushjs.io:",r.l=(e,a,d,b)=>{if(c[e])c[e].push(a);else{var t,o;if(void 0!==d)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var f=c[e];if(delete c[e],t.parentNode&&t.parentNode.removeChild(t),f&&f.forEach((e=>e(d))),a)return a(d)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/zh-cn/",r.gca=function(e){return e={17896441:"7918",21532442:"1747",63299639:"8453",b2dab381:"12","935f2afb":"53","35e870cd":"152",d51f65fe:"229",ec27df8b:"258",ad2b9d68:"346",ea4262d8:"483","17c455d4":"600",bf56ae4d:"772","8d839558":"796","1cad9f42":"805",e05a5acc:"818","84611dc1":"893",e9357c82:"903","1df5d915":"927","7027e4c2":"967",a0b209c5:"1103","73c245c2":"1273","7e3dcd97":"1325","380a0223":"1332","300c2de1":"1413","2f97c71a":"1502","26d03265":"1527",d84d816f:"1801",e48e6b3e:"1807","1962e0ad":"1892","9d7e3736":"1975","271382b6":"2188","278df401":"2253","3ee79011":"2435","3c7632d0":"2728","9605ab48":"2742",f1833d2f:"2868",d684a32d:"2972",a79e7852:"3159","33a22dbe":"3224","4dbe0065":"3230","1df93b7f":"3237",ab35d70b:"3252","5bd5b781":"3423",ea8e34cd:"3507",fab9881a:"4017","7eaee0fe":"4024",c4f4e2a2:"4070","95c818bd":"4118",adc22863:"4141","38f59ed3":"4192",bfb764ba:"4382","94da874f":"4442",a5d153a9:"4475",c1874168:"4696","8b64d730":"4711","3809b696":"4732",d11a7dc9:"4738","8007e6ea":"4864",a2fa2b08:"4932","0d1db017":"5065","3b7f15d6":"5066","3858caba":"5101","6db34b32":"5215","97cc50ca":"5324",f1462f32:"5833","488a4814":"6032","83bcf68e":"6085",ed21afe2:"6108","2ee6c7eb":"6199",f7302dad:"6505","5ae4e7b1":"6717","86709c0f":"6718","514cdfc6":"6782","6b3ab3b2":"6789","6821c247":"6790","48d2b91f":"6851","0b6fcc7a":"6995","9b10ff19":"7182","4178084f":"7262",d1a53368:"7295","675a17f4":"7411",cc4650a7:"7560",aa1eaa5a:"7682","2970f5d1":"7722",eaa53c02:"7865","1a4e3797":"7920",c4006fab:"7957",a5cc47f5:"8010",fc7c0786:"8281",a0be7566:"8508","9dc47188":"8668","992a8302":"8681",ee2c95d0:"8789","140f2912":"8902",e52302ca:"9009",c36f2b01:"9113","612504fb":"9248",cc8ccd0c:"9499","1be78505":"9514",c774a42a:"9590",a0369338:"9746","53c68a99":"9780","74b61b4b":"9798"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,d)=>{var c=r.o(e,a)?e[a]:void 0;if(0!==c)if(c)d.push(c[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var f=new Promise(((d,f)=>c=e[a]=[d,f]));d.push(c[2]=f);var b=r.p+r.u(a),t=new Error;r.l(b,(d=>{if(r.o(e,a)&&(0!==(c=e[a])&&(e[a]=void 0),c)){var f=d&&("load"===d.type?"missing":d.type),b=d&&d.target&&d.target.src;t.message="Loading chunk "+a+" failed.\n("+f+": "+b+")",t.name="ChunkLoadError",t.type=f,t.request=b,c[1](t)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,d)=>{var c,f,[b,t,o]=d,n=0;if(b.some((a=>0!==e[a]))){for(c in t)r.o(t,c)&&(r.m[c]=t[c]);if(o)var i=o(r)}for(a&&a(d);n{"use strict";var e,a,d,c,f,b={},t={};function r(e){var a=t[e];if(void 0!==a)return a.exports;var d=t[e]={exports:{}};return b[e].call(d.exports,d,d.exports,r),d.exports}r.m=b,e=[],r.O=(a,d,c,f)=>{if(!d){var b=1/0;for(i=0;i=f)&&Object.keys(r.O).every((e=>r.O[e](d[o])))?d.splice(o--,1):(t=!1,f0&&e[i-1][2]>f;i--)e[i]=e[i-1];e[i]=[d,c,f]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},d=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var f=Object.create(null);r.r(f);var b={};a=a||[null,d({}),d([]),d(d)];for(var t=2&c&&e;"object"==typeof t&&!~a.indexOf(t);t=d(t))Object.getOwnPropertyNames(t).forEach((a=>b[a]=()=>e[a]));return b.default=()=>e,r.d(f,b),f},r.d=(e,a)=>{for(var d in a)r.o(a,d)&&!r.o(e,d)&&Object.defineProperty(e,d,{enumerable:!0,get:a[d]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,d)=>(r.f[d](e,a),a)),[])),r.u=e=>"assets/js/"+({12:"b2dab381",53:"935f2afb",152:"35e870cd",229:"d51f65fe",258:"ec27df8b",346:"ad2b9d68",483:"ea4262d8",600:"17c455d4",772:"bf56ae4d",796:"8d839558",805:"1cad9f42",818:"e05a5acc",893:"84611dc1",903:"e9357c82",927:"1df5d915",967:"7027e4c2",1103:"a0b209c5",1273:"73c245c2",1325:"7e3dcd97",1332:"380a0223",1413:"300c2de1",1502:"2f97c71a",1527:"26d03265",1747:"21532442",1801:"d84d816f",1807:"e48e6b3e",1892:"1962e0ad",1975:"9d7e3736",2188:"271382b6",2253:"278df401",2435:"3ee79011",2728:"3c7632d0",2742:"9605ab48",2868:"f1833d2f",2972:"d684a32d",3159:"a79e7852",3224:"33a22dbe",3230:"4dbe0065",3237:"1df93b7f",3252:"ab35d70b",3423:"5bd5b781",3507:"ea8e34cd",4017:"fab9881a",4024:"7eaee0fe",4070:"c4f4e2a2",4118:"95c818bd",4141:"adc22863",4192:"38f59ed3",4382:"bfb764ba",4442:"94da874f",4475:"a5d153a9",4696:"c1874168",4711:"8b64d730",4732:"3809b696",4738:"d11a7dc9",4864:"8007e6ea",4932:"a2fa2b08",5065:"0d1db017",5066:"3b7f15d6",5101:"3858caba",5215:"6db34b32",5324:"97cc50ca",5833:"f1462f32",6032:"488a4814",6085:"83bcf68e",6108:"ed21afe2",6199:"2ee6c7eb",6505:"f7302dad",6717:"5ae4e7b1",6718:"86709c0f",6782:"514cdfc6",6789:"6b3ab3b2",6790:"6821c247",6851:"48d2b91f",6995:"0b6fcc7a",7182:"9b10ff19",7262:"4178084f",7295:"d1a53368",7411:"675a17f4",7560:"cc4650a7",7682:"aa1eaa5a",7722:"2970f5d1",7865:"eaa53c02",7918:"17896441",7920:"1a4e3797",7957:"c4006fab",8010:"a5cc47f5",8281:"fc7c0786",8453:"63299639",8508:"a0be7566",8668:"9dc47188",8681:"992a8302",8789:"ee2c95d0",8902:"140f2912",9009:"e52302ca",9113:"c36f2b01",9248:"612504fb",9499:"cc8ccd0c",9514:"1be78505",9590:"c774a42a",9746:"a0369338",9780:"53c68a99",9798:"74b61b4b"}[e]||e)+"."+{12:"6581d349",53:"df274282",152:"1ef0a736",229:"b4ea33a7",258:"5a1c55c9",346:"f13fc5ac",483:"eaf91a45",600:"5c3e8e06",772:"8b1fc586",796:"8089270c",805:"fea06099",818:"07945d9e",893:"5fae2c4e",903:"d457e093",927:"b654365f",967:"a9452f65",1103:"105ac300",1273:"03b48e1e",1325:"d9b6af2b",1332:"6430f38f",1413:"fdbb3cfa",1502:"67bb6f28",1527:"db02ef3e",1747:"db84d212",1801:"36796fb9",1807:"79af3204",1892:"5a760e36",1975:"84854e64",2188:"65cf66fd",2253:"c69cd022",2435:"1c1ddab8",2728:"5a9ee506",2742:"4b744bc1",2832:"0d9a94f2",2868:"b01b31e0",2928:"9d23e8f2",2972:"226d0bc4",3159:"0b133955",3224:"b08b75f1",3230:"87d1f980",3237:"00c2849c",3252:"ba325c44",3423:"7b79ac86",3507:"1d9317c7",4017:"af45237d",4024:"405c0c6a",4070:"683cccab",4118:"c60ceac5",4141:"e81c5f16",4192:"49d461d8",4382:"9790a7a8",4391:"e2e60112",4442:"c6094f02",4475:"c05864ce",4696:"80259771",4711:"1c2673fe",4732:"c55c282f",4738:"635c68df",4864:"08a4f7d4",4932:"c1558183",5065:"24933115",5066:"90db2a10",5101:"0de4316b",5215:"65f35c07",5324:"ee34424e",5502:"09e1c67b",5833:"38b522d8",6032:"5b18f22f",6085:"ff938333",6108:"3d9baf36",6199:"3f0a6704",6505:"ade95c91",6717:"3a715437",6718:"569c574e",6782:"a2aa88a1",6789:"8acc913b",6790:"d1d4b355",6851:"e035e8aa",6995:"8132c03d",7182:"834ec4b7",7262:"dd86f358",7295:"42edf404",7411:"b110fa3a",7560:"6478458e",7682:"bd1c8a40",7722:"905f5ba9",7865:"105133aa",7918:"781e8e87",7920:"d74d357c",7957:"bc42c9e6",8010:"0c6954d0",8281:"654ba5f2",8453:"e5268f3d",8508:"046a3fe1",8668:"4c4d5432",8681:"9dc54de8",8789:"80569f64",8902:"7ea1f672",8988:"5a29583b",9009:"b95a96fe",9042:"eabad492",9113:"cc9cd26f",9248:"674c93fb",9485:"879ad254",9499:"8e79d3c1",9514:"8ffd2c13",9590:"430c1054",9746:"e64ee89e",9780:"9530c411",9798:"ddc57431",9970:"6f0174d1"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),c={},f="rushjs.io:",r.l=(e,a,d,b)=>{if(c[e])c[e].push(a);else{var t,o;if(void 0!==d)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var f=c[e];if(delete c[e],t.parentNode&&t.parentNode.removeChild(t),f&&f.forEach((e=>e(d))),a)return a(d)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/zh-cn/",r.gca=function(e){return e={17896441:"7918",21532442:"1747",63299639:"8453",b2dab381:"12","935f2afb":"53","35e870cd":"152",d51f65fe:"229",ec27df8b:"258",ad2b9d68:"346",ea4262d8:"483","17c455d4":"600",bf56ae4d:"772","8d839558":"796","1cad9f42":"805",e05a5acc:"818","84611dc1":"893",e9357c82:"903","1df5d915":"927","7027e4c2":"967",a0b209c5:"1103","73c245c2":"1273","7e3dcd97":"1325","380a0223":"1332","300c2de1":"1413","2f97c71a":"1502","26d03265":"1527",d84d816f:"1801",e48e6b3e:"1807","1962e0ad":"1892","9d7e3736":"1975","271382b6":"2188","278df401":"2253","3ee79011":"2435","3c7632d0":"2728","9605ab48":"2742",f1833d2f:"2868",d684a32d:"2972",a79e7852:"3159","33a22dbe":"3224","4dbe0065":"3230","1df93b7f":"3237",ab35d70b:"3252","5bd5b781":"3423",ea8e34cd:"3507",fab9881a:"4017","7eaee0fe":"4024",c4f4e2a2:"4070","95c818bd":"4118",adc22863:"4141","38f59ed3":"4192",bfb764ba:"4382","94da874f":"4442",a5d153a9:"4475",c1874168:"4696","8b64d730":"4711","3809b696":"4732",d11a7dc9:"4738","8007e6ea":"4864",a2fa2b08:"4932","0d1db017":"5065","3b7f15d6":"5066","3858caba":"5101","6db34b32":"5215","97cc50ca":"5324",f1462f32:"5833","488a4814":"6032","83bcf68e":"6085",ed21afe2:"6108","2ee6c7eb":"6199",f7302dad:"6505","5ae4e7b1":"6717","86709c0f":"6718","514cdfc6":"6782","6b3ab3b2":"6789","6821c247":"6790","48d2b91f":"6851","0b6fcc7a":"6995","9b10ff19":"7182","4178084f":"7262",d1a53368:"7295","675a17f4":"7411",cc4650a7:"7560",aa1eaa5a:"7682","2970f5d1":"7722",eaa53c02:"7865","1a4e3797":"7920",c4006fab:"7957",a5cc47f5:"8010",fc7c0786:"8281",a0be7566:"8508","9dc47188":"8668","992a8302":"8681",ee2c95d0:"8789","140f2912":"8902",e52302ca:"9009",c36f2b01:"9113","612504fb":"9248",cc8ccd0c:"9499","1be78505":"9514",c774a42a:"9590",a0369338:"9746","53c68a99":"9780","74b61b4b":"9798"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,d)=>{var c=r.o(e,a)?e[a]:void 0;if(0!==c)if(c)d.push(c[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var f=new Promise(((d,f)=>c=e[a]=[d,f]));d.push(c[2]=f);var b=r.p+r.u(a),t=new Error;r.l(b,(d=>{if(r.o(e,a)&&(0!==(c=e[a])&&(e[a]=void 0),c)){var f=d&&("load"===d.type?"missing":d.type),b=d&&d.target&&d.target.src;t.message="Loading chunk "+a+" failed.\n("+f+": "+b+")",t.name="ChunkLoadError",t.type=f,t.request=b,c[1](t)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,d)=>{var c,f,[b,t,o]=d,n=0;if(b.some((a=>0!==e[a]))){for(c in t)r.o(t,c)&&(r.m[c]=t[c]);if(o)var i=o(r)}for(a&&a(d);nRush - +
    Rush StackShopBlogEvents

    Rush：一个可扩展的Web单仓库管理器

    Rush让那些从一个公共Git仓库构建和发布多个包的JavaScript开发者的生活变得更轻松。如果你正打算将你的大型应用程序分解为更小的部分，并且你已经意识到 为什么这不可行 将每个包放在一个单独的仓库里... 那么Rush就是为你准备的！

    monorepo diagram
    monorepo diagram

    Rush的不同之处

    现在许多不同的工具可以在20个不同的文件夹中运行"npm install"和"npm run build"。那么Rush有什么优点呢？

    Git repositories

    适应大型仓库

    Rush是由维护大型生产单仓库的专业工程师构建的。我们的工作是为我们的同事提供最佳的开发者体验，而不是将你转变为付费咨询或托管服务的客户。我们维护的仓库包含有多年Git历史记录的数百个应用程序。为了管理这种规模，Rush提供并行构建、子集构建、增量构建和分布式构建。

    large team

    为大型团队设计

    Rush提供了许多机制来引导新手和协调团队间的协作。仓库策略允许在接受新的包依赖关系之前对其进行审查。Rush可以在你的仓库中强制执行一致的依赖版本。不同的项目子集可以使用锁定步调或独立版本策略进行独立发布。

    NPM phantom dependency

    可靠的NPM安装

    Rush的安装模型利用PNPM包管理器消除 幽灵依赖 和 NPM替身 这些使大规模安装受挫的问题。你可以使用我们的 锁文件资源管理器 配套工具来可视化和解决版本冲突。

    motorbike and tricycle

    易于管理

    当你维护一个大型仓库时，你不希望开发者提出无法在任何其他计算机上复现的支持请求。Rush有助于确保安装和构建完全确定。甚至Rush引擎版本也会根据你的Git分支自动安装。如果你定义自定义命令或选项，它们会被严格验证，并作为Rush命令行帮助的一部分进行文档记录。

    army knife

    一站式解决方案

    厌倦了从多个工具中拼凑出你的开发者体验，而这些工具似乎从未正确集成过吗？Rush是一个统一的协调器，可以安装、链接、构建、生成变更日志、发布和升级版本。这些功能旨在与更广泛的 Rush Stack 工具和实践套件集成。

    free price tag

    开放模式

    Rush软件是免费和开源的。我们欢迎社区的贡献！我们也对你的工具链持开放态度：在Rush仓库中，每个项目文件夹都保持完全独立，可以单独安装，如果需要也易于迁移。只需要相对较少的努力就可以为一组特定的项目启用/禁用Rush。

    谁在使用Rush？

    Azure SDK logo
    Azure SDK
    HBO Max logo
    HBO Max
    OneDrive logo
    OneDrive
    SharePoint logo
    SharePoint
    Office 365 Small Business logo
    Office 365 Small Business
    Windows Store logo
    Windows Store
    Office Web Apps logo
    Office Web Apps
    SimplrJS react-forms logo
    SimplrJS react-forms
    Telia Company logo
    Telia Company
    Welbi logo
    Welbi
    Wix logo
    Wix
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/link/pnpm-issue-5132/index.html b/zh-cn/link/pnpm-issue-5132/index.html index 1bc71276..64bc1a99 100644 --- a/zh-cn/link/pnpm-issue-5132/index.html +++ b/zh-cn/link/pnpm-issue-5132/index.html @@ -6,13 +6,13 @@ pnpm-issue-5132 | Rush - +
    Rush StackShopBlogEvents

    Redirecting...

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/link/upgrading/index.html b/zh-cn/link/upgrading/index.html index 231e8eab..09bcd7c9 100644 --- a/zh-cn/link/upgrading/index.html +++ b/zh-cn/link/upgrading/index.html @@ -6,13 +6,13 @@ upgrading | Rush - +
    Rush StackShopBlogEvents

    Redirecting...

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/api/index.html b/zh-cn/pages/advanced/api/index.html index 9aa2a075..33ac7432 100644 --- a/zh-cn/pages/advanced/api/index.html +++ b/zh-cn/pages/advanced/api/index.html @@ -6,13 +6,13 @@ 使用 Rush 库的 API | Rush - +
    Rush StackShopBlogEvents

    使用 Rush 库的 API

    Rush 通过 API 提供了自动化脚本使用的接口。它在 Rush 工程中的竭诚 API 可以参考以下文档：

         接口手册： @microsoft/rush-lib package

    下面是一些用法示例：

    虽然这些示例为 JavaScript 代码，但我们强烈建议使用 TypeScript. 起初需要花费些时间，但是长时间运行时，它可以节省时间和减少维护的工作。

    读取 rush.json 配置​

    建议使用提供了很多数据信息的 RushConfiguration 类来读取 rush.json, 而不是直接读取 rush.json 文件。

    例如，以下脚本展示了 Rush 内所有的项目和它们的文件夹：

    const rushLib = require('@microsoft/rush-lib');

    // loadFromDefaultLocation() 会搜索父亲文件来寻找 "rush.json", 之后会解析它并加载相关的配置文件。
    const rushConfiguration = rushLib.RushConfiguration.loadFromDefaultLocation({
      startingFolder: process.cwd()
    });

    for (const project of rushConfiguration.projects) {
      console.log(project.packageName + ':');
      console.log('  ' + project.projectRelativeFolder);
    }

    修改 package.json 文件​

    如果你想修改 package.json 文件，PackageJsonEditor 类提供了一些有用的校验和标准化方法：

    const rushLib = require('@microsoft/rush-lib');

    const rushConfiguration = rushLib.RushConfiguration.loadFromDefaultLocation({
      startingFolder: process.cwd()
    });

    // 它将寻找在 rush.json 中的 "@rushstack/ts-command-line", 而不需要指定 NPM 包的作用域
    const project = rushConfiguration.findProjectByShorthandName('ts-command-line');

    // 将 lodash 作为一个可选依赖
    project.packageJsonEditor.addOrUpdateDependency('lodash', '4.17.15', 'optionalDependencies');

    // 保存修改过的 package.json 文件
    project.packageJsonEditor.saveIfModified();

    生成 README.md 摘要​

    作为一个更实际的例子，repo-toolbox/src/ReadmeAction.ts 展示了如何使用这些 API 来生成 Rush Stack 库的 README.md.

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/compatibility_db/index.html b/zh-cn/pages/advanced/compatibility_db/index.html index 560a7112..4a165030 100644 --- a/zh-cn/pages/advanced/compatibility_db/index.html +++ b/zh-cn/pages/advanced/compatibility_db/index.html @@ -6,13 +6,13 @@ PNPM Compatibility DB | Rush - +
    Rush StackShopBlogEvents

    PNPM Compatibility DB

    Both Yarn and PNPM support a feature called the Compatibility DB, which is a public database of package.json fixups. These fixups solve known issues that the official maintainer of an NPM package may be unwilling to solve. (The best practice would be to avoid such packages, but often that is impractical.) Compatibility DB fixups are similar to user-authored rules found in .pnpmfile.cjs. They are maintained with the @yarnpkg/extensions package.

    PNPM's feature protects small projects from common pitfalls, but the approach has some downsides for a large monorepo:

    • Hidden magic: The fixups are bundled into the PNPM binary. When trying to coordinate complex cross-project version dependencies, it is awkward for key inputs to be in a file with no Git diff, not even viewable in the GitHub website.
    • Unnecessary coupling: Different versions of the @yarnpkg/extensions rules are bundled into different PNPM releases. This may cause churn the lockfile when upgrading or downgrading the package manager.
    • Applied last: The fixups are applied after .pnpmfile.cjs. This means the fixed up versions aren't visible to the user's own transformations or logging, and .pnpmfile.cjs is no longer the final authority about version choices.

    To avoid these issues, rush install and rush update always disable the Compatibility DB feature when invoking PNPM.

    Details:

    • Compatibility DB is implemented by PNPM versions >= 6.32.12, >= 7.0.1 (but not 7.0.0)
    • The ignore-compatibility-db switch is implemented in newer PNPM releases: >= 6.34.0 <7.0.01 and >= 7.9.0
    • Compatibility DB is disabled by Rush versions >= 5.76.0 if possible...
    • ..otherwise, if the switch is missing, Rush prints a warning recommending to upgrade PNPM

    The Compatibility DB fixes are useful. To apply them in your Rush repo, it's recommended to copy these settings into a proper Git-tracked file such as .pnpmfile.cjs.

    💡 Feature idea: Propose an automated mechanism for syncing @yarnpkg/extensions into a Git-tracked file under common/config/rush.

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/config_files/index.html b/zh-cn/pages/advanced/config_files/index.html index 57df1010..3ff378ea 100644 --- a/zh-cn/pages/advanced/config_files/index.html +++ b/zh-cn/pages/advanced/config_files/index.html @@ -6,13 +6,13 @@ 配置文件参考 | Rush - +
    Rush StackShopBlogEvents

    配置文件参考

    配置文件​

    文件列表作用
    common/temp/install-run/...存储 install-run.js 和 install-run-rush.js 脚本。 可以查看启用 CI 构建一文。
    common/temp/node_modules/...安装的库，它只是 npm install 的输出，其中没有任何符号连接。
    common/temp/npm-cache/...本地 NPM 的缓存，由于并发问题，Rush 不会使用全局的 NPM 缓存。
    common/temp/npm-local/...基于 npmVersion 的配置，Rush 会在根目录安装 NPM 包，同时给每个项目创建符号链接。
    common/temp/npm-tmp/...NPM 安装时候创建的临时文件。
    common/temp/projects/...common/temp/package.json 引用的合成项目。
    common/temp/rush-recycler/...用于加速递归删除。
    common/temp/last-install.flag不必关心该文件，它追踪了上次 rush install 成功的时间戳。
    common/temp/package.json公共文件的定义。
    common/temp/rush-link.json不必关心该文件，当你执行 rush link 是它会创建，并被诸如 "rush build" 等命令读取。
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/incremental_builds/index.html b/zh-cn/pages/advanced/incremental_builds/index.html index 744e07e8..c6c4554a 100644 --- a/zh-cn/pages/advanced/incremental_builds/index.html +++ b/zh-cn/pages/advanced/incremental_builds/index.html @@ -6,13 +6,13 @@ 增量构建 | Rush - +
    Rush StackShopBlogEvents

    增量构建

    Rush 的增量构建功能可以通过跳过某些已经是最新的库来加速构建，在本文中，“已经是最新的”含义是：

    1. 项目已经在本地构建过，并且
    2. 其源码和 NPM 依赖没有发生变化，并且
    3. 如果该项目依赖另一个 Rush 项目，这些项目都是最新的，并且
    4. 命令行参数没有变化（例如，在 rush build 后调用 rush build --production 需要重新构建）。

    该功能可以和选择项目参数结合使用，其作用是开发者显式的告诉 Rush 那些项目需要被处理。增量构建可以重新使用本地磁盘上已经存在的输出（与构建缓存形成鲜明的对比，构建缓存可以从云端获取到之前的构建缓存，它依然是实验性的功能，但是它可能最终会替换增量构建。)

    如何使用​

    只需要执行 rush build 两次就能使用增量构建：

    $ rush install

    # 可能需要一点时间
    $ rush build

    # 第二次耗时只需要几秒钟
    $ rush build

    rush build 是增量构建（rush rebuild 不是增量构建）。如果是你自定义的全局指令, 你可以在配置文件 command-line.json 中启用 "incremental" 选项来使其成为增量构建。

    它是如何工作的？​

    你的项目构建脚本（被 rushx build 或 npm run build 调用）可能自身就有增量优化。例如，Heft 对于不同的任务维护了多缓存。然而，甚至当 rushx build 对一个项目无效时，仍然会由于开启了 Node 进程、调用 JavaScript 文件，比较单个文件的时间戳而导致的昂贵的开销，假设上述操作需要 500ms, 如果你的 monorepo 存在 100 个项目，那么即使在项目都是最新的情况下，上述工作要花费 100 * 0.5 == 50 seconds.

    Rush 通过一次搜索来对仓库进行全局分析，进而消除了这次操作耗时 —— 这种方式在所有项目都是最新的情况下，可以不唤醒所有项目。作为一个额外的优化，Rush 的增量分析依赖文件哈希而不是时间戳。如果你切换到不同的分支，或者切来切去，许多文件的时间戳会改变，但是 Rush 的增量分析不会受到影响，因为源文件没有发生改变。文件哈希受到 @rushstack/package-deps-hash 管理，哈希值被存储在 <your-project>/.rush/temp/package-deps_<task-name>.json 的文件中，监视这个文件可以提供一些技术指标。

    只构建发生变化的项目（不安全）​

    假设我们的 monorepo 有以下项目：

    a sample monorepo

    上述图例中，圆圈表示本地项目，没有外部的 NPM 依赖。箭头 D 到 C 表明 D 依赖 C, 这意味着 C 必须在 D 构建前构建。

    假设构建完所有项目后，在 B 项目下改变了源文件。项目 C 和 D 依赖于 B, 因此也需要构建：

    rush build --impacted-by B

    我们可能会调用：

    # 该命令会重新构建 B, C, D
    $ rush build

    但是，你如何知道你对 C 的改变是否会影响其 API? 例如，也许你想更新某个控制按钮的颜色，或者某个错误信息中的文本。

    --changed-projects-only 参数告知 Rush 之构建那些文件被更改的项目：

    rush build --only B

    我们的调用方式如下：

    # 下面指令会重新构建 B（但是忽略 C 和 D）
    $ rush build --changed-projects-only

    --changed-projects-only 参数是不安全的，因为当下游项目重新构建时可能遇到错误。假设你比 Rush 更了解哪些需要重新构建，那么这个参数可以节省时间。如果你不知道，那么可以调用 rush build 来保证正确性。

    参考

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/installation_variants/index.html b/zh-cn/pages/advanced/installation_variants/index.html index 67c75c6f..cf8c9327 100644 --- a/zh-cn/pages/advanced/installation_variants/index.html +++ b/zh-cn/pages/advanced/installation_variants/index.html @@ -6,13 +6,13 @@ 安装变种 | Rush - +
    Rush StackShopBlogEvents

    安装变种

    有时你也许想要使用修改后的依赖来构建整个项目。例如，假设你刚刚完成一个框架的主版本升级工作，但是你想在迁移过程中保持与之前版本的兼容性。开发人员应该使用新版本的依赖，但是提交 PR 时，你想要让 CI 任务构建整个项目两次，一次是使用旧版本的依赖，一次是使用新版本的依赖。

    你可以通过编写简单的脚本来搜索和替换 package.json 下的版本号来解决这个问题，但是你很快发现其他的文件被影响了：

    • shrinkwrap 文件: 除非你保持两个变量的独立的 shrinkwrap 文件，否则构建不可预知。
    • common-versions.json: preferredVersions 或 allowedAlternativeVersions 可能需要不同的版本号。
    • pnpmfile.js: 如果你对某些有问题的包有解决方案，那么可能需要两个版本号。

    这个问题看起来需要使用单独的、并行的配置文件来解决。从 Rush 5.4.0 版本，现在有开箱即用的解决方式。

    开始一个变种​

    假定 "widget-sdk" 是刚刚发布了主版本 3 的库，我们将其升级到版本 3, 但是我们想要维持与版本 2 的兼容性，我们可以在 package.json 中使用语义化版本来指定一个范围：

    libraries/my-controls/package.json

    {
      "name": "my-controls",
      "version": "1.0.0",
      "description": "An example library project",
      "license": "MIT",
      "main": "lib/index.js",
      "typings": "lib/index.d.ts",
      "scripts": {
        "build": "node_modules/.bin/my-build"
      },
      "dependencies": {
        "widget-sdk": "^2.3.4 || ^3.0.2"
      },
      "devDependencies": {
        "my-toolchain": "^1.0.0",
        "typescript": "^3.0.3"
      }
    }

    范围 "^2.3.4 || ^3.0.2" 表示我们的库可以接受 widget-sdk 2.x 版本（但不能旧于 2.3.4 版本）或者 3.x 版本（但是不能旧于 3.0.2 版本），当你执行 rush update 时，你可以得到最新的兼容版本。那么如何构建和测试与旧版本 2 的库？请设置一个安装变种！

    1. 定义你的安装变种 在 rush.json 配置文件中，我们添加了如下定义：

    *rush.json 摘录*

      "variants": [
        // {
        //   /**
        //    * 变种名.
        //    */
        //   "variantName": "example-variant",
        //
        //   /**
        //    * 描述信息
        //    */
        //   "description": "Build this repo using the previous release of the SDK"
        // }

        {
          "variantName": "old-widget-sdk",
          "description": "Build this repo using version 2 of the widget-sdk"
        }
      ],

    2, 拷贝配置文件。为了开始这个变量，首先要将 common/config/rush下的配置文件拷贝到变量目录 common/config/rush/variants/old-widget-sdk 下。目前支持三个配置文件（将来可能会添加更多）：

    • shrinkwrap.yaml, npm-shrinkwrap.json, 或者 yarn.lock, 由你的包管理器决定。
    • common-versions.json
    • pnpmfile.js, 如果你使用 PNPM.

    确保已经将拷贝的文件添加到 Git 中：

    $ git add .
    $ git commit -m "Creating a new variant"

    3. 重写变种的依赖版本。例如，我们将会将 widget-sdk 降级到使用 2.x 版本。这可以通过使用 Rush 的偏好版本功能实现。我们使用通配符，这样 rush update --full 仍然会抓取 minor/patch 版本：

    *common-versions.json 摘录*

      /**
       * 一个明确“偏好版本”的依赖包列表，“编号版本”通常用于保持间接依赖到特定版本，但是它通常可以是一个语义化版本范围（例如 "~1.2.3"）。
       * 同时他也会窄化任何（兼容的）语义化繁为。可以参考 Rush 文档来了解该功能的更多细节。
       */
      "preferredVersions": {

        /**
         * 当某些人请求 "^1.0.0" 是需要确保 "1.2.3" 在这个项目里可以正常工作，而不是最新版本。
         */
        // "some-library": "1.2.3"

        "widget-sdk": "^2.3.9"
      },

    注意，^2.3.9 满足 package.json 中指定的 SemVer 范围 ^2.3.4 || ^3.0.2.(如果不是这样，那么偏好版本将不会有任何效果。)

    1. 安装你的变种并测试。假设我们想要在变种中运行 rush update，来安装新的依赖版本：
    $ rush update --full --variant old-widget-sdk

    这会更新 common/config/rush/old-widget-sdk/shrinkwrap.yaml 文件，安装这些依赖到 common/temp/node_modules 下，同时在每个项目下链接这些依赖。rush install 命令同样支持 --variant 选项。当 CI 任务使用老版本的 widget-sdk 构建时，可以使用此命令。

    现在你可以构建和测试你的安装变种：

    $ rush rebuild

    ⏵ 如果你经常使用 --variant，你也可以使用 RUSH_PREVIEW_VERSION.

    5. 恢复原始状态。当你测试完变种后，你通过不带有 --variant 参数的 rush install 返回到原始状态。我们称其为“默认变种”，因为它与一个没有定义安装变种的仓库的默认行为相同：

    # 通过不带有 `--variant` 参数的 `rush install` 恢复原始状态：
    $ rush install

    提示：如果你忘记了安装变种是否被激活，你可以使用 common/temp/current-variant.json 文件来查看。如果你在文本编辑器中打开此文件，你应该看到一行如下：

    {
     "variant": "old-widget-sdk"
    }
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/npm_doppelgangers/index.html b/zh-cn/pages/advanced/npm_doppelgangers/index.html index 4e4fc97d..f0eccb77 100644 --- a/zh-cn/pages/advanced/npm_doppelgangers/index.html +++ b/zh-cn/pages/advanced/npm_doppelgangers/index.html @@ -6,13 +6,13 @@ NPM 分身 | Rush - +
    Rush StackShopBlogEvents

    NPM 分身

    首先建议先阅读 “幻影依赖” 一文，因为这篇文章是其后续。

    NPM 分身如何出现的​

    NPM doppelganger

    有时 node_modules 的数据结构会强制安装同一个包的两个相同版本的。真的吗？它是如何发生的？

    假设我们有项目 A, 如下：

    {
      "name": "library-a",
      "version": "1.0.0",
      "dependencies": {
        "library-b": "^1.0.0",
        "library-c": "^1.0.0",
        "library-d": "^1.0.0",
        "library-e": "^1.0.0"
      }
    }

    然后 B 和 C 都依赖于 F1:

    {
      "name": "library-b",
      "version": "1.0.0",
      "dependencies": {
        "library-f": "^1.0.0"
      }
    }
    {
      "name": "library-c",
      "version": "1.0.0",
      "dependencies": {
        "library-f": "^1.0.0"
      }
    }

    之后 D 和 E 都依赖 F2:

    {
      "name": "library-d",
      "version": "1.0.0",
      "dependencies": {
        "library-f": "^2.0.0"
      }
    }
    {
      "name": "library-e",
      "version": "1.0.0",
      "dependencies": {
        "library-f": "^2.0.0"
      }
    }

    node_modules 树可以把 F1 放在树的顶部来实现共享，但是需要把 F2 拷贝到子目录中：

    - library-a/
      - package.json
      - node_modules/
        - library-b/
          - package.json
        - library-c/
          - package.json
        - library-d/
          - package.json
          - node_modules/
            - library-f/
              - package.json  <-- library-f@2.0.0
        - library-e/
          - package.json
          - node_modules/
            - library-f/
              - package.json  <-- library-f@2.0.0
        - library-f/
          - package.json  <-- library-f@1.0.0

    另外一种方式是包管理器将 F2 放在顶部，之后拷贝 F1:

    - library-a/
      - package.json
      - node_modules/
        - library-b/
          - package.json
          - node_modules/
            - library-f/
              - package.json  <-- library-f@1.0.0
        - library-c/
          - package.json
          - node_modules/
            - library-f/
              - package.json  <-- library-f@1.0.0
        - library-d/
          - package.json
        - library-e/
          - package.json
        - library-f/
          - package.json  <-- library-f@2.0.0

    无论哪种方式，我们都只能在树中拷贝两个相同版本的 library-f, 我们将其称之为“分身”。其他语言上的包管理器不会遇到这个问题，它是 NPM 的 node_modules 树的特性，是必然的，是由其设计导致，无法避免。

    分身的结果​

    小项目内很少遇到分身，但是在大型的 monorepo 中很常见，这会导致一些问题。

    • 更慢的安装时间：如今磁盘空间非常宝贵，但是假设你有 20 个依赖于 F1 的库，这会导致 20 份拷贝。假设这里有一个安装脚本，它会下载和解压大型的压缩包（例如 PhantomJS），这会在每个分身中重复执行，最终显著影响你的安装时间。

    • 增大包体积：Web 项目经常使用诸如 webpack 等打包工具，它们会静态分析 require() 语句，并将其收集到一个单一的打包产物中。这些产物应该尽可能保持小，因为它会直接影响页面应用的加载时间，假设出现了不符合预期的分身（例如由于 npm install 操作导致的 node_modules 树重排），这会导致一个库拷贝了两份之后被嵌入到产物中，进而极大增加了包体积。

    • 非单一的：假设 library-f 暴露了一个缓存对象的 API, 其目的是想让库那所有的消费者共享一个单例，当两个不同的组件调用 require("library-f") 时，它们可能获取到两个不同的库，这意味着这里会有两个实例（也就是说，“全局”变量会从两个不同的闭包中获取）。这可能会导致一些难以调试的奇怪问题。

    • 多重类型：假设 library-f 是一个 TypeScript 库，那么编译器会遇到多个 *.d.ts 文件。例如，每个类的声明都会有两份拷贝，由于它们是两个分开的真实文件，导致不能被符号链接复用。通常而言，在 TypeScript 中，相同的类声明被视为是不可互换的，混合后会导致编译问题。TypeScript 2.x 引入了一种检测和比较重复的类声明的方法，但是它会引入额外的复杂度。其他的构建任务可能没有如此精明。

    • 语义上的分身：假设 F 有一个依赖 G, G 同样被其他库使用。在这棵树上，F1 的第一份拷贝将从 B 开始寻找 G , 第二个拷贝将从 C 开始寻找 G. 对于两个不同的起点而言，require() 算法可能寻找到不同的 G 版本。这意味着运行时两个 F1 的实例可能有一些不同。或者在编译阶段，如果 F 导出了 TypeScript 的类，该类继承自 G 中定义的基类，由于相同的类从相同包的相同版本到处，可能会导致非常有迷惑性的编译错误。

    • Rush 如何改善的： Rush 的符号链接策略会删除仓库内依赖为本地项目的分身。不幸的是，如果你使用 NPM 或 Yarn 作为包管理器，那么任何间接依赖都还存在分身。如果你选择 Rush 和 PNPM, 那么分身问题会得到了完全性的解决（因为 PNPM 的安装模型模拟了一个真正的有向无环图）。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/phantom_deps/index.html b/zh-cn/pages/advanced/phantom_deps/index.html index 36dfa525..1f1f8a47 100644 --- a/zh-cn/pages/advanced/phantom_deps/index.html +++ b/zh-cn/pages/advanced/phantom_deps/index.html @@ -6,13 +6,13 @@ 幻影依赖 | Rush - +
    Rush StackShopBlogEvents

    幻影依赖

    Rush 的文章中时不时提及“幻影”和“复制体”，你是否想更多了解 JavaScript 的包管理器是如何工作的？

    一些历史和理论​

    大家都知道软件包可以依赖其他的包，其生成的依赖图是一种有向无环图。不同于树状结构，有向无环图可以用菱形分支链接。例如，库 A 可能导入 B 和 C, 之后 B 和 C 被 D 引入, 这四个库中创建了一个菱形依赖。通常，编程语言的模块解析会沿着图的边向上查找，并且（在其他系统中）包本身被放在一个中央的存储库中，可以被多个项目共享。

    由于历史原因，NodeJS 和 NPM 使用了一个不同的方法来在磁盘上组织图的物理形式，NPM 使用库的副本来表示图的顶点，以及图的边被子目录所替代。但是树状的文件夹不能组成菱形，为了解决该问题，NodeJS 增加了一个特殊的解析规则，起作用是引入额外的边（指向所有父亲目录的直接子文件夹）。从计算机科学的视角来看，这套规则以两种方式轻松地改变了文件系统的树状结构：(1) 它可以表示一些（但不是所有）有向无环图；(2) 我们捕获了一些额外的边，它们不属于任何声明的包依赖。这些额外的边便是“幻影依赖”。

    NPM 中用到的方法与传统的包管理方式有很多不同点：

    • 每一个（根级）目录的 node_module 树来存储大量的库文件夹副本，甚至一个很小的 NodeJS 项目的文件夹下可能有超过 10,000 个文件。

    • 在 NPM 2.x 版本中，node_modules 文件树非常深，而且存在很多重复，这可以消除幻影依赖。NPM 3.x 的安装算法改成了将树扁平化，这消除了大量重复项，但代价是引入了幻影依赖（图上额外的边），在某些情况下这个新算法会选择一个更久版本的包（虽然依旧符合语义化规范）来消除包文件夹的重复。

    • 安装后的 node_modules 树并不唯一，有很多种可能来重新组织文件夹来使得其接近菱形，并没有独一无二的“标准化”排列。安装后的树依赖于你的包管理器使用了哪种算法，NPM 自身的算法甚至对你添加的包的次序有关。

    node_modules 树是一个奇特的数据结构，让我们关注三个可能造成麻烦的问题，这些问题可能会在大型项目和 monorepo 中导致问题，我们也会展示 Rush 如何改善这些 —— 解决这些问题是 Rush 创立的动机之一。

    幻影依赖​

    NPM phantom dependency

    当项目中使用了一个没有在 package.json 文件中定义的包时，幻影依赖便出现了。示例如下：

    my-library/package.json

    {
      "name": "my-library",
      "version": "1.0.0",
      "main": "lib/index.js",
      "dependencies": {
        "minimatch": "^3.0.4"
      },
      "devDependencies": {
        "rimraf": "^2.6.2"
      }
    }

    代码可能会长成下面的样子：

    my-library/lib/index.js

    var minimatch = require('minimatch');
    var expand = require('brace-expansion'); // ???
    var glob = require('glob'); // ???

    // (使用这些库的代码)

    等一下 —— 这有两个库 brace-expansion 和 glob 两个库并没在 package.json 文件中声明为依赖。那它们是如何运行的呢？结论是 brace-expansion 是 minimatch 的依赖，glob 是 rimraf 的依赖。安装时，NPM 会将 my-library/node_modules 下的文件夹铺平，由于 NodeJS 的 require() 函数不需要考虑 package.json 文件，所以它找到这些库。这也许有一些违反直觉，但是这看起来没有问题，也许这不是个 bug?

    不幸的是，项目中缺少声明的依赖最好被视作一个 bug, 它可能导致一些不符合预期错误：

    • 不兼容的版本：尽管我们库的 package.json 明确需要 minimatch 的版本为 3, 我们并没有声明 brace-expansion 的版本，语义化系统 会使得当 minimatch 的 API 没发生变动时，minimatch 的 PATCH 版本完美的兼容了 brace-expansion 的 MAJOR 版本。在实际开发 my-library 时，可能永远不会遇到这种情况，相反，当随后有人以相较于我们平日测试时更新（更旧）的版本约束方式来约束 node_modules 排列方式来安装了我们发布的库，这个人就会变成一个受害者。

    • 缺少依赖：库 glob 来自于 devDependencies 中，这意味着只有开发 my-library 的开发者才会安装这些库。对于其他人，require("glob") 将会因 glob 未安装而立即抛错。只要我们发布了 my-library, 就会立即听到这个反馈，对吧？并不是，实际情况中，由于某些原因（例如自身使用了 rimraf），绝大部分用户都有 glob 这个库，所以看起来可以运行。只有一小部分用户会遇到导入失败的问题，这使得它看起来像是一个难以重现的问题。

    Rush 如何解决问题的： Rush 的符号链接策略能确保每个项目下的 node_modules 可仅仅包含它直接的依赖。这会在构建阶段捕获到幻影依赖的问题。如果你使用 PNPM, 相同保护措施也会应用到所有间接依赖上（可以通过 pnpmfile.js 来解决任何“不良”的包）。

    幻影 node_modules 文件夹​

    假定我们有一个 monorepo, 有人在根目录下的 package.json 文件增加了以下内容：

    my-monorepo/package.json:

    {
      "name": "my-monorepo",
      "version": "0.0.0",
      "scripts": {
        "deploy-app": "node ./deploy-app.js"
      },
      "devDependencies": {
        "semver": "~5.6.0"
      }
    }

    这会允许人们执行 npm run deploy-app, 该脚本会被自动部署 monorepo 中的所有项目（不要再 Rush 中使用这种方式，请使用自定义指令）。注意，这个幻想的脚本需要使用 semver 这个库，所以它被添加到 devDependencies 列表中，在项目根目录中，开发者可以在执行 npm run deploy-app 之前执行 npm install.

    安装目录的结构如下：

    - my-monorepo/
      - package.json
      - node_modules/
        - semver/
        - ...
      - my-library/
        - package.json
        - lib/
          - index.js
        - node_modules/
          - brace-expansion
          - minimatch
          - ...

    NodeJS 的模块解析器会在父目录下寻找依赖，这意味着 my-library/lib/index.js 可以执行 require("semver") 并寻找到 semver 包，甚至它不会出现在 my-library/node_modules 下。这是一种更隐蔽的方式来捕获幻影依赖 —— 它甚至可以找到不在你的 Git 工作目录下的 node_modules 文件夹。

    Rush 如何解决问题的： rush install 指令可以扫描所有潜在的父目录并在发现 node_modules 中存在幻影依赖时发出警告。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/pinned_versions/index.html b/zh-cn/pages/advanced/pinned_versions/index.html index 7ca1611a..761b0536 100644 --- a/zh-cn/pages/advanced/pinned_versions/index.html +++ b/zh-cn/pages/advanced/pinned_versions/index.html @@ -6,13 +6,13 @@ pinned_versions | Rush - +
    Rush StackShopBlogEvents

    Redirecting...

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/preferred_versions/index.html b/zh-cn/pages/advanced/preferred_versions/index.html index 6be6cbe1..83b960b6 100644 --- a/zh-cn/pages/advanced/preferred_versions/index.html +++ b/zh-cn/pages/advanced/preferred_versions/index.html @@ -6,13 +6,13 @@ 优先版本 | Rush - +
    Rush StackShopBlogEvents

    优先版本

    背景​

    Rush 通过在公共文件夹下创建了一个虚假的 rush-common 项目来实现一次性安装，该项目引用了每个项目的。例如，假设 rush.json 内有两个项目 "project1" 和 "project2"。生成的文件可能如下：

    common/temp/package.json

    {
      "name": "rush-common",
      "description": "Temporary file generated by the Rush tool",
      "private": true,
      "version": "0.0.0",
      "dependencies": {
        "@rush-temp/project1": "file:./projects/project-1.tgz",
        "@rush-temp/project2": "file:./projects/project-2.tgz"
      }
    }

    包管理器认为每个以 "@rush-temp" 命名的项目都是 rush-common 项目的直接依赖。通常而言，NPM 会首先安装项目的直接依赖（在 node_modules 树的根目录），然后再下载间接依赖。但是，由于你的项目的直接依赖现在已经间接依赖 rush-common 项目了，所以 npm install 的行为可能有些不同。

    假如 project-1/package.json 如下：

    {
      "name": "project-1",
      "version": "1.0.0",
      "dependencies": {
        "library-a": "1.0.1",
        "library-b": "1.1.3"
      }
    }

    接着假设 library-a （来自于互联网）如下：

    {
      "name": "library-a",
      "version": "1.0.1",
      "dependencies": {
        "library-b": "^1.0.0"
      }
    }

    如果你在 project-1 下执行 npm install, 你会得到一个如下所示的 node_modules 文件夹，甚至如果 library-b@1.4.4 在 NPM 上有版本的话：

    node_modules/
      library-a/ (1.0.1)
      library-b/ (1.1.3)

    尽管 library-b@1.4.4 满足 "1.0.0" 的语义化版本，但是 NPM 不会下载它，因此 1.1.3（被 project-1 安装）已经满足它。

    但是 common/temp/package.json 并不能保证上述行为。相反，由于 project-2 的依赖，你可能会得到这样的结果：

    node_modules/
      project-1/
        library-b/ (1.1.3)
      library-a/ (1.0.1)
      library-b/ (1.4.4)

    这也是语义化版本的一个有效解决方案。当使用 Rush 和 NPM 的 peer dependencies 时，可能会出现相似的问题。

    优先的版本​

    为了控制上述影响，Rush 引入了“优先版本”的概念，这些依赖会被显式的添加到 common/temp/package.json 顶层。

    你可以通过配置文件 common-versions.json 来“固定”版本，例如：

    common/config/rush/common-versions.json

    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/common-versions.schema.json",
      "preferredVersions": {
        "css-loader": "1.2.3"
      }
    }

    这将会导致 css-loader 添加到 common/temp/package.json 中，如下所示：

    {
      "name": "rush-common",
      "description": "Temporary file generated by the Rush tool",
      "private": true,
      "version": "0.0.0",
      "dependencies": {
        "css-loader": "1.2.3",
        "@rush-temp/project1": "file:./projects/project-1.tgz",
        "@rush-temp/project2": "file:./projects/project-2.tgz"
      }
    }

    注意：如果你发布一个包，当你添加优先版本时候应当非常小心，因为这可能会产生一个与普通用户通过 NPM 安装你的库的不同结果。

    隐性的优先版本​

    默认情况下，Rush 会自动将你的所有项目的直接依赖添加到 common/temp/package.json 中。在上面的例子中，这些“隐性的优先版本”可能会像这样：

    common/temp/package.json

    {
      "name": "rush-common",
      "description": "Temporary file generated by the Rush tool",
      "private": true,
      "version": "0.0.0",
      "dependencies": {
        "css-loader": "1.2.3",  // <---- 明确制定的优先版本
        "library-a": "~1.0.0",  // <---- 隐形的优先版本
        "library-b": "1.1.3",   // <---- 隐形的优先版本
        "@rush-temp/project1": "file:./projects/project-1.tgz",
        "@rush-temp/project2": "file:./projects/project-2.tgz",
      }
    }

    对于某个依赖而言，除了在不同的项目中指定不同的版本范围外，Rush 会自动将所有的直接依赖添加到 common/temp/package.json 中。在上述示例中，Rush 不知道哪个版本应当被认为是隐性的优先。例如，如果 project1 和 project2 指定了不同的 library-b 版本，之后你可能需要使用 common-version.json 来解决问题。

    对于较老的包管理器，自动添加这个这些条目会减少间接依赖的重复。然而，隐性的优先版本可能会导致某些不兼容 peerDependencies 范围的依赖出现问题。如果你遇到了同级依赖而导致的安装错误，建议通过设定 [common/config/rush/common-version.json] 中的 implicitlyPreferredVersions 为 false 来禁用这个行为。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/rush_files_and_folders/index.html b/zh-cn/pages/advanced/rush_files_and_folders/index.html index 114d6523..16d3e390 100644 --- a/zh-cn/pages/advanced/rush_files_and_folders/index.html +++ b/zh-cn/pages/advanced/rush_files_and_folders/index.html @@ -6,13 +6,13 @@ Rush files and folders | Rush - +
    Rush StackShopBlogEvents

    Rush files and folders

    Every Rush monorepo has a standard folder structure that is created by rush init and validated by rush update.

    Configuration files​

    Folder pathWhat it does
    rush.jsonThe main configuration file for Rush
    common/config/rush/.npmrcIf you need custom settings for "npm install" (e.g. NPM registry mappings), put them in this file. Rush will copy this file into the common/temp/ folder.
    common/config/rush/.npmrc-publishUsed instead of .npmrc for publishing operations.
    common/config/artifactory.jsonConfiguration for Rush integration with JFrog Artifactory services.
    common/config/build-cache.jsonConfiguration for Rush's Build cache
    common/config/rush/command-line.jsonUsed to define custom commands.
    common/config/rush/common-versions.jsonUsed to specify versions that affect all projects in a repo.
    common/config/rush/deploy.jsonUsed to define profiles for the rush deploy command
    common/config/rush/experiments.jsonEnables experimental features of Rush
    common/config/rush/npm-shrinkwrap.jsonThe shrinkwrap file when your package manager is NPM. This is the common shrinkwrap file that applies to all projects in the Rush repo. For more information, see "What is this "shrinkwrap file" in the Everyday commands section.
    common/config/rush/rush-plugins.jsonSpecifies Rush plugins to be loaded for the monorepo.
    common/config/rush/pnpm-lock.yamlThe shrinkwrap file when your package manager is PNPM.
    common/config/rush/yarn.lockThe shrinkwrap file when your package manager is Yarn.
    common/config/rush/browser-approved-packages.jsonUsed by the approvedPackagesPolicy setting from rush.json
    common/config/rush/nonbrowser-approved-packages.jsonUsed by the approvedPackagesPolicy setting from rush.json
    common/config/rush/pnpm-config.jsonConfiguration specific to the PNPM package manager
    common/config/rush/version-policies.jsonDefines the rush version and rush publish workflows.

    Standard Rush folders​

    Folder pathWhat it does
    common/autoinstallers/...Autoinstaller projects are created under this folder
    common/changes/...Stores change files created by the rush change command and consumed by the rush version command.
    common/deploy/...The rush init-deploy creates deployment configurations under this folder.
    common/git-hooks/...Rush's git hook scripts are defined here
    common/pnpm-patches/...The rush-pnpm commit-patch command stores package patch files under this folder
    common/scripts/install-run-rush.jsCI bootstrap script for invoking rush. The rush update generates this file, which should be committed to Git. See Enabling CI builds for details.
    common/scripts/install-run-rush-pnpm.jsCI bootstrap script for invoking rush-pnpm.
    common/scripts/install-run-rushx.jsCI bootstrap script for invoking rushx.
    common/scripts/install-run.jsCI bootstrap script for invoking arbitrary NPM packages.

    Temporary files created by Rush​

    Folder pathWhat it does
    common/temp/build-cache/...Default storage location for Rush's Build cache
    common/temp/install-run/...Storage for the install-run.js and install-run-rush.js scripts. See Enabling CI builds.
    common/temp/node_modules/...The installed packages. This is a plain old npm install output, with no symlinks in this tree.
    common/temp/npm-cache/...A local NPM cache will be created here. Rush does not use the global NPM cache due to its concurrency problems.
    common/temp/npm-local/...If the NPM package manager is selected, this is a symlink to Rush's global install of the version specified in rush.json.
    common/temp/npm-tmp/...Temporary files created by NPM during installation.
    common/temp/patches/...The rush-pnpm patch command creates patch files under this temporary folder (which rush-pnpm commit-patch will copy to common/pnpm-patches)
    common/temp/pnpm-local/...If the PNPM package manager is selected, this is a symlink to Rush's global install of the version specified in rush.json.
    common/temp/pnpm-store/...If the PNPM package manager is selected, this is the default location of the PNPM store. (It can be redirected using the RUSH_PNPM_STORE_PATH environment variable.)
    common/temp/projects/...Synthetic projects referenced by common/temp/package.json.
    common/temp/rush-recycler/...Used to speed up recursive deletes.
    common/temp/telemetry/...Stores telemetry output saved by Rush when telemetryEnabled=true in rush.json
    common/temp/yarn-local/...If the Yarn package manager is selected, this is a symlink to Rush's global install of the version specified in rush.json.
    common/temp/last-install.flagDon't worry about this file. It tracks the timestamp of the last successful rush install.
    common/temp/package.jsonThe common package definition.
    common/temp/repo-state.jsonGenerated by the preventManualShrinkwrapChanges setting from pnpm-config.json
    common/temp/rush-link.jsonDon't worry about this file. It is created whenever you run rush link, and read by later commands such as "rush build".
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/advanced/watch_mode/index.html b/zh-cn/pages/advanced/watch_mode/index.html index ca939758..0d85accd 100644 --- a/zh-cn/pages/advanced/watch_mode/index.html +++ b/zh-cn/pages/advanced/watch_mode/index.html @@ -6,7 +6,7 @@ 使用监听模式 | Rush - + @@ -14,7 +14,7 @@
    Rush StackShopBlogEvents

    使用监听模式

    诸如 Webpack 和 Jest 等流行工具提供了“监听模式”功能：当任务完成后，工具选择文件系统来等待源代码发生变动，一旦监听到变动，任务队列会更新其输出。这加速开发，因为 (1) 一旦你保存文件就可以重新构建；(2) 由于进程没有停止，因此可以使用缓存。

    因为这些功能仅仅对单个项目有效，一旦在 monorepo 中开发，我们需要能够一次性监听多项目的监听模式。

    一个实验性的想法​

    假设我们的 monorepo 有如下项目：

    a sample monorepo

    上述图例中，圆圈表示本地项目，没有外部的 NPM 依赖。箭头 D 到 C 表明 D 依赖 C, 这意味着 C 必须在 D 构建前构建。

    假设你保存了对项目 B 的变动：

    rush build --impacted-by B

    对于多项目的“监听模式”，我们预期会发生如下事情：

    • B 应该被重新构建，因为它的文件被改变了；
    • 之后，C 应该被重新构建，因为它依赖于 B
    • 之后，D 应该被重新构建，因为它依赖于 C
    • 最后，Webpack dev server（预期是由 D 唤起的）刷新你的 web 浏览器，重新构建的 app

    如果通过 rush 来实现这个方案？假设项目内 B 和 C 都有如下的简单脚本：

    package.json

      . . .
      "scripts": {
        "build": "rm -Rf lib/ && tsc && jest"
      }
      . . .

    我们将尝试在一个无限循环中调用 rush build --to-except D:

    # 构建所有依赖于 D 的项目（但不包括 D 本身），并在无限循环中重复这个操作
    $ while true; do rush build --to-except D; done

    之后让它一直运行，我们在项目 D 中唤起 heft start（或者 webpack serve）：

    之后你会发现上述方案有一些问题：

    • rm -Rf lib/ 删除了符号链接文件；符号链接会迷惑 Webpack 的文件监听，所以你会看到很多报错提示说：找不到导入的文件。Webpack 不会从中恢复它们，因为当文件重新写入时，符号链接的文件不会更新。

    • 当监听时，jest 和 rm -Rf 步骤一般不重要。开发者的内部循环 编辑 -> 重新构建 -> 重新加载 比文件监听所需时间慢多了。

    这些问题可以通过创建一个特殊的简化脚本来解决，比如这样：

    package.json

      . . .
      "scripts": {
        "build": "rm -Rf lib/ && tsc && jest",
        "build:watch": "tsc"
      }
      . . .

    设置 "watchForChanges"（实验性）​

    Rush 的“文件监听” 基本思想是用 chokidar 来优化循环。下面是其用法：

    1. 在 command-line.json 中的添加一个自定义指令。继续上面的示例，我们的自定义指令将被命名为 "build:watch"。重要的设置是 "incremental" 和 "watchForChanges":

      common/config/rush/command-line.json

        . . .
        "commands": [
          {
            "name": "build:watch",
            "commandKind": "bulk",
            "summary": "Build projects and watch for changes",
            "description": "For details, see the article \"Using watch mode\" on the Rush website: https://rushjs.io/",

            // 使用增量构建（重要）
            "incremental": true,
            "enableParallelism": true,
            // 启用“监听模式”
            "watchForChanges": true
          },
        . . .

    2. 在每个项目的 package.json 下增加 "build:watch" 脚本（PR #2298 的目标是简化这一步骤，来使得项目内的 "build:watch" 与 "build" 相等，最终可以被合并到一个共享的 rig 包中。

    如果你使用 Heft, 你的脚本将会像这样：

    package.json

      . . .
      "scripts": {
        "build": "heft build --clean",
        "build:watch": "heft build"
      }
      . . .
    1. 参考选择部分项目一文选中 D 的所有依赖，但不包含 D 本身：
    # 构建所有依赖于 D 的项目（但不包括 D 本身），并在无限循环中重复这个操作
    $ rush build:watch --to-except D
    1. 随后，开一个项目目录中开启开发服务器：
    # 在项目 D 的目录下开启 Webpack 的开发服务器
    # （这是示例中的 web 应用）
    $ cd apps/D
    $ heft start # 或者用自己的 "npm run start"
    1. 在某些情况下，为了实现更快的监听，--changed-projects-only 命令可以与 "watchForChanges" 结合使用。增量构建一文详细说明了他是如何工作的，以及它是否适合使用。

    “实验性” "watchForChanges" 的功能还在其初期阶段。有意见或建议请联系我们！ GitHub issue #1202 跟踪更多工作项，以及 William Bernting 的开发计划。

    社区解决方法​

    Rush 的社区分享了一些有用的替代方案：

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/best_practices/change_logs/index.html b/zh-cn/pages/best_practices/change_logs/index.html index 722ed94b..5bd13a37 100644 --- a/zh-cn/pages/best_practices/change_logs/index.html +++ b/zh-cn/pages/best_practices/change_logs/index.html @@ -6,13 +6,13 @@ 编写变更日志 | Rush - +
    Rush StackShopBlogEvents

    编写变更日志

    当发布一个 NPM 包时，最普遍的做法是带上一个 CHANGELOG.md 文件，该文件记录了问题修复、新功能、功能变动或移除。Rush 中可以使用 rush change 来自动完成这些功能。当你准备提交 PR 时，并将变动 commit 到相应的分支上后，需要执行这个命令，它会分析当前分支中的变动，并在必要时让你对其变动进行描述。

    如何组织你的描述是很重要的：不能太具体，也不能太复杂，不能暴露隐私，同时要让描述信息更友好。我们建议在可读性上做文章，问问你自己：

    • “此次变更是否与第三方开发者有关？”
    • “是否存在破坏性变更？”
    • “是否修复了某个让人不悦的 bug? ”
    • “是否有需要他人适用的新功能？”

    在一些工作流中，发布前需要有人来编辑变更日志，然而应该是每个人都尽其最大努力来保证日志内容的清晰和专业。

    最佳实践​

    • 使用 简单的现代时 和 命令式语气。

    • 从一个不熟悉项目细节的外部人员的角度来写。

    • 尽量描述场景（例如：“搜索现在支持通配符”），而不是代码的变更（例如：“在 SearchHelper 类中增加正则表达式的支持”）

    • 使用动词开头，推荐使用：

      • Add - 当你引入或暴露一个新功能、属性、类、UI 等。
      • Remove - 当你完全移除了不会再被使用的东西。
      • Deprecate - 当你计划移除某些东西，但是目前仍然可用。
      • Fix an issue with/where... - 当你修复一个 bug.
      • Improve - 改进了一个已有的东西。
      • Update - 更新了某项东西，但不一定使其更好。
      • Upgrade - 升级了依赖包的版本。
      • Initial/Beta release of ... - 发布了一个新功能。

    • 别用 bug 一词，转而使用 issue.

    • 不要使用缩写，除非是被广泛认可的（例如："HTTP"）

    • 使用正确的拼写和语法。CHANGELOG.md 是发布文档的一部分。

    • 当涉及到公共 API 变化时，使用 () 后缀来指出函数名，例如 setSomethingOnWebpart().

    • 当涉及到公共 API 变化时，使用 (` `) 来包裹类和其属性名。

    • 当描述版本升级时，表明旧版本和新版本，例如："Upgraded widget-library from 1.0.2 to 2.0.1".

    • 当修复一个 Github issue 后，考虑在括号中添加 issue URL.

    • 不要在句尾添加句号，除非你有两个以上句子。

    变更日志消息示例​

    这里有一些用于编写 rush change 变更日志的示例：

    • Add "buttonColor" to the button manifest schema
    • Remove support for older mobile web browsers as described in the README.md
    • Deprecate the doSomething() API function. Use doSomethingBetter() instead.
    • Fix an issue where "ExampleWidget" API did not handle dates correctly
    • Improve the diagnostic logging when running in advanced mode
    • Upgrade from React 15 to React 16
    • Initial release of the flexible panels feature
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush-pnpm/index.html b/zh-cn/pages/commands/rush-pnpm/index.html index 3c94c070..52f3de6a 100644 --- a/zh-cn/pages/commands/rush-pnpm/index.html +++ b/zh-cn/pages/commands/rush-pnpm/index.html @@ -6,7 +6,7 @@ rush-pnpm | Rush - + @@ -16,7 +16,7 @@ 优先版本 和更快的增量安装。

    因此，如果你在 Rush 仓库中直接调用 pnpm 命令，它可能会因为找不到 pnpm-workspace.yaml 文件失败。 一些操作可能会由于与 Rush 的增强功能不兼容而发生故障。

    为了避免这些问题，在你的 Rush 仓库中，无论何时都应该使用 rush-pnpm 来代替 pnpm 命令。 @microsoft/rush 附带了 rush-pnpm 二进制文件用于替代品 pnpm 命令。它提供了以下功能：

    • 设置正确的上下文/环境，以便 PNPM 命令能够正常工作
    • 报告已知不兼容操作的错误
    • 报告潜在不兼容操作的警告
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_add/index.html b/zh-cn/pages/commands/rush_add/index.html index a1044a61..91be7303 100644 --- a/zh-cn/pages/commands/rush_add/index.html +++ b/zh-cn/pages/commands/rush_add/index.html @@ -6,13 +6,13 @@ rush add | Rush - +
    Rush StackShopBlogEvents

    rush add

    用法：rush add [-h] -p PACKAGE [--exact] [--caret] [--dev] [-m] [-s] [--all]

    在当前项目下（由当前的工作目录决定）添加指定的包作为依赖，然后运行"rush update"。
    如果版本没有指定，则会自动检测版本（通常是最新的版本或者是不会破坏 "ensureConsistentVersions" 策略的版本）
    如果指定了版本范围（或者工作区范围），则会使用范围内的最新版本。
    如果没有使用 "--exact" 或 "--carte" 参数，则会自动在版本号前面加上波浪号。
    如果使用 "--make-consistent" 参数，则可以更新所有包的 package.json 文件，使其使用相同的依赖。

    可选参数：
      -h, --help            展示帮助信息并退出。
      -p PACKAGE, --package PACKAGE
                            (必须) 应当被添加到依赖的包名。可以在 "@" 符号后添加语义化版本。
                            警告： 特征字符串经常被 shell 解释，所以建议使用引号。例如，书
                            写 "rush add --package "example@^1.2.3"", 而不是
                            "rush add --package example@^1.2.3".
      --exact               一旦使用该参数，添加到 package.json 那的版本将是一个精确
                            版本（例如，没有 ~ 或 ^ 标记）。
      --caret               一旦使用该参数，那么添加到 package.json 中的版本将带有
                            ^ 标记。
      --dev                 一旦使用该参数，那么添加到库将添加到 package.json 中的
                            "devDependencies" 字段。
      -m, --make-consistent
                            一旦使用该参数，使用该库的其他项目将会在 package.json 文件中
                            将该依赖成相同的版本。
      -s, --skip-update     一旦使用该参数，当更新完 package.json 文件后将不会执行
                            "rush update".
      --all                 一旦使用该参数，该依赖将被添加到所有项目中。
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_build/index.html b/zh-cn/pages/commands/rush_build/index.html index aa6dc802..218c5341 100644 --- a/zh-cn/pages/commands/rush_build/index.html +++ b/zh-cn/pages/commands/rush_build/index.html @@ -6,13 +6,13 @@ rush build | Rush - +
    Rush StackShopBlogEvents

    rush build

    用法：rush build [-h] [-p COUNT] [-t PROJECT] [-T PROJECT] [-f PROJECT]
                      [-o PROJECT] [-i PROJECT] [-I PROJECT]
                      [--to-version-policy VERSION_POLICY_NAME]
                      [--from-version-policy VERSION_POLICY_NAME] [-v] [-c]
                      [--ignore-hooks]

    除了 "rush build" 可以增量构建外，刚命令与 "rush rebuild" 相似。换句话说，Rush build
    只会构建自上次成功构建后发生的代码。它需要 Git 工作树来进行分析，只关心被 Git 跟踪的源文件
    和在其项目下的文件（该算法的更多细节可以参考 "package-deps-hash" 包的文档）。增量构建状态
    会保存在每个项目中的 ".rush/temp" 文件夹，该文件夹没被 Git 记录。构建指令被 "package-deps_build.json"
    文件下的“参数”字段记录；当参数发生变化时（例如有或者没有 "--production" 参数），会重新执行
    全量构建。

    可选参数：
      -h, --help            展示帮助信息并退出。
      -p COUNT, --parallelism COUNT
                            定义并行构建的最大并发数，COUNT 参数应该是一个正整数并且其最大
                            值等于 CPU 核数。如果该参数为空，那么默认值会依赖操作系统和 CPU
                            的核数决定。参数可以通过 RUSH_PARALLELISM 环境变量指定。
      -t PROJECT, --to PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--to" 参数会包含项目和其依赖的项目。"." 是当前工作目录
                            的简写。更多信息可以参考“选中部分项目”一文。
      -T PROJECT, --to-except PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--to-except" 参数会包含项目的依赖项目，而不包括项目
                            本身。"." 是当前工程目录的简写。更多信息可以参考“选中部分项目”
                            一文。
      -f PROJECT, --from PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--from" 参数会包含项目和所有依赖它的项目，再加上这个集
                            合的依赖。"." 是当前工程目录的简写。更多信息可以参考“选中部分
                            项目”一文。
      -o PROJECT, --only PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--only" 参数会选中指定的项目，而其依赖不会被添加。"." 是
                            当前目录的简写。注意这个参数是“不安全”的，因为它可能将某些依赖排除
                            在外。更多信息可以参考“选中部分项目”一文。
      -i PROJECT, --impacted-by PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--impacted-by" 参数会包含该项目和所有依赖该项目的项目
                            （因此可能会造成破坏性变动）。"." 是当前目录的简写。注意该参数是
                            “不安全的”, 因为它可能将某些依赖排除在外。更多信息可以参考“选中
                            部分项目”一文。
      -I PROJECT, --impacted-by-except PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--impacted-by-expect" 参数会包含所有依赖该项目的项目，
                            而不包含本身。"." 是当前目录的简写。注意该参数是“不安全的”，
                            因为它可能将某些依赖排除在外。更多信息可以参考“选中部分项目”一文。
      --to-version-policy VERSION_POLICY_NAME
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            "--to-version-policy" 参数会给每个属于 VERSION_POLICY_NAME
                            的项目指定 "--to", 更多信息可以参考“选中部分项目”一文。
      --from-version-policy VERSION_POLICY_NAME
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            "--from-version-policy" 参数会给每个属于 VERSION_POLICY_NAME
                            的项目指定 "--from", 更多信息可以参考“选中部分项目”一文。
      -v, --verbose         构建期间展示更多信息，而不是仅仅展示总结性状态。
      -c, --changed-projects-only
                            正常情况增量构建逻辑会重新构建所有直接或间接改变的项目。
                            指定 "--changed-projects-only" 将会忽略依赖项目，而仅构建
                            文件发生变化的项目。注意，该参数是“不安全”的，需要开发者确保忽略
                            的项目可以被忽略。
      --ignore-hooks        跳过定义在 "rush.jon" 下 "eventHooks" 脚本的。确保你知道
                            跳过了哪些。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_change/index.html b/zh-cn/pages/commands/rush_change/index.html index ecc65cdf..f9bb22b7 100644 --- a/zh-cn/pages/commands/rush_change/index.html +++ b/zh-cn/pages/commands/rush_change/index.html @@ -6,13 +6,13 @@ rush change | Rush - +
    Rush StackShopBlogEvents

    rush change

    用法: rush change [-h] [-v] [--no-fetch] [-b BRANCH] [--overwrite]
                       [--email EMAIL] [--bulk] [--message MESSAGE]
                       [--bump-type {major,minor,patch,none}]

    通过询问一系列的问题之后在公共文件夹中生成 <branchname>-<timestamp>.json 文件。当变更版
    本号时通过 `publish` 命令来消费这些文件。注意这些变更日志最终会被放到每个项目的 changelog.md
    文件中。变更的类型有：MAJOR - 存在破坏性变动并且向后不兼容，例如重命名一个公共类，在公共 API 中
    添加或删除一个必选参数，或者重命名一个导出的变量或函数；MINOR - 存在向后兼容（但不向前兼容）的变
    化，例如增加一个公共 API 或者在公共 API 中增加一个可选参数；PATCH - 存在向前兼容、向后兼容的改
    动，例如修改一个私有 API 或者修复修复某个 API 的工作逻辑。 HOTREX（实验性的） - 在某个存在的版
    本上进行热修复。当增加一个热修复时，其他的变化不会增加版本号，可以通过在 rush.json 中设定参数
    'hotfixChangeEnabled' 来开启。


    可选参数：
      -h, --help            展示帮助信息并退出
      -v, --verify          验证是否生成了有效的变更文件
      --no-fetch            在执行 "git diff" 检测之前，跳过获取基准分支
      -b BRANCH, --target-branch BRANCH
                            一旦指定该参数，会比较当前分支和目标分支的差异。如果没有指定该
                            参数，则默认比较 "main" 分支
      --overwrite           如果某个变更日志存在，将在没有提示的情况下对该文件进行覆盖（当
                            --bulk 参数存在时会导致失败）
      --email EMAIL         邮箱地址用于变更文件中和，如果没有提供该参数，那么会在交互模式下
                            检测邮箱。
      --bulk                一旦指定该参数，那么会将相同的变更信息和变更类型应用到所有项目。
                            一旦使用该参数，同时需要指定 --message 和 --bump-type 参数。
      --message MESSAGE     当指定 --bulk 参数时，该参数会适用于所有变化的项目
      --bump-type {major,minor,patch,none}
                            当指定 --bulk 参数时，变更类型会适用于所有变化的项目

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_check/index.html b/zh-cn/pages/commands/rush_check/index.html index f4eec39f..80340f36 100644 --- a/zh-cn/pages/commands/rush_check/index.html +++ b/zh-cn/pages/commands/rush_check/index.html @@ -6,13 +6,13 @@ rush check | Rush - +
    Rush StackShopBlogEvents

    rush check

    用法： rush check [-h] [--variant VARIANT] [--json]

    检查每个项目的 package.json 文件来确保仓库内所有的依赖都有相同的版本。

    可选参数：
      -h, --help         展示帮助信息并退出
      --variant VARIANT  Rush 命令通过使用安装配置文件变量该参数可以通过 RUSH_VARIANT 环
                         境变量来指定。
      --json             该参数指定后会被输出 JSON 格式的文件
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_deploy/index.html b/zh-cn/pages/commands/rush_deploy/index.html index 6a2cca09..48ab31d4 100644 --- a/zh-cn/pages/commands/rush_deploy/index.html +++ b/zh-cn/pages/commands/rush_deploy/index.html @@ -6,13 +6,13 @@ rush deploy | Rush - +
    Rush StackShopBlogEvents

    rush deploy

    用法： rush deploy [-h] [-p PROJECT_NAME] [-s SCENARIO_NAME] [--overwrite]
                       [-t PATH] [--create-archive ARCHIVE_PATH]

    仓库构建完成后，"rush deploy" 可以将 Rush 仓库内的某些项目和依赖部署到指定的目录下，该目录可
    被上传到生产服务器上。"rush deploy" 通过 "rush init-deploy" 生成的配置文件来指定该行为。

    可选参数：
      -h, --help            展示帮助信息并退出。
      -p PROJECT_NAME, --project PROJECT_NAME
                            指定需要被部署的 Rush 项目名，它必须是部署配置文件下的
                            "deploymentProjectNames" 设定。
      -s SCENARIO_NAME, --scenario SCENARIO_NAME
                            默认情况下，部署配置在 "common/config/rush/deploy.json"
                            中指定。你可以使用 "--scenario" 来指定一个可选名，该名必须小
                            写且以破折号分割。例如，如果 SCENARIO_NAME 是 "web"，之后
                            配置文件应该是 "common/config/rush/deploy-web.json".
      --overwrite           默认情况下，如果目标目录为空则构建失败。当指定该参数后，会递归
                            的删除目标目录下存在的内容。
      -t PATH, --target-folder PATH
                            默认情况下，文件部署在 Rush 仓库内的 "common/deploy" 目录
                            下。可以使用该参数来指定不同的位置。警告：当与 "--overwrite"
                            结合使用时需要小心。该参数可以通过 RUSH_DEPLOY_TARGET_FOLDER
                            环境变量来指定。
      --create-archive ARCHIVE_PATH
                            一旦使用该参数，那么构建完成后，"rush deploy" 会创建一个目标
                            目录的压缩包。 新创建的压缩包被放到相对于目标文件的制定目录上，
                            支持的文件扩展名：.zip

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_init-autoinstaller/index.html b/zh-cn/pages/commands/rush_init-autoinstaller/index.html index bcfa31b3..aad2f021 100644 --- a/zh-cn/pages/commands/rush_init-autoinstaller/index.html +++ b/zh-cn/pages/commands/rush_init-autoinstaller/index.html @@ -6,13 +6,13 @@ rush init-autoinstaller | Rush - +
    Rush StackShopBlogEvents

    rush init-autoinstaller

    用法： rush init-autoinstaller [-h] --name AUTOINSTALLER_NAME

    使用该指令可以初始化一个新的自动安装文件夹。自动安装提供了一种管理一系列相关依赖的方式，
    这些依赖通过被用于 "rush install" 之外的场景。可以查看 common-line.json 文档中的
    示例。

    可选参数：
      -h, --help            展示帮助信息并推出。
      --name AUTOINSTALLER_NAME
                            指定自动安装目录的目录名，该目录名必须符合 NPM 包的命名规
                            则。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_init-deploy/index.html b/zh-cn/pages/commands/rush_init-deploy/index.html index 98e27782..512cbaff 100644 --- a/zh-cn/pages/commands/rush_init-deploy/index.html +++ b/zh-cn/pages/commands/rush_init-deploy/index.html @@ -6,13 +6,13 @@ rush init-deploy | Rush - +
    Rush StackShopBlogEvents

    rush init-deploy

    用法： rush init-deploy [-h] -p PROJECT_NAME [-s SCENARIO]

    该命令可以生成用于 "rush deploy" 的配置文件。默认名为 common/config/rush/deploy.json.
    然而，如果你需要管理多个不同配置的部署环境，你可以使用 '--scenario" 来创建额外的配置文件。

    可选参数：
      -h, --help            展示帮助信息并退出。
      -p PROJECT_NAME, --project PROJECT_NAME
                            指定该场景下需要被部署的项目名。它将添加到 "deploymentProjectNames"
                            配置中。
      -s SCENARIO, --scenario SCENARIO
                            默认情况下，部署配置将被写到 "common/config/rush/deploy.json"
                            中，你可以使用 "--scenario" 来指定一个可选名，该名字必须
                            小写且使用破折号分开，例如，如果名字是 "web"，那么配置文件
                            应该是 "common/config/rush/deploy-web.json".

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_init/index.html b/zh-cn/pages/commands/rush_init/index.html index 53dbf25f..b56cadb9 100644 --- a/zh-cn/pages/commands/rush_init/index.html +++ b/zh-cn/pages/commands/rush_init/index.html @@ -6,13 +6,13 @@ rush init | Rush - +
    Rush StackShopBlogEvents

    rush init

    用法： rush init [-h] [--overwrite-existing] [--rush-example-repo]

    当在一个空文件夹下调用该命令时，它会提供一系列配置模版来使用 Rush 管理项目。

    可选参数：
      -h, --help            展示帮助信息并退出。
      --overwrite-existing  默认情况下，"rush init" 不会覆盖已经存在的配置文件。指定该
                            参数后会重写。当你将仓库的 Rush 升级到一个新版本时，它十分有
                            用。警告：小心使用！
      --rush-example-repo   当拷贝模版配置文件时，"rush-example" 的 GitHub 仓库使用了
                            这些不包含注释的片段，"rush-example" 是一个说明 Rush 诸多
                            特性的 monorepo 仓库。该参数主要用于维护该示例。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_install/index.html b/zh-cn/pages/commands/rush_install/index.html index a4e577e7..533b1d98 100644 --- a/zh-cn/pages/commands/rush_install/index.html +++ b/zh-cn/pages/commands/rush_install/index.html @@ -6,13 +6,13 @@ rush install | Rush - +
    Rush StackShopBlogEvents

    rush install

    用法： rush install [-h] [-p] [--bypass-policy] [--no-link]
                        [--network-concurrency COUNT] [--debug-package-manager]
                        [--max-install-attempts NUMBER] [--ignore-hooks]
                        [--variant VARIANT] [-t PROJECT] [-T PROJECT] [-f PROJECT]
                        [-o PROJECT] [-i PROJECT] [-I PROJECT]
                        [--to-version-policy VERSION_POLICY_NAME]
                        [--from-version-policy VERSION_POLICY_NAME]

    "rush install" 命令会基于 "rush update" 创建/更新的 shrinkwrap 文件来给仓库内的所有项
    目安装依赖（"shrinkwrap" 文件存储了仓库内项目的所有依赖和版本关系）。如果 shrinkwrap 文件
    缺失或过时后（例如，由于项目的 package.json 文件改变），"rush install" 命令会执行失败，
    并告诉你需要执行 "rush update" 来替代。其主要特性是只读：持续集成中应该使用 "rush install"
    而不是 "rush update" 来获取那些忘记在 commit 中更新 shrinkwrap 的开发者。如果想要避免
    shrinkwrap 文件偶然更新，那么这些谨慎的人可以使用 "rush install"

    可选参数：
      -h, --help            展示帮助信息并推出。
      -p, --purge           开始执行之前执行 "rush purge".
      --bypass-policy       强制覆盖 rush.json 中约定的 "gitPolicy" 规定。
      --no-link             一旦指定该参数，那么当安装完成后项目不会执行符号连接。你需要手动
                            执行 "rush link", 当想要独立的报告每个阶段，或者在两个阶段之
                            间进行额外的操作时，该参数十分有用。当使用 workspaces 时，不支
                            持该参数。
      --network-concurrency COUNT
                            一旦指定该参数，将会限制最大的并发网络请求数。当网络出现问题时，
                            该参数十分有用。
      --debug-package-manager
                            开启包管理器的详细日志。当使用该参数时，你可能想要 Rush 输出到
                            一个文件中。
      --max-install-attempts NUMBER
                            覆盖默认的尝试安装的次数，默认值为 3.
      --ignore-hooks        跳过执行定义在 rush.json 中的 "eventHooks" 脚本。你应该知道
                            自己跳过了什么。
      --variant VARIANT     通过一个安装配置变量来执行 Rush 命令。该参数可以通过环境变量
                            RUSH_VARIANT 来指定。
      -t PROJECT, --to PROJECT
                            默认情况下将会处理仓库内的所有项目，可以通过该参数来选中部分项目。
                            每个 "--to" 参数会包含项目和其依赖的项目。"." 是当前工作目录的
                            简写。 更多信息可以参考“选中部分项目”一文。
      -T PROJECT, --to-except PROJECT
                            默认情况下将会处理仓库内的所有项目，可以通过该参数来选中部分项目。
                            每个 "--to-except" 会包含项目的依赖，而不包括项目本身。"." 是
                            当前工作目录的简写。 更多信息可以参考“选中部分项目”一文。
      -f PROJECT, --from PROJECT
                            默认情况下将会处理仓库内的所有项目，可以通过该参数来选中部分项目。
                            每个 "--from" 参数将会包含该项目和所有依赖它的项目，再加上这个
                            集合的依赖。"." 是当前工作目录的简写。 更多信息可以参考“选中部
                            分项目”一文。
      -o PROJECT, --only PROJECT
                            默认情况下将会处理仓库内的所有项目，可以通过该参数来选中部分项目。
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--only" 参数会选中指定的项目，而其依赖不会被添加。"." 是
                            当前目录的简写。注意这个参数是“不安全”的，因为它可能将某些依赖排除
                            在外。更多信息可以参考“选中部分项目”一文。
      -i PROJECT, --impacted-by PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--impacted-by" 参数会包含该项目和所有依赖该项目的项目
                            （因此可能会造成破坏性变动）。"." 是当前目录的简写。注意该参数是
                            “不安全的”, 因为它可能将某些依赖排除在外。更多信息可以参考“选中
                            部分项目”一文。
      -I PROJECT, --impacted-by-except PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--impacted-by-expect" 参数会包含所有依赖该项目的项目，
                            而不包含本身。"." 是当前目录的简写。注意该参数是“不安全的”，
                            因为它可能将某些依赖排除在外。更多信息可以参考“选中部分项目”一文。
      --to-version-policy VERSION_POLICY_NAME
                           正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            "--to-version-policy" 参数会给每个属于 VERSION_POLICY_NAME
                            的项目指定 "--to", 更多信息可以参考“选中部分项目”一文。
      --from-version-policy VERSION_POLICY_NAME
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            "--from-version-policy" 参数会给每个属于 VERSION_POLICY_NAME
                            的项目指定 "--from", 更多信息可以参考“选中部分项目”一文。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_link/index.html b/zh-cn/pages/commands/rush_link/index.html index b01e5305..67f81e78 100644 --- a/zh-cn/pages/commands/rush_link/index.html +++ b/zh-cn/pages/commands/rush_link/index.html @@ -6,13 +6,13 @@ rush link | Rush - +
    Rush StackShopBlogEvents

    rush link

    用法： rush link [-h] [-f]

    给所有项目的 node_modules 创建符号连接，通常情况下该操作将会在 "rush install" 或
    "rush update" 后自动执行。你可以在因某些原因而执行 "rush unlink" 后，或者给 "rush
    install" 和 "rush update" 中添加 "--no-link" 参数后使用 "rush link".

    可选参数：
      -h, --help   展示帮助信息并退出。
      -f, --force  删除并重新创建所有链接，甚至文件系统看起来似乎不需要重新创建。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_list/index.html b/zh-cn/pages/commands/rush_list/index.html index f026df32..2128f41b 100644 --- a/zh-cn/pages/commands/rush_list/index.html +++ b/zh-cn/pages/commands/rush_list/index.html @@ -6,13 +6,13 @@ rush list | Rush - +
    Rush StackShopBlogEvents

    rush list

    用法： rush list [-h] [-v] [-p] [--full-path] [--json] [-t PROJECT]
                     [-T PROJECT] [-f PROJECT] [-o PROJECT] [-i PROJECT]
                     [-I PROJECT] [--to-version-policy VERSION_POLICY_NAME]
                     [--from-version-policy VERSION_POLICY_NAME]

    对于记录在 rush 配置文件中的项目，该命令可以列举包名，可选列出版本(--version)和路径(--path)或者完整路径(--full-path).

    可选参数：
      -h, --help            展示帮助信息退出
      -v, --version         一旦指定该参数，则项目版本会在项目名的另外一列内展示。
      -p, --path            一旦指定该参数，则项目路径会在项目名的另外一列内展示。
      --full-path           一旦指定该参数，则项目的完整路径会在项目名的另外一列内展示。
      --json                一旦指定该参数，则以 JSON 的格式输出。
      -t PROJECT, --to PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--to" 参数会包含项目和其依赖的项目。"." 是当前工作目录
                            的简写。更多信息可以参考“选中部分项目”一文。
      -T PROJECT, --to-except PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--to-except" 参数会包含项目的依赖项目，而不包括项目
                            本身。"." 是当前工程目录的简写。更多信息可以参考“选中部分项目”
                            一文。
      -f PROJECT, --from PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--from" 参数会包含项目和所有依赖它的项目，再加上这个集
                            合的依赖。"." 是当前工程目录的简写。更多信息可以参考“选中部分
                            项目”一文。
      -o PROJECT, --only PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--only" 参数会选中指定的项目，而其依赖不会被添加。"." 是
                            当前目录的简写。注意这个参数是“不安全”的，因为它可能将某些依赖排除
                            在外。更多信息可以参考“选中部分项目”一文。
      -i PROJECT, --impacted-by PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--impacted-by" 参数会包含该项目和所有依赖该项目的项目
                            （因此可能会造成破坏性变动）。"." 是当前目录的简写。注意该参数是
                            “不安全的”, 因为它可能将某些依赖排除在外。更多信息可以参考“选中
                            部分项目”一文。
      -I PROJECT, --impacted-by-except PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--impacted-by-expect" 参数会包含所有依赖该项目的项目，
                            而不包含本身。"." 是当前目录的简写。注意该参数是“不安全的”，
                            因为它可能将某些依赖排除在外。更多信息可以参考“选中部分项目”一文。
      --to-version-policy VERSION_POLICY_NAME
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            "--to-version-policy" 参数会给每个属于 VERSION_POLICY_NAME
                            的项目指定 "--to", 更多信息可以参考“选中部分项目”一文。
      --from-version-policy VERSION_POLICY_NAME
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            "--from-version-policy" 参数会给每个属于 VERSION_POLICY_NAME
                            的项目指定 "--from", 更多信息可以参考“选中部分项目”一文。
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_publish/index.html b/zh-cn/pages/commands/rush_publish/index.html index 78e10129..bb5b1348 100644 --- a/zh-cn/pages/commands/rush_publish/index.html +++ b/zh-cn/pages/commands/rush_publish/index.html @@ -6,13 +6,13 @@ rush publish | Rush - +
    Rush StackShopBlogEvents

    rush publish

    用法： rush publish [-h] [-a] [-b BRANCH] [-p] [--add-commit-details]
                        [--regenerate-changelogs] [-r REGISTRY] [-n TOKEN]
                        [-t TAG] [--set-access-level {public,restricted}] [--pack]
                        [--release-folder FOLDER] [--include-all]
                        [--version-policy POLICY] [--prerelease-name NAME]
                        [--partial-prerelease] [--suffix SUFFIX] [--force]
                        [--apply-git-tags-on-pack] [-c COMMIT_ID]

    读取并处理由 "rush change" 生成的发布更改请求。默认情况下，这是一个只读操作，会在控制台
    输出执行的操作。为了将变更日志提交并发布包，必须使用 --commit 参数，或者 --publish 参数。

    可选参数
      -h, --help            展示帮助信息并退出
      -a, --apply           一旦指定该参数，则变更请求会被应用到 package.json 文件中。
      -b BRANCH, --target-branch BRANCH
                            一旦指定该参数，将会把变更和删除变更的行为提交并合并到指定分
                            支上。
      -p, --publish         一旦指定该参数，则会将变更发布到 npm 上。
      --add-commit-details  在每次变更中把提交作者和哈希值都添加到 changelog.json 文
                            件中。
      --regenerate-changelogs
                            基于当前的 JSON 内容重新生成所有 changelog 文件。
      -r REGISTRY, --registry REGISTRY
                            指定发布的 NPM 源。一旦该参数指定，那么它会组织当前的提交不
                            带标签。
      -n TOKEN, --npm-auth-token TOKEN
                            （废弃） 发布时使用认证令牌。该参数已被废弃，因为命令行参数
                            可能被其他无关的进程读取。相反，更安全的做法是通过环境变量传
                            递该口令，之后从 common/config/rush/.npmrc-publish 文
                            件中读取。
      -t TAG, --tag TAG     传递给 npm 的标签参数。NPM 默认使用 'latest' 标签，即使是
                            当前发布的版本比最近发布的版本更低，所以，对于更旧的版本发布
                            工作流而言，提供一个标签是很重要的。当存在热更新时，该参数会
                            被默认设定为 'hotfix'.
      --set-access-level {public,restricted}
                            默认情况下，当 Rush 执行 "npm publish" 时，它将发布所有访
                            问级别是 "restricted" 的 scope 包。访问级别是 "public"
                            的 scope 包可以在刚开始发布时指定标签来发布。对于那些没有
                            scope 包, NPM 会以 "public" 的访问级别发布。更多信息可以
                            参考 NPM 文档上 "npm publish" 的 "--access" 选项。
                             For more information, see the NPM
      --pack                只有使用 --include-all 时该参数才可用，它将项目打包成压缩
                            包，而不会将其发布到 NPM 仓库上。当指定该参数时，与 NPM 源
                            相关的参数想会被忽略。
      --release-folder FOLDER
                            该参数用于给 --pack 参数提供自定义的打包位置，而不是使用默
                            认值。
      --include-all         一旦指定该参数，则 rush.json 内所有设定 shouldPublish=
                            true 的项目，和指定了版本策略且其版本比旧版本新的项目都会被
                            发布。
      --version-policy POLICY
                            版本策略名，当使用 --include-all 时，只有存在版本策略的项目
                            会被发布。
      --prerelease-name NAME
                            使用预览版命名来将其提高到预览版。不能与 --suffix 一起使用。
      --partial-prerelease  与 --prerelease-name 结合使用，只会将变更的库提升到预览版。
      --suffix SUFFIX       给所有变更的版本增加后缀。不能与 --prerelease-name 一起使用。
      --force               如果该参数与 --publish 共同使用，那么会给 npm 带上 --force.
      --apply-git-tags-on-pack
                            该参数与 --publish 和 --pack 共同使用，git 标签将会应用到
                            所有包将被应用到包上，就好像在没有 --pack 的情况下发布。
      -c COMMIT_ID, --commit COMMIT_ID
                            与 git 标签结合使用：在指定的 commit 哈希中使用 git 标签。
                            如果没有提供该参数，则使用当前的 HEAD.

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_purge/index.html b/zh-cn/pages/commands/rush_purge/index.html index 4eeb1e87..cfb33780 100644 --- a/zh-cn/pages/commands/rush_purge/index.html +++ b/zh-cn/pages/commands/rush_purge/index.html @@ -6,13 +6,13 @@ rush purge | Rush - +
    Rush StackShopBlogEvents

    rush purge

    用法： rush purge [-h] [--unsafe]

    "rush purge" 指令用于删除 Rush 创建的临时文件。当你遇到问题时，或者怀疑缓存有问题，便可以
    使用该命令.

    可选参数：
      -h, --help  展示帮助信息并退出
      --unsafe    （不安全）会删除存储在用户文件目录下的 ".rush" 文件夹内的共享文件，例
                  如包管理器。这是一个非常激进的修复方法，因为它将导致其他同时运行的 Rush
                  进程执行失败。
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_rebuild/index.html b/zh-cn/pages/commands/rush_rebuild/index.html index 6089738d..7feef135 100644 --- a/zh-cn/pages/commands/rush_rebuild/index.html +++ b/zh-cn/pages/commands/rush_rebuild/index.html @@ -6,13 +6,13 @@ rush rebuild | Rush - +
    Rush StackShopBlogEvents

    rush rebuild

    用法： rush rebuild [-h] [-p COUNT] [-t PROJECT] [-T PROJECT] [-f PROJECT]
                        [-o PROJECT] [-i PROJECT] [-I PROJECT]
                        [--to-version-policy VERSION_POLICY_NAME]
                        [--from-version-policy VERSION_POLICY_NAME] [-v]
                        [--ignore-hooks]


    该指令假定每个项目下的 package.json 文件中的 "scripts" 字段，该字段中有 "npm run build"
    这样完全清洁的构建。Rush 会调用该脚本来构建每个在 rush.json 中注册过的项目。项目会尽可能的
    并行构建，但永远会遵循本地链接生成的依赖图。并行的进程数基于机器的核心数，除非被 --parallelism
    参数覆盖（对于增量构建，可以使用 "rush build" 来替换 "rush rebuild"）。

    可选参数：
      -h, --help            展示帮助信息并退出
      -p COUNT, --parallelism COUNT
                            定义并行构建的最大并发数，COUNT 参数应该是一个正整数并且其最大
                            值等于 CPU 核数。如果该参数为空，那么默认值会依赖操作系统和 CPU
                            的核数决定。参数可以通过 RUSH_PARALLELISM 环境变量指定。
      -t PROJECT, --to PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--to" 参数会包含项目和其依赖的项目。"." 是当前工作目录
                            的简写。更多信息可以参考“选中部分项目”一文。
      -T PROJECT, --to-except PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--to-except" 参数会包含项目的依赖项目，而不包括项目
                            本身。"." 是当前工程目录的简写。更多信息可以参考“选中部分项目”
                            一文。
      -f PROJECT, --from PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--from" 参数会包含项目和所有依赖它的项目，再加上这个集
                            合的依赖。"." 是当前工程目录的简写。更多信息可以参考“选中部分
                            项目”一文。
      -o PROJECT, --only PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--only" 参数会选中指定的项目，而其依赖不会被添加。"." 是
                            当前目录的简写。注意这个参数是“不安全”的，因为它可能将某些依赖排除
                            在外。更多信息可以参考“选中部分项目”一文。
      -i PROJECT, --impacted-by PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--impacted-by" 参数会包含该项目和所有依赖该项目的项目
                            （因此可能会造成破坏性变动）。"." 是当前目录的简写。注意该参数是
                            “不安全的”, 因为它可能将某些依赖排除在外。更多信息可以参考“选中
                            部分项目”一文。
      -I PROJECT, --impacted-by-except PROJECT
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            每个 "--impacted-by-expect" 参数会包含所有依赖该项目的项目，
                            而不包含本身。"." 是当前目录的简写。注意该参数是“不安全的”，
                            因为它可能将某些依赖排除在外。更多信息可以参考“选中部分项目”一文。
      --to-version-policy VERSION_POLICY_NAME
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            "--to-version-policy" 参数会给每个属于 VERSION_POLICY_NAME
                            的项目指定 "--to", 更多信息可以参考“选中部分项目”一文。
      --from-version-policy VERSION_POLICY_NAME
                            正常情况下会构建仓库内的所有项目。通过该参数可以选中部分项目。
                            "--from-version-policy" 参数会给每个属于 VERSION_POLICY_NAME
                            的项目指定 "--from", 更多信息可以参考“选中部分项目”一文。
      -v, --verbose         构建期间展示更多信息，而不是仅仅展示总结性状态。
      --ignore-hooks        跳过定义在 "rush.jon" 下 "eventHooks" 脚本的。确保你知道
                            跳过了哪些。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_remove/index.html b/zh-cn/pages/commands/rush_remove/index.html index 88500568..03076f1b 100644 --- a/zh-cn/pages/commands/rush_remove/index.html +++ b/zh-cn/pages/commands/rush_remove/index.html @@ -6,13 +6,13 @@ rush remove | Rush - +
    Rush StackShopBlogEvents

    rush remove

    用法：rush remove [-h] [-s] -p PACKAGE [--all]

    从当前项目（由当前工作目录确定）的依赖项中删除指定的包，并运行 "rush update"。

    可选参数：
      -h, --help            显示此帮助消息并退出。
      -s, --skip-update     如果指定，将不会运行 "rush update" 命令来更新 package.json 文件。
      -p PACKAGE, --package PACKAGE
                            要删除的包的名称。要删除多个包，
                            请运行 "rush remove --package foo --package bar"。
      --all                 如果指定，将从所有声明它的项目中删除依赖项。

    参见​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_scan/index.html b/zh-cn/pages/commands/rush_scan/index.html index 2f645fb3..3d9d018b 100644 --- a/zh-cn/pages/commands/rush_scan/index.html +++ b/zh-cn/pages/commands/rush_scan/index.html @@ -6,13 +6,13 @@ rush scan | Rush - +
    Rush StackShopBlogEvents

    rush scan

    用法： rush scan [-h]

    Node.js 的模块系统允许项目引入一个没有在 package.json 文件中声明的 NPM 包。像这种
    “幻影依赖” 便会导致问题。Rush 和 PNPM 使用符号链接来防止幻影依赖，当开发者尝试将已有
    项目迁移到 Rush 时，这些保护性措施可能会导致运行时错误。"rush scan" 指令就是修复这些
    错误的工具，它会扫描 "./src" 和 "./lib" 目录下的 import 语法，诸如 "import __
    from '__'", "require('__')", and "System.import('__'). 这种方法并不完美，但是
    在迁移项目的过程中可以节省时间。

    可选参数：
      -h, --help  展示帮助信息并退出

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_setup/index.html b/zh-cn/pages/commands/rush_setup/index.html index 4336b9cf..a512e07f 100644 --- a/zh-cn/pages/commands/rush_setup/index.html +++ b/zh-cn/pages/commands/rush_setup/index.html @@ -6,13 +6,13 @@ rush setup | Rush - +
    Rush StackShopBlogEvents

    rush setup

    用法： rush setup [-h]

    （实验性）在投入到新的仓库前使用该命令可以确保所需的前提条件都已经安装、权限已经得到配置。
    并初始实现配置 NPM 源的凭证。将来会添加更多功能。

    可选参数：
      -h, --help    展示帮助信息并退出
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_tab-complete/index.html b/zh-cn/pages/commands/rush_tab-complete/index.html index a15a185e..343a0664 100644 --- a/zh-cn/pages/commands/rush_tab-complete/index.html +++ b/zh-cn/pages/commands/rush_tab-complete/index.html @@ -6,13 +6,13 @@ rush tab-complete | Rush - +
    Rush StackShopBlogEvents

    rush tab-complete

    用法： rush tab-complete [-h] [--word WORD] [--position INDEX]

    提供 tab 补全。

    可选参数：
      -h, --help        展示帮助信息并退出
      --word WORD       需要补全的单词，默认为 ""."".
      --position INDEX  单词中需要被补全的位置，默认为 0.

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_unlink/index.html b/zh-cn/pages/commands/rush_unlink/index.html index b5c91d14..d854c54c 100644 --- a/zh-cn/pages/commands/rush_unlink/index.html +++ b/zh-cn/pages/commands/rush_unlink/index.html @@ -6,13 +6,13 @@ rush unlink | Rush - +
    Rush StackShopBlogEvents

    rush unlink

    用法： rush unlink [-h]

    该命令用于移除 "rush link" 创建的符号连接。当使用 "git clean" 清理仓库时可以用次来保证不会删除源文件，或者需要在某个项目上使用 NPM 指令时很有用。

    可选参数：
      -h, --help     展示帮助信息并退出

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_update-autoinstaller/index.html b/zh-cn/pages/commands/rush_update-autoinstaller/index.html index 3a222b40..da8cf959 100644 --- a/zh-cn/pages/commands/rush_update-autoinstaller/index.html +++ b/zh-cn/pages/commands/rush_update-autoinstaller/index.html @@ -6,13 +6,13 @@ rush update-autoinstaller | Rush - +
    Rush StackShopBlogEvents

    rush update-autoinstaller

    用法：rush update-autoinstaller [-h] --name AUTOINSTALLER_NAME

    使用该指令该给一个自动安装文件夹生成 shrinkwrap 文件。

    可选参数：
      -h, --help            展示帮助信息并退出
      --name AUTOINSTALLER_NAME
                            指定自动安装的包名，它必须是 common/autoinstallers
                            下的一个文件夹。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_update-cloud-credentials/index.html b/zh-cn/pages/commands/rush_update-cloud-credentials/index.html index 42eaec98..c178801a 100644 --- a/zh-cn/pages/commands/rush_update-cloud-credentials/index.html +++ b/zh-cn/pages/commands/rush_update-cloud-credentials/index.html @@ -6,13 +6,13 @@ rush update-cloud-credentials | Rush - +
    Rush StackShopBlogEvents

    rush update-cloud-credentials

    用法： rush update-cloud-credentials [-h] [-i]
                                         [--credential CREDENTIAL_STRING] [-d]

    （实验性）如果配置了构建缓存功能，那么该指令可以可以方便的更新基于云服务商的凭证。

    可选参数：
      -h, --help            展示帮助信息并退出
      -i, --interactive     如果云服务商支持的话，可以以交互形式来更新凭证。
      --credential CREDENTIAL_STRING
                            一个将被缓存的静态凭证。
      -d, --delete          一旦指定该参数，会删除存储的凭证。

    参考更多​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_update/index.html b/zh-cn/pages/commands/rush_update/index.html index 54c4b98c..84e459de 100644 --- a/zh-cn/pages/commands/rush_update/index.html +++ b/zh-cn/pages/commands/rush_update/index.html @@ -6,13 +6,13 @@ rush update | Rush - +
    Rush StackShopBlogEvents

    rush update

    用法： rush update [-h] [-p] [--bypass-policy] [--no-link]
                       [--network-concurrency COUNT] [--debug-package-manager]
                       [--max-install-attempts NUMBER] [--ignore-hooks]
                       [--variant VARIANT] [--full] [--recheck]

    "rush update" 命令会依据 package.json 文件安装依赖，并按需更新 shrinkwrap 文件（
    shrinkwrap 文件是存储仓库内所有项目的依赖和版本的中心，它被放到 "common/config/rush"
    文件夹下）。注意，Rush 会在一次性给仓库内的所有项目安装。 当你从 Git 上拉去文件，或者修改
    完 package.json 文件后，需要执行 "rush update" 才能开始工作。如果无需更新，则 "rush
    update" 会在瞬时完成。注意：在某些情况下应该使用 "rush install" 来替换 "rush update",
    更多信息可以参考 "rush install" 的命令行帮助。

    可选参数：
      -h, --help            展示帮助信息并退出
      -p, --purge           开始执行之前执行 "rush purge".
      --bypass-policy       强制覆盖 rush.json 中约定的 "gitPolicy" 规定。
      --no-link             一旦指定该参数，那么当安装完成后项目不会执行符号连接。你需要手动
                            执行 "rush link", 当想要独立的报告每个阶段，或者在两个阶段之
                            间进行额外的操作时，该参数十分有用。当使用 workspaces 时，不支
                            持该参数。
      --network-concurrency COUNT
                            一旦指定该参数，将会限制最大的并发网络请求数。当网络出现问题时，
                            该参数十分有用。
      --debug-package-manager
                            开启包管理器的详细日志。当使用该参数时，你可能想要 Rush 输出到
                            一个文件中。
      --max-install-attempts NUMBER
                            覆盖默认的尝试安装的次数，默认值为 3.
      --ignore-hooks        跳过执行定义在 rush.json 中的 "eventHooks" 脚本。你应该知道
                            自己跳过了什么。
      --variant VARIANT     通过一个安装配置变量来执行 Rush 命令。该参数可以通过环境变量
                            RUSH_VARIANT 来指定。
      --full                通常 "rush update" 会尝试保留已安装的版本并会在满足
                            package.json 文件要求的情况下进行最小更新。这种保守的方式
                            可以防止 PR 被卷入到与自己无关的包更新中。当你想将所有依赖
                            更新到语义化兼容的最新版本时候，可以使用 "--full" 参数。
                            该操作应该由某个人或者机器来定期执行，进而处理潜在的升级回
                            归。
      --recheck             如果 shrinkwrap 文件看依赖已经满足 package.json 文件，
                            那么 "rush update" 不再会调用包管理器。但是在某些情况
                            下，这种方法可能并不精准。使用 "--recheck" 参数可以强制
                            包管理器处理 shrinkwrap 文件。这也会更新 shrinkwrap 文件。
                            （为了最大限度减少 shrinkwrap 的变更，这些修复只会在临时
                            文件中执行）

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_upgrade-interactive/index.html b/zh-cn/pages/commands/rush_upgrade-interactive/index.html index 1c832c62..ba0d943a 100644 --- a/zh-cn/pages/commands/rush_upgrade-interactive/index.html +++ b/zh-cn/pages/commands/rush_upgrade-interactive/index.html @@ -6,13 +6,13 @@ rush upgrade-interactive | Rush - +
    Rush StackShopBlogEvents

    rush upgrade-interactive

    用法：rush upgrade-interactive [-h] [--make-consistent] [-s]

    用交互式命令行来升级依赖项。
    运行该命令将打开一个交互式提示，询问你要升级哪些项目和依赖项。
    它将更新 package.json 文件，然后为你运行 "rush update"。
    如果你使用 ensureConsistentVersions 策略，upgrade-interactive
    将更新所有使用你升级的依赖项的包，
    并且匹配它们的 SemVer 范围（如果提供的话）。
    如果未启用 ensureConsistentVersions，upgrade-interactive
    将仅更新你指定的包中的依赖项。
    这可以通过使用 --make-consistent 标志来覆盖。

    可选参数：
      -h, --help         显示此帮助消息并退出。
      --make-consistent  当从单个项目升级依赖项时，也升级其他项目的依赖项。
      -s, --skip-update  如果指定，将不会运行 "rush update" 命令来更新 package.json 文件。

    参见​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rush_version/index.html b/zh-cn/pages/commands/rush_version/index.html index b986e56a..6504768a 100644 --- a/zh-cn/pages/commands/rush_version/index.html +++ b/zh-cn/pages/commands/rush_version/index.html @@ -6,13 +6,13 @@ rush version | Rush - +
    Rush StackShopBlogEvents

    rush version

    用法： rush version [-h] [-b BRANCH] [--ensure-version-policy]
                        [--override-version NEW_VERSION] [--bump]
                        [--bypass-policy] [--version-policy POLICY]
                        [--override-bump BUMPTYPE] [--override-prerelease-id ID]

    使用 "rush version" 指令来确保版本策略和变更版本。

    可选参数：
      -h, --help            展示帮助信息并退出。
      -b BRANCH, --target-branch BRANCH
                            一旦指定该参数，将会把变更和删除变更的行为提交并合并到指定分
                            支上。
      --ensure-version-policy
                            如果需要满足版本策略，则更新包版本。
      --override-version NEW_VERSION
                            使用指定的 --version-policy 覆盖版本。只有当指定
                            --ensure-version-policy 时，该设置才会对 lock-step
                            版本策略起作用。
      --bump                基于版本策略进行版本变更。policies.
      --bypass-policy       强制覆盖 rush.json 中约定的 "gitPolicy" 规定。
      --version-policy POLICY
                            版本政策的名字
      --override-bump BUMPTYPE
                            在 version-policy.json 中覆盖变更类型。有效的版本变更类型
                            包括：prerelease, patch, preminor, minor,
                            major. 该设定只对 lock-step 版本策略有效。
      --override-prerelease-id ID
                            覆盖 version-policy.json 中的预发布 id. 该设定只对
                            lock-step 版本策略有效。当带有 "--bump" 参数时，该配置
                            会增加预发布 id; 当带有 "--ensure-version-policy"
                            时，该配置会替换预发布名称。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/commands/rushx/index.html b/zh-cn/pages/commands/rushx/index.html index 2499a35f..6b448a29 100644 --- a/zh-cn/pages/commands/rushx/index.html +++ b/zh-cn/pages/commands/rushx/index.html @@ -6,13 +6,13 @@ rushx | Rush - +
    Rush StackShopBlogEvents

    rushx

    rushx 命令与 npm run 或者 pnpm run 类似，它会调用 package.json 文件中 "scripts" 字段中定义的 shell 脚本。任何额外的命令行参数都会传递给该 shell 脚本，这些参数不会经过任何验证。

    例如在你的项目中：

    <my project>/package.json

    {
      "name": "my-project",
      "version": "0.0.0",
      "scripts": {
        "build": "rm -Rf lib && tsc",
        "test": "jest"
      }
    }

    如果你单独调用 rushx，它将会显示可用的命令：

    用法：rushx [-h]
          rushx [-q/--quiet] <命令> ...

    可选参数：
      -h, --help            展示帮助信息并退出。
      -q, --quiet           隐藏 Rush 启动信息。

    my-project 项目中可用的命令：
      build: "rm -Rf lib && tsc"
      test:  "jest"

    调用 rushx build 等同于运行 rm -Rf lib && tsc。添加的参数将会被直接添加到字符串的末尾，例如 rushx build --verbose 等同于 rm -Rf lib && tsc --verbose。

    使用 "rush" 还是 "rushx"？​

    rushx 和 rush 这两个命令很容易混淆：

    • rush 调用一个通用的操作，它会影响整个仓库（“全局命令”）或者多个项目（“批量命令”）。这些命令应该被仔细设计。Rush 会强制对它们的参数进行验证和文档化。
    • rushx 为单个项目执行自定义操作。尽管一些命令用于实现批量命令，但是许多命令都是该项目开发人员独有的辅助脚本。Rush 并不严格验证这些命令。

    为什么使用 "rushx" 而不是 "pnpm run" 或者 "npx"？​

    rushx 命令具有与 pnpm run 或者 npx 相似的功能，但是还有一些额外的好处：

    • 通过使用 Rush 版本选择器 来确定需要使用的工具链
    • 基于 Rush 的配置来准备 shell 环境
    • 实现了额外的验证
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/artifactory_json/index.html b/zh-cn/pages/configs/artifactory_json/index.html index 26394c26..1e5a1567 100644 --- a/zh-cn/pages/configs/artifactory_json/index.html +++ b/zh-cn/pages/configs/artifactory_json/index.html @@ -6,13 +6,13 @@ artifactory.json | Rush - +
    Rush StackShopBlogEvents

    artifactory.json

    这是 rush init 为 monorepo 生成的模版下的 artifactory.json 文件：

    common/config/rush/artifactory.json

    /**
     * 该配置项用于管理 Rush 和 JFrog Artifactory 服务集成。
     * 更多信息可以参考 Rush 官网： https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/artifactory.schema.json",

      "packageRegistry": {
        /**
         * (Required) Set this to "true" to enable Rush to manage tokens for an Artifactory NPM registry.
         * When enabled, "rush install" will automatically detect when the user's ~/.npmrc
         * authentication token is missing or expired.  And "rush setup" will prompt the user to
         * renew their token.
         * （必须）设定该值为 "true" 来使得 Rush 管理 Artifactory NPM 的口令。当开启后，"rush install" 会自动检测
         * 用户的 ~/.npmrc 认证令牌是否缺失或过期，并且 "rush setup" 将会提示用户更新令牌。
         *
         * 默认值为 false.
         */
        "enabled": false,

        /**
         * （必须）给 NPM 源指定 URL, 它与 .npmrc 文件中的 URL 相同，应该像这样：
         *
         *   https://your-company.jfrog.io/your-project/api/npm/npm-private/
         */
        // "registryUrl": "",

        /**
         * 一系列自定义字符串，当口令更新后 "rush setup" 将其添加到用户的 ~/.npmrc 文件中。例如，这可以配置公司源，以便
         * NPM 作为一个独立命令（但是对于 "rush add" 和 "rush install" 等操作没有必要，因为它们会从 monorepo 的
         * common/config/rush/.npmrc 获取）
         *
         * 注意： ~/.npmrc 设定在给定机器上是全局的，所以添加设定时要小心，防止与其他工作区冲突。
         */
        "userNpmrcLinesToAdd": [
          // "@example:registry=https://your-company.jfrog.io/your-project/api/npm/npm-private/"
        ],

        /**
         * （必须）指定 Artifactory 控制面板的 URL, 用户在此处生成一个 API 密钥。
         * 该 URL 在 "visitWebsite" 后打印。其示例如： https://your-company.jfrog.io/
         * 指定一个空字符串来覆盖这一行。
         */
        // "artifactoryWebsiteUrl": "",

        /**
         * 该配置项允许自定义 "rush setup" 交互，例如为您的团队或配置提供消息。
         * 指定一个空字符串来覆盖这一行。
         */
        "messageOverrides": {
          /**
           * 覆盖通常所输出的消息：
           * “这个 monorepo 使用来自 Artifactory 私有 NPM 源的包”
           */
          // "introduction": "",

          /**
           * 覆盖通常所输出的消息：
           * “请联系版本库维护者，以获得设置 Artifactory 用户账户的帮助。”
           */
          // "obtainAnAccount": "",

          /**
           * 覆盖通常所输出的消息：
           * “请在浏览器中打开这个 URL：”
           *
           * 这条信息后，"artifactoryWebsiteUrl" 会打印。
           */
          // "visitWebsite": "",

          /**
           * 覆盖通常所输出的消息：
           * “您的用户名出现在 JFrog 网站的右上角”
           */
          // "locateUserName": "",

          /**
           * 覆盖通常所输出的消息：
           *
           * “在 JFrog 网站上点击 “编辑资料”。 如果还没生成米要的话，
           * 请点击“生成API密钥”按钮。”
           *
           */
          // "locateApiKey": ""
        }
      }
    }

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/build-cache_json/index.html b/zh-cn/pages/configs/build-cache_json/index.html index 7b2b6668..13205673 100644 --- a/zh-cn/pages/configs/build-cache_json/index.html +++ b/zh-cn/pages/configs/build-cache_json/index.html @@ -6,13 +6,13 @@ build-cache.json | Rush - +
    Rush StackShopBlogEvents

    build-cache.json

    这是 rush init 为 monorepo 生成的模版下的 build-cache.json 文件：

    common/config/rush/build-cache.json

    /**
     * 该配置项用于管理 Rush 的构建缓存功能。
     * 更多信息可以参考 Rush 官网： https://rushjs.io
     */
     {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/build-cache.schema.json",

      /**
       * （必须）实验性 - 设定该值为 true 来开启构建缓存功能。
       *
       * 参考 https://rushjs.io/pages/maintainer/build_cache/ 来获取该实验性功能的更多细节。
       */
      "buildCacheEnabled": false,

      /**
       * （必须）选择把构建缓存放到哪里。
       *
       * 可选的值： "local-only", "azure-blob-storage", "amazon-s3"
       */
      "cacheProvider": "local-only",

      /**
       * 设定该值覆盖缓存入口 ID.
       * 如果设定该值，那么它必须包含一个 [hash] 占位符，
       * 它也可以包含 [projectName], [projectName:normalize], [phaseName], [phaseName:normalize], [phaseName:trimPrefix]
       */
      // "cacheEntryNamePattern": "[projectName:normalize]-[hash]"

      /**
       * 该配置项用于配置 "cacheProvider"="azure-blob-storage"
       */
      "azureBlobStorageConfiguration": {
        /**
         * （必须）用于构建缓存的 Azure storage 账户。
         */
        // "storageAccountName": "my-account",

        /**
         * （必须）用于构建缓存的容器名。
         */
        // "storageContainerName": "my-container",

        /**
         * Azure 环境内的账户。默认为 AzurePublicCloud.
         *
         * 可选的值： "AzurePublicCloud", "AzureChina", "AzureGermany", "AzureGovernment"
         */
        // "azureEnvironment": "AzurePublicCloud",

        /**
         * 缓存项目的前缀名。
         */
        // "blobPrefix": "my-prefix",

        /**
         * 如果设定为 true, 允许写入到缓存中。
         * 默认为 false.
         */
        // "isCacheWriteAllowed": true
      },

      /**
       * 该配置项用于配置 "cacheProvider"="amazon-s3"
       */
      "amazonS3Configuration": {
        /**
         * （必备） 用于建立缓存的亚马逊 S3 的桶（例如 "us-east-1"）。
         */
        // "s3Region": "us-east-1",

        /**
         * 用于建立缓存的Amazon S3中的桶的名称。
         */
        // (Required) "s3Bucket": "my-bucket",

        /**
         * 缓存项目的可选前缀（"文件夹"）。
         */
        // "s3Prefix": "my-prefix",

        /**
         * 如果设置为true，允许写入缓存。
         * 默认为false。
         */
        // "isCacheWriteAllowed": true
      }
    }

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/cobuild_json/index.html b/zh-cn/pages/configs/cobuild_json/index.html index a1936f04..a5443594 100644 --- a/zh-cn/pages/configs/cobuild_json/index.html +++ b/zh-cn/pages/configs/cobuild_json/index.html @@ -6,14 +6,14 @@ cobuild.json (experimental) | Rush - +
    Rush StackShopBlogEvents

    cobuild.json (experimental)

    This is the template that rush init generates for the cobuild feature.

    common/config/rush/cobuild.json

    /**
     * This configuration file manages Rush's cobuild feature.
     * More documentation is available on the Rush website: https://rushjs.io
     */
     {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/cobuild.schema.json",

      /**
       * (Required) EXPERIMENTAL - Set this to true to enable the cobuild feature.
       * RUSH_COBUILD_CONTEXT_ID should always be specified as an environment variable with an non-empty string,
       * otherwise the cobuild feature will be disabled.
       */
      "cobuildFeatureEnabled": false,

      /**
       * (Required) Choose where cobuild lock will be acquired.
       *
       * The lock provider is registered by the rush plugins.
       * For example, @rushstack/rush-redis-cobuild-plugin registers the "redis" lock provider.
       */
      "cobuildLockProvider": "redis"
    }

    See also​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/command-line_json/index.html b/zh-cn/pages/configs/command-line_json/index.html index eac5e7c5..e9a40bc6 100644 --- a/zh-cn/pages/configs/command-line_json/index.html +++ b/zh-cn/pages/configs/command-line_json/index.html @@ -6,13 +6,13 @@ command-line.json | Rush - +
    Rush StackShopBlogEvents

    command-line.json

    这是 rush init 为 monorepo 生成的模版下的 command-line.json 文件：

    common/config/rush/command-line.json

    /**
     * 该配置项配置 "rush" 的自定义命令。
     * 更多信息可以参考 Rush 官网： https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/command-line.schema.json",

      /**
       * 自定义“命令”为命令行引入了新的变量。可以通过 "rush --help", "rush my-bulk-command --help", 或
       * "rush my-global-command --help" 来看更多的帮助。
       */
      "commands": [
        // {
        //   /**
        //    * （必须）决定自定义命令的类型
        //    * Rush 的 "bulk" 命令会在每个项目中单独执行。Rush 会寻找每个项目内的 package.json 文件下的
        //    * 符合命令的 "script' 脚本。默认情况下，命令会按照依赖图在仓库内的每个项目执行（与 "rush build"
        //    * 工作流类似）。
        //    * 可以限定一些子项目，例如使用 "--to" 或 "--from" 参数。
        //    */
        //   "commandKind": "bulk",
        //
        //   /**
        //    * （必须） 输入的名称被视为命令行的一部分。 这也项目内 package.json 中
        //    * "scripts" 的钩子。
        //    * 该名称必须是大写字母、数字和下划线的组合，它应当包含一个英语动词（例如： "deploy"）
        //    * 使用连字符来分割单词（例如： "upload-docs")。一组相关的命令可以以冒号为前缀。
        //    * （例如："docs:generate", "docs:deploy", "docs:serve" 等等）
        //    *
        //    * 注意，如果此处覆盖了 "rebuild" 命令，它就与 "build" 指令分割开了，
        //    * 同时会调用 "rebuild" 而不是 "build" 脚本。
        //    */
        //   "name": "my-bulk-command",
        //
        //   /**
        //    * （必须）该自定义命令的简短总结，它将被展示在命令行帮助中。
        //    * 例如 "rush --help".
        //    */
        //   "summary": "Example bulk custom command",
        //
        //   /**
        //    * 当打印命令行帮助时的更细节的描述。（例如："rush --help my-command"）
        //    * 如果为空，则使用 "summary" 字段。
        //    *
        //    * 无论何时引入指令或参数，花些时间来写一些有意义的文档会给开发体验带来巨大提升。
        //    */
        //   "description": "This is an example custom command that runs separately for each project",
        //
        //   /**
        //    * Rush 操作需要一个锁文件来防止同一个仓库被多个指令同时处理。（例如：同时执行 "rush install" 和
        //    * "rush build" 会出错）。如果你的命令可以与其他操作同时执行，那么设定 "safeForSimultaneousRushProcesses"
        //    * 为 true 来禁用这种保护。
        //    *
        //    * 对于调用其他 Rush 命令的脚本而言，这一点是尤为需要的。
        //    */
        //   "safeForSimultaneousRushProcesses": false,
        //
        //   /**
        //    * （必须）如果为真，那么该指令可以安全的并行执行，例如同时在多个项目内执行。
        //    * 与 "rush build" 类似，无论是否开启并行，在其依赖完成前，该项目都不会
        //    * 开始执行。
        //    */
        //   "enableParallelism": false,
        //
        //   /**
        //    * 通常项目会依照依赖顺序处理，对于某个项目而言，直到其依赖处理完成后才会处理
        //    * 该项目。但对于某个特定的操作而言，该限制并不适用，例如 "clean" 任务来删除
        //    * 输出文件。在这种情况下，可以设定 "ignoreDependencyOrder" 为 true 来
        //    * 提高并行度。
        //    */
        //   "ignoreDependencyOrder": false,
        //
        //   /**
        //    * 通常情况下，Rush 会要求每个项目的 package.jso 文件下都有对应的 "script"
        //    * 匹配自定义指令名。设定 "ignoreMissingScript" 为 true 可以禁止此检查，
        //    * 缺少相应定义的项目会被跳过。
        //    */
        //   "ignoreMissingScript": false,
        //
        //   /**
        //    * 当调用 shell 脚本时，Rush 将用以下方法来从警告信息中区分出错误信息：
        //    * - 如果脚本返回非 0 状态码，那么 Rush 会认为存在“一个或多个错误”，之后以红色输
        //    * 出错误信息，它会阻止 Rush 继续处理其他项目。
        //    * - 如果脚本的状态码为 0, 但是向 stderr 流写入了一些数据，Rush 会认为存在 “一
        //    * 个或多个警告”，之后以黄色输出警告信息，但是不会阻止 Rush 继续处理其他项目。
        //    *
        //    * 因此，警告信息不会阻碍本地开发，但在 Rush 的设计中，当存在任何警告或报错信息，
        //    * Rush进程会返回非 0 状态码，进而会导致 CI 任务失败，
        //    * 在一个活跃的 monorepo 中，我们发现如果你的主干分支允许警告，那么就会在不经
        //    * 意间交给开发者忽略警告，这很快会导致存在非常多“预期”的警告信息以至于这些信息
        //    * 没有任何提示性作用的状态。
        //    *
        //    * 有时，尽管操作是成功的，但由于某个行为存在问题的任务会被写入到 stderr 流中。
        //    * 在这种情况下，强烈建议修复这个任务，然而，你可以设定 allowWarningsInSuccessfulBuild
        //    * =true 来进行变通，这会导致 Rush 只会对错误信息才返回非 0 的状态码。
        //    *
        //    * 注意： 默认值为 false. 在 5.7.x 以及更旧的版本中，默认值为 true.
        //    */
        //   "allowWarningsInSuccessfulBuild": false,
        //
        //   /**
        //    * 该参数为 true 时，其行为类似于内置的 "build" 命令的增量构建。
        //    */
        //   "incremental": false,
        //
        //   /**
        //    * （实验性）通常 Rush 会在命令完成后终止。如果该值被设定为 "true", Rush 会进入
        //    * 到一个监听指定项目文件的循环中。当检测到文件变动时，指令会被唤醒，且其范围是选
        //    * 中的项目以及依赖。
        //    *
        //    * 更多信息，可以参考“使用监听模式”一文。
        //    */
        //   "watchForChanges": false,
        //
        //   /**
        //    * （实验性）对于该行为禁止掉缓存。如果该命令会影响到项目自身目录以外的状态时，该
        //    * 命令很有用。
        //    */
        //   "disableBuildCache ": false
        // },
        //
        // {
        //   /**
        //    * （必须）自定义指令的类型。
        //    * Rush 的 "global" 指令会在整个项目内唤醒一次。
        //    */
        //   "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,
        //
        //   /**
        //    * （必须）一个使用操作系统 shell 调用的脚本。工作目录是含有 rush.json 的
        //    * 目录。如果自定义指令与该指令有关，那么它们的值应该被添加到字符串的尾部。
        //    */
        //   "shellCommand": "node common/scripts/my-global-command.js",
        //
        //   /**
        //    * 如果你的 "shellCommand" 依赖 NPM 包，那么推荐将其写成 Rush 内的一
        //    * 个项目，使得工作链可以正常构建。某些情况下该指令应该在没有首次执行
        //    * "rush build" 的情况下正常工作，推荐的方式是将该项目发布到 NPM 源
        //    * 上，并使用 common/scripts/install-run.js 来调用它。
        //    *
        //    * 自动安装功能提供了另外一种可能：在 "common/autoinstallers" 下的目
        //    * 录都有一个 package.json 文件和 shrinkwrap 文件。在被调用前，Rush
        //    * 会自动调用包管理器来安装这些依赖。自动下载有一个优势：即使所在的分支的  Autoinstallers have the
        //    * "rush isntall" 出现了问题，它们也能正常工作，这使得该功能可以实现
        //    * Git 的钩子脚本。但是该功能也有一个缺点，它们不能用于构建项目，并且会增
        //    * 加仓库的安装量。
        //    *
        //    * "autoinstallerName" 属性不能包含路径，并必须是一个有效的 NPM 包名。
        //    * 例如， "my-task" 是映射到 "common/autoinstallers/my-task/package.json"
        //    * 的包名，当调用该 "shellCommand" 时，"common/autoinstallers/my-task/node_modules/.bin"
        //    * 应当被添加到环境变量中。
        //    */
        //   // "autoinstallerName": "my-task"
        // }
      ],

      /**
       * 自定义“参数”给指定的 Rush 命令行指令引入了参数。
       * 例如，你也许会给 "rush build" 命令增加 "production" 参数。
       */
      "parameters": [
        // {
        //   /**
        //    * （必须）自定义参数的类型
        //    * "flag" 类型表明该参数的作用是一个开关。
        //    */
        //   "parameterKind": "flag",
        //
        //   /**
        //    * （必须）参数的全名。必须是小写并使用破折号分割。
        //    */
        //   "longName": "--my-flag",
        //
        //   /**
        //    * 该参数的缩写，该属性可选。它必须是在破折号后跟有一个
        //    * 大小写敏感的字母，
        //    *
        //    * 注意：推荐使用全名来增加可读性。缩写仅仅是为了方便。
        //    * 字母表很容易被占用完，并且不方便记忆，所以*仅仅*当
        //    * 遇到非常频繁的操作时才使用简写。
        //    */
        //   "shortName": "-m",
        //
        //   /**
        //    * （必须） 在命令帮助中显示的描述信息。
        //    *
        //    * 无论何时引入指令或参数，花些时间来写一些有意义的文档会给开发体验带来巨大提升。
        //    */
        //   "description": "A custom flag parameter that is passed to the scripts that are invoked when building projects",
        //
        //   /**
        //    * （必须）该列表内存储了这个参数可被哪些自定义指令或内置指令使用。
        //    */
        //   "associatedCommands": ["build", "rebuild"]
        // },
        //
        // {
        //   /**
        //    * （必须）自定义参数的类型
        //    * 一个“字符串”类型的自定义命令行参数是指参数为一个简单的文本。
        //    */
        //   "parameterKind": "string",
        //   "longName": "--my-string",
        //   "description": "A custom string parameter for the \"my-global-command\" custom command",
        //
        //   "associatedCommands": ["my-global-command"],
        //
        //   /**
        //    * 参数名，在命令帮助中将被显示。
        //    *
        //    * 例如，参数名一个 "--count", 其类型为 "NUMBER", 那么命令行
        //    * 帮助信息应该展示 "--count NUMBER". 该参数必须由大写字母、数字
        //    * 下划线组成，应该尽可能的短。
        //    */
        //   "argumentName": "SOME_TEXT",
        //
        //   /**
        //    * 当该属性为 true 时，参数必须包含在命令中。默认为 false.
        //    */
        //   "required": false
        // },
        //
        // {
        //   /**
        //    * （必须）自定义参数的类型
        //    * "choice" 参数类型是指参数必须是给定列表内的某个值。
        //    */
        //   "parameterKind": "choice",
        //   "longName": "--my-choice",
        //   "description": "A custom choice parameter for the \"my-global-command\" custom command",
        //
        //   "associatedCommands": ["my-global-command"],
        //
        //   /**
        //    * 当该属性为 true 时，参数必须包含在命令中。默认为 false.
        //    */
        //   "required": false,
        //
        //   /**
        //    * 正常情况下若某个参数被省略掉，那么它将不会被传到 shell 中。
        //    * 该属性用于插入一个默认值，若 "defaultValue" 定义后，参数永远会被
        //    * 传入到 shell 中，若未指定则使用默认值。该值必须是定义在可选列表中
        //    * 的一个。
        //    */
        //   "defaultValue": "vanilla",
        //
        //   /**
        //    * （必须）一系列用于选择的可选参数。
        //    */
        //   "alternatives": [
        //     {
        //       /**
        //        * 用于选择参数的一个可选值。
        //        * 例如，在 "--flavor vanilla" 使用了 "vanilla".
        //        */
        //       "name": "vanilla",
        //
        //       /**
        //        *
        //        * 在命令行帮助中显示的可选参数的详细描述。
        //        *
        //        * 无论何时引入指令或参数，花些时间来写一些有意义的文档会给开发体验带来巨大提升。
        //        *
        //        */
        //       "description": "Use the vanilla flavor (the default)"
        //     },
        //
        //     {
        //       "name": "chocolate",
        //       "description": "Use the chocolate flavor"
        //     },
        //
        //     {
        //       "name": "strawberry",
        //       "description": "Use the strawberry flavor"
        //     }
        //   ]
        // }
      ]
    }

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/command_line_json/index.html b/zh-cn/pages/configs/command_line_json/index.html index 7332c63c..f520cd3c 100644 --- a/zh-cn/pages/configs/command_line_json/index.html +++ b/zh-cn/pages/configs/command_line_json/index.html @@ -6,13 +6,13 @@ command_line_json | Rush - +
    Rush StackShopBlogEvents

    Redirecting...

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/common-versions_json/index.html b/zh-cn/pages/configs/common-versions_json/index.html index c63c2bfa..b7be0cd2 100644 --- a/zh-cn/pages/configs/common-versions_json/index.html +++ b/zh-cn/pages/configs/common-versions_json/index.html @@ -6,13 +6,13 @@ common-versions.json | Rush - +
    Rush StackShopBlogEvents

    common-versions.json

    这是 rush init 为 monorepo 生成的模版下的 command-version.json 文件：

    common/config/rush/common-versions.json

    /**
     * 该配置项用于配置 NPM 依赖版本，它会影响 Rush 仓库内的所有项目。
     * 更多信息可以参考 Rush 官网： https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/common-versions.schema.json",

      /**
       * 一张指定 NPM 包的“偏好版本”的表。该功能通常用于给间接依赖指定某个旧版本
       * 或者减少间接依赖的复制数量。
       *
       * "preferredVersions" 是一个语义化的值（例如： "~1.2.3"）。Rush 将该值插入
       * 到影响包管理机器计算版本的顶层 common/temp/package.json 中的 "dependencies" 字段中。
       * 该字段的效果由包管理器决定，通常不会导致兼容或者违背语义化版本的问题。
       * 如果你使用 PNPM, 其效果类似于 pnpmfile.js 钩子，可以查看 Rush 的文档来了解更多细节。
       *
       * 修改完该字段后，建议执行 "rush update --full" 来使得包管理器重新计算版本。
       */
      "preferredVersions": {
        /**
         * 当仓库内某个依赖请求 "^1.0.0" 时，确保它们会获得 "1.2.3"
         * 版本，而不是最新版本。
         */
        // "some-library": "1.2.3"
      },

      /**
       * 当设定该值为 true 时，仓库中的所有项目、所有依赖将会被自动添加到 preferredVersions 中，
       * 除非不同的项目为某个依赖指定了不同的版本范围。
       * 对于陈旧的版本管理器而言，它们会尝试减少非直接依赖的复制数量。但是，对于不兼容 peerDependencies
       * 的间接依赖而言可能造成问题。
       *
       * 该值的默认值为 true. 如果你在安装期间遇到了同级依赖导致的问题，建议
       * 将它设定为 false.
       *
       * 修改完该字段后，建议执行 "rush update --full" 来使得包管理器重新计算版本。
       */
      // "implicitlyPreferredVersions": false,

      /**
       * "rush check" 命令用来确保每个项目中的同一版本都有相同的语义化版本。
       * 然而，有时需要一些例外。
       * allowedAlternativeVersions 属性列出 "rush check" 运行时允许的
       * 其他版本的依赖列表。
       *
       * 重要：这张表是针对*额外*的版本，它是通常版本（根据仓库中的所有项目推
       * 断而来）的替代品。这个设计避免了该文件不必要的更新。
       */
      "allowedAlternativeVersions": {
        /**
         * 例如，允许某些项目使用旧版本的 TypeScript 编译器。
         * （除了其他项目正在使用的“通常”版本，还包括）：
         */
        // "typescript": [
        //   "~2.4.0"
        // ]
      }
    }
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/common_versions_json/index.html b/zh-cn/pages/configs/common_versions_json/index.html index 32dfebd6..07ad92e7 100644 --- a/zh-cn/pages/configs/common_versions_json/index.html +++ b/zh-cn/pages/configs/common_versions_json/index.html @@ -6,13 +6,13 @@ common_versions_json | Rush - +
    Rush StackShopBlogEvents

    Redirecting...

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/custom-tips_json/index.html b/zh-cn/pages/configs/custom-tips_json/index.html index 0dea4ccf..7815a3b8 100644 --- a/zh-cn/pages/configs/custom-tips_json/index.html +++ b/zh-cn/pages/configs/custom-tips_json/index.html @@ -6,13 +6,13 @@ custom-tips.json (实验性功能) | Rush - +
    Rush StackShopBlogEvents

    custom-tips.json (实验性功能)

    这是 rush init 为 Custom tips 功能生成的模板配置文件。

    common/config/rush/custom-tips.json

    /**
     * 这个配置文件允许仓库维护者配置与某些 Rush 消息一起打印的额外详细信息。更多文档可在
     * Rush 官方网站上找到：https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/custom-tips.schema.json",

      /**
       * 指定 Rush 要显示的 custom tips。
       */
      "customTips": [
        // {
        //   /**
        //    * (必须) 一个标识符，表示 Rush 可能打印的消息。
        //    * 如果打印了该消息，则将显示此 custom tip。
        //    * 请参阅 Rush 文档以获取可能的标识符的当前列表。
        //    */
        //   "tipId": "TIP_RUSH_INCONSISTENT_VERSIONS",
        //
        //   /**
        //    * (必须) 要为此提示显示的消息文本。
        //    */
        //   "message": "要获取额外的故障排除信息，请参阅此 wiki 文章：\n\nhttps://intranet.contoso.com/docs/pnpm-mismatch"
        // }
      ]
    }

    另请参阅​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/deploy_json/index.html b/zh-cn/pages/configs/deploy_json/index.html index 039ad0e8..027babbd 100644 --- a/zh-cn/pages/configs/deploy_json/index.html +++ b/zh-cn/pages/configs/deploy_json/index.html @@ -6,13 +6,13 @@ deploy.json | Rush - +
    Rush StackShopBlogEvents

    deploy.json

    这是 rush init-deploy 为 deploy.json 和 deploy-<scenario name>>.json 生成的模版文件：

    common/config/rush/deploy.json

    /**
     * 这个配置文件约定了使用 "rush deploy" 时的部署场景。
     * 默认的文件是 "deploy.json"; 其他的文件名匹配 "deploy-<scenario-name>.json".
     * 更全的文档可以参考：https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/deploy-scenario.schema.json",

      /**
       * "rush deploy" 命令准备了一个构建文件夹，用于从主项目开始收集其所
       * 有依赖（包括 NPM 包和 Rush 工程）， 主项目被 "--project" 参数指定。
       * "deploymentProjectNames" 列出了 "--project" 参数可选的列表，它
       * 记录了仓库内想要部署的项目，并帮助 "rush deploy" 正确的调用。如果
       * "deploymentProjectNames" 列表内只有一个项目，那么 "--project"
       * 参数可以被忽略，同时，其列表内的项目名应该是是 rush.json 中声明的包
       * 名。
       *
       * 如果住项目包含其他无关的 Rush 工程，那么添加它们到 "projectSettings"
       * 中，之后在 "additionalProjectsToInclude" 指定它们。
       */
      "deploymentProjectNames": [ /* 在这添加你的工程 */ ],

      /**
       * 当部署一个本地 Rush 工程时，package.json 中的 "devDependencies"
       * 会被排除在外。如果你想包含它们，则设定 "includeDevDependencies" 为
       * true.
       *
       * 该参数默认值为 false.
       */
      // "includeDevDependencies": true,

      /**
       * 当部署一个本地 Rush 项目，通常将过滤 .npmignore 中内容，所以 Rush
       * 只会复制哪些被 "npm pack" 打包的文件。设定 "includeNpmIgnoreFiles"
       * 为 true 会禁止掉这些过滤，以至于所有文件都会被复制（诸如 "node_modules"
       * 等例外）。
       *
       * 该参数默认值为 false.
       */
      // "includeNpmIgnoreFiles": true,

      /**
       * 为了提高遗留包的后向兼容性，PNPm 会在 node_modules 中下载额外的链接
       * 来使得包可以引入没被声明的链接。某些情况下这种方式可能会创建双倍的链接。
       * 如果你的部署不需要这种变通方式，可以设定 "omitPnpmWorkaroundLinks"
       * 为 true 来避免创建额外的链接。
       *
       * 该参数默认值为 false.
       */
      // "omitPnpmWorkaroundLinks": true,

      /**
       * 指定创建部署目录时如何链接（符号连接，硬链接，或者 NTFS 链接）：
       *
       * - "default": 默认行为是创建文件时创建链接。
       * - "script": 写入一个名为 "create-links.js" 的 Node.js 脚本。执行时，这个脚本会创建 "deploy-metadata.json" 中描述的链接。
       * - "none": 什么都不做，稍后使用其他工具创建链接。
       */
      // "linkCreation": "script",

      /**
       * 一旦指定该参数，那么 "rush deploy" 会递归地将文件夹中的文件复制到
       * 部署的目标文件夹中 (common/deploy). 这可以用来提供额外的配置文件
       * 或者部署时所需的脚本。该路径相对于仓库根目录。
       */
      //  "folderToCopy": "repo-tools/assets/deploy-config",

      /**
       * 自定义 Rush 项目在部署阶段如何处理。
       */
      "projectSettings": [
        // {
        //   /**
        //    * 项目的包名，必须在 rush.json 中声明。
        //    */
        //   "projectName": "@my-scope/my-project",
        //
        //   /**
        //    * 一系列与该项目一起部署的 本地 项目（除了 package.json
        //    * dependencies)。指定在 rush.json 中声明的完整包名。
        //    */
        //   "additionalProjectsToInclude": [
        //     // "@my-scope/my-project2"
        //   ],
        //
        //   /**
        //    * 当部署一个项目时，其包含的依赖通常基于 package.json 中的
        //    * "dependencies", "peerDependencies" 和 "optionalDependencies"
        //    *  字段自动决定，受制于 "includeDevDependencies" 等部署设置。
        //    * 然而，当某些信息不准确时，可以使用 "additionalDependenciesToInclude"
        //    * 来在这个列表中加更多的包  However, in cases where
        //    *
        //    * 这个列表包含了 Rush 安装，Node.js 模块解析的所有包。
        //    * 如果指向本地 Rush 项目， "additionalProjectsToInclude"
        //    * 字段不会递归地应用。
        //    */
        //   "additionalDependenciesToInclude": [
        //     // "@rushstack/node-core-library"
        //   ],
        //
        //   /**
        //    * 此设置可以防止部署特定的依赖。它只会过滤项目中 package.json
        //    * 中明确声明的依赖关系。不会影响通过 "additionalProjectsToInclude"
        //    * "additionalDependenciesToInclude" 添加的依赖，也不会影响见解
        //    * 依赖。
        //    *
        //    * "*" 用于匹配任意字符。例如，如果你的项目将依赖打包，那么指定
        //    *  "dependenciesToExclude": [ "*" ] 排除 package.json
        //    * 中的所有依赖。
        //    */
        //   "dependenciesToExclude": [
        //     // "@types/*"
        //   ]
        // }
      ]
    }

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/environment_vars/index.html b/zh-cn/pages/configs/environment_vars/index.html index 640b32c3..6d716465 100644 --- a/zh-cn/pages/configs/environment_vars/index.html +++ b/zh-cn/pages/configs/environment_vars/index.html @@ -6,14 +6,14 @@ 环境变量 | Rush - +
    Rush StackShopBlogEvents

    环境变量

    Rush 的环境变量可以通过终端环境变量来定制：

    如果该变量设定为 true, Rush 会使用绝对路径创建符号链接而不是相对路径。当仓库被移动时，或者仓库的部分内容被移动到沙盒时，该参数可能会很有用。

    RUSH_ALLOW_UNSUPPORTED_NODEJS​

    如果该变量设定为 true, 当运行的 Node 版本不符合 rush.json 中 odeSupportedVersionRange 字段指定的范围时，Rush 不会失败。

    RUSH_BUILD_CACHE_CREDENTIAL（实验性）​

    该环境变量用于 构建缓存 这个实验性的功能。

    配置后将会给远端的构建缓存提供一个凭证。这个凭证可以被缓存或覆盖。

    如果使用 Azure Blob Storage, 在序列化的参数重必须有一个 SAS 口令。关于其更多细节可以参考这篇文章。

    RUSH_BUILD_CACHE_ENABLED （实验性）​

    该环境变量用于 构建缓存 这个实验性的功能。

    覆盖定义在 build-cache.json 中的 buildCacheEnabled 值。这个环境变量必须是 1（表示 true）或者 0（表示 false）。如果没有配置构建缓存，那么该环境变量将被忽略。

    RUSH_BUILD_CACHE_WRITE_ALLOWED（实验性）​

    该环境变量用于 构建缓存 这个实验性的功能。

    覆盖定义在 build-cache.json 中的 isCacheWriteAllowed 值。这个环境变量必须是 1（表示 true）或者 0（表示 false）。如果没有配置构建缓存，那么该环境变量将被忽略。

    RUSH_DEPLOY_TARGET_FOLDER​

    该环境变量用于给 rush deploy 指令指定 --target-folder 参数。

    RUSH_GIT_BINARY_PATH​

    显式的指定 Rush 执行时候的 Git 执行文件的路径。

    RUSH_GLOBAL_FOLDER​

    覆盖了 Rush 中的 ~/.rush 全局目录的路径，它用于存储临时文件。

    为了避免并发问题和兼容性问题，Rush 中的大部分临时文件都是存储在仓库内每个项目中的独立目录中。然而，一小部分文件（例如 @microsoft/rush-lib 引擎和包管理器）被存储在全局文件夹下来加速安装。在 POSIX 风格的操作系统上的默认路径为 ~/.rush, 在 Windows 上的默认路径为 C:\Users\YourName.（POSIX 是 IEEE 公司的一个商标）。

    使用 RUSH_GLOBAL_FOLDER 可以指定不同的目录路径，如果 Windows 租政策禁止安装在用户目录时，该环境变量很有用。

    RUSH_INVOKED_FOLDER​

    当 Rush 执行脚本时，有时候需要改变工作目录，例如从一个项目文件到仓库根目录。起初的工作目录（Rush 命令被调用的目录）被 子进程的 RUSH_INVOKED_FOLDER 环境变量赋值，以便在脚本中按需使用。RUSH_INVOKED_FOLDER 与包管理器执行生命周期脚本时的 INIT_CWD 相同。

    RUSH_PARALLELISM​

    约定构建期间最大的并行进程数，更多信息可以参考 rush build 的 --parallelism 参数的命令行帮助。

    RUSH_PNPM_STORE_PATH​

    当使用 pnpm 作为包管理器时，该变量可以用于配置 pnpm 使用的存储目录。

    如果使用相对路径，那么存储路径将被解析为相对于进程当前工作目录。推荐使用绝对路径。

    RUSH_PREVIEW_VERSION​

    该命令变量可以覆盖版本选择器将要安装的 Rush 的版本。默认值由 rushVersion 字段来确定。

    例如，如果你想在升级前尝试不同版本的 Rush, 你可以这样做：

    $ set RUSH_PREVIEW_VERSION=5.0.0-dev.25
    $ rush install

    RUSH_TEMP_FOLDER​

    该变量覆盖了 Rush 的临时目录。默认值是仓库根目录下的 common/temp。

    RUSH_VARIANT​

    该变量设定了当安装和链接包依赖时 Rush 使用的安装变种。

    更多信息可以参考安装变种。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/experiments_json/index.html b/zh-cn/pages/configs/experiments_json/index.html index 4810f039..c864d2e1 100644 --- a/zh-cn/pages/configs/experiments_json/index.html +++ b/zh-cn/pages/configs/experiments_json/index.html @@ -6,13 +6,13 @@ experiments.json | Rush - +
    Rush StackShopBlogEvents

    experiments.json

    这是 rush init 生成的模版下的 experiments.json 文件：

    common/config/rush/experiments.json

    /**
     * 该配置文件允许仓库开启或禁止某些实验性的功能。
     * 更多信息可以参考 Rush 官网： https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/experiments.schema.json",

      /**
       * Rush 5.14.0 改善了增量构建，它会忽略 pnpm-lock.json 文件中的一些虚假变化。
       * 该优化默认开启，如果你遇到了 "rush build" 忽略构建某些项目的问题，请开启一个
       * Github issue, 临时的解决方法是取消这行的注释来恢复当 package.json 变化时的
       * 旧行为。
       */
      /*[LINE "HYPOTHETICAL"]*/ "legacyIncrementalBuildDependencyDetection": true,

      /**
       * 默认情况下，'rush install' 传给 "pnpm install" 带有 --no-prefer-frozen-lockfile 参数。
       * 设定该值为 true 会传入 '--frozen-lockfile' 进而实现更快的下载。
       */
      /*[LINE "HYPOTHETICAL"]*/ "usePnpmFrozenLockfileForRushInstall": true,

      /**
       * 默认情况下， 'rush update' 传给 "pnpm install" 带有 --no-prefer-frozen-lockfile 参数
       * 设定该值为 true 会传入  '--prefer-frozen-lockfile' 来替换最小 shrinkwrap 变动。
       */
      /*[LINE "HYPOTHETICAL"]*/ "usePnpmPreferFrozenLockfileForRushUpdate": true,

      /**
       * 使用 'preventManualShrinkwrapChanges' 选项限制哈希值，使其只包括对外部依赖。
       * 该参数用于允许项目之间的增加/删除已经存在的依赖版本引用不会导致哈希变化。
       */
      /*[LINE "HYPOTHETICAL"]*/ "omitImportersFromPreventManualShrinkwrapChanges": true,

      /**
       * 若该值为 true, 临时项目的压缩文件的头信息的 chmod 字段不会被规范化。
       * 规范化可以帮助压缩文件在不同平躺上保持一致。
       */
      /*[LINE "HYPOTHETICAL"]*/ "noChmodFieldInTarHeaderNormalization": true
    }
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/npmrc-publish/index.html b/zh-cn/pages/configs/npmrc-publish/index.html index 0e2c5a11..3c3d4f49 100644 --- a/zh-cn/pages/configs/npmrc-publish/index.html +++ b/zh-cn/pages/configs/npmrc-publish/index.html @@ -6,13 +6,13 @@ .npmrc-publish | Rush - +
    Rush StackShopBlogEvents

    .npmrc-publish

    这是 rush init 为 monorepo 生成的模版下的 .npmrc-publish 文件：

    common/config/rush/.npmrc-publish

    # 该配置文件与 common/config/rush/.npmrc, 除了 .npmrc-publish 文件适用于 "rush publish" 指令，因为
    # 发布时可能需要不同于其他操作的凭据和源。
    #
    # this avoids problems that would otherwise result due to a missing variable being replaced by
    # an empty string.
    # 在调用包管理器之前，Rush 将复制此文件到 "common/temp/publish-home/.npmrc"，然后暂时架将该文件夹映射为用户的
    # “主目录”。这使得在每个发布的项目中应用相同的设置。复制的文件将忽略在会话中没有定义的环境变量，这是为了避免由于空字符
    # 串而导致的变量缺失的问题。
    #
    #
    # * * * 安全警告 * * *
    #
    # 不建议在机器上存储身份验证令牌，因为其他无关进程可能会读取文件。同样，该文件也可能永久存储，例如如果机器断电。
    # 更安全的方式是通过环境变量来传递口令，可以通过 ${} 扩展引用到 .npmrc 中。例如：
    #
    #   //registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}
    #

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/npmrc/index.html b/zh-cn/pages/configs/npmrc/index.html index 781b8aee..80bc9efb 100644 --- a/zh-cn/pages/configs/npmrc/index.html +++ b/zh-cn/pages/configs/npmrc/index.html @@ -6,13 +6,13 @@ .npmrc | Rush - +
    Rush StackShopBlogEvents

    .npmrc

    这是 rush init 为 monorepo 生成的模版下的 .npmrc 文件：

    common/config/rush/.npmrc

    # Rush 使用该文件来配置安装阶段的 NPM 源，它可以用 PNPM，NPM 或者 Yarn。它被诸如 "rush install",
    # "rush update"，"install-run.js" 脚本等使用。
    #
    # 注意： "rush publish" 命令使用 .npmrc-publish 文件。
    #
    # 在调用包管理器之前，Rush 会拷贝该文件到执行安装命令的目录中。拷贝的文件会忽略没有在该会话中定义的环境变量；
    # 这避免了一些因为缺少变量而导致的问题。
    #
    # * * * 安全警告 * * *
    #
    # 不建议在机器上存储身份验证令牌，因为其他无关进程可能会读取文件。同样，该文件也可能永久存储，例如如果机器断电。
    # 更安全的方式是通过环境变量来传递口令，可以通过 ${} 扩展引用到 .npmrc 中。例如：
    #
    #   //registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}
    #
    registry=https://registry.npmjs.org/
    always-auth=false

    .npmrc 文件优先​

    普通 Rush 操作执行如下查找：

    1. 为了支持不规范的情况，NPM 配置的环境变量优先于任何 .npmrc 配置。环境变量名以 npm_config_ 开头，例如设置 npm_config_registry 可以覆盖 .npmrc 中的 registry 设置。Rush 也可以接受 NPM 标准中不规范的命名，例如 npm_config_@example:registry。
    2. 通常的配置刚来自于 Rush 拷贝到工作目录的临时文件 .npmrc，这个文件拷贝自 common/config/rush/.npmrc，但是省略了很多没有定义的环境变量（解释如上）。对于大多数的操作，工作目录是 common/temp。
    3. 如果包管理器没有从方法 1 或方法 2 中找到配置项，将使用用户配置中的 ~/.npmrc。用户通常存储自己的身份验证令牌在这个文件中。

    以上规则同样适用于诸如 install-run.js 等辅助脚本。

    rush publish 使用独立的 .npmrc-publish 配置文件。详细请参考此文档。

    上述规则不适用于直接调用 Rush 以外的包管理器的情况。例如，从 shell 中调用 npm publish时，将按照包管理器的通常优先级寻找 .npmrc 文件。通常不鼓励在 Rush 仓库中执行上述行为。当执行上述行为时，你可能需要创建额外的 .npmrc 文件。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/pnpm-config_json/index.html b/zh-cn/pages/configs/pnpm-config_json/index.html index b891d20e..9f22ec5d 100644 --- a/zh-cn/pages/configs/pnpm-config_json/index.html +++ b/zh-cn/pages/configs/pnpm-config_json/index.html @@ -6,7 +6,7 @@ pnpm-config.json | Rush - + @@ -18,7 +18,7 @@ you must manually delete the "pnpmOptions" setting from rush.json and create the pnpm-config.json file.

    This is the template that rush init generates for pnpm-config.json:

    common/config/rush/pnpm-config.json

    /**
     * This configuration file provides settings specific to the PNPM package manager.
     * More documentation is available on the Rush website: https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/pnpm-config.schema.json",

      /**
       * If true, then `rush install` and `rush update` will use the PNPM workspaces feature
       * to perform the install, instead of the old model where Rush generated the symlinks
       * for each projects's node_modules folder.
       *
       * When using workspaces, Rush will generate a `common/temp/pnpm-workspace.yaml` file referencing
       * all local projects to install. Rush will also generate a `.pnpmfile.cjs` shim which implements
       * Rush-specific features such as preferred versions.  The user's `common/config/rush/.pnpmfile.cjs`
       * is invoked by the shim.
       *
       * This option is strongly recommended. The default value is false.
       */
      "useWorkspaces": true,

      /**
       * If true, then Rush will add the `--strict-peer-dependencies` command-line parameter when
       * invoking PNPM.  This causes `rush update` to fail if there are unsatisfied peer dependencies,
       * which is an invalid state that can cause build failures or incompatible dependency versions.
       * (For historical reasons, JavaScript package managers generally do not treat this invalid
       * state as an error.)
       *
       * PNPM documentation: https://pnpm.io/npmrc#strict-peer-dependencies
       *
       * The default value is false to avoid legacy compatibility issues.
       * It is strongly recommended to set `strictPeerDependencies=true`.
       */
      // "strictPeerDependencies": true,

      /**
       * Environment variables that will be provided to PNPM.
       */
      // "environmentVariables": {
      //   "NODE_OPTIONS": {
      //     "value": "--max-old-space-size=4096",
      //     "override": false
      //   }
      // },

      /**
       * Specifies the location of the PNPM store.  There are two possible values:
       *
       * - `local` - use the `pnpm-store` folder in the current configured temp folder:
       *   `common/temp/pnpm-store` by default.
       * - `global` - use PNPM's global store, which has the benefit of being shared
       *    across multiple repo folders, but the disadvantage of less isolation for builds
       *    (for example, bugs or incompatibilities when two repos use different releases of PNPM)
       *
       * In both cases, the store path can be overridden by the environment variable `RUSH_PNPM_STORE_PATH`.
       *
       * The default value is `local`.
       */
      // "pnpmStore": "global",

      /**
       * If true, then `rush install` will report an error if manual modifications
       * were made to the PNPM shrinkwrap file without running `rush update` afterwards.
       *
       * This feature protects against accidental inconsistencies that may be introduced
       * if the PNPM shrinkwrap file (`pnpm-lock.yaml`) is manually edited.  When this
       * feature is enabled, `rush update` will append a hash to the file as a YAML comment,
       * and then `rush update` and `rush install` will validate the hash.  Note that this
       * does not prohibit manual modifications, but merely requires `rush update` be run
       * afterwards, ensuring that PNPM can report or repair any potential inconsistencies.
       *
       * To temporarily disable this validation when invoking `rush install`, use the
       * `--bypass-policy` command-line parameter.
       *
       * The default value is false.
       */
      // "preventManualShrinkwrapChanges": true,

      /**
       * The "globalOverrides" setting provides a simple mechanism for overriding version selections
       * for all dependencies of all projects in the monorepo workspace.  The settings are copied
       * into the `pnpm.overrides` field of the `common/temp/package.json` file that is generated
       * by Rush during installation.
       *
       * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
       * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
       * and `globalOverrides` has lowest precedence.
       *
       * PNPM documentation: https://pnpm.io/package_json#pnpmoverrides
       */
      "globalOverrides": {
        // "example1": "^1.0.0",
        // "example2": "npm:@company/example2@^1.0.0"
      },

      /**
       * The `globalPeerDependencyRules` setting provides various settings for suppressing validation errors
       * that are reported during installation with `strictPeerDependencies=true`.  The settings are copied
       * into the `pnpm.peerDependencyRules` field of the `common/temp/package.json` file that is generated
       * by Rush during installation.
       *
       * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
       * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
       * and `globalOverrides` has lowest precedence.
       *
       * https://pnpm.io/package_json#pnpmpeerdependencyrules
       */
      "globalPeerDependencyRules": {
        // "ignoreMissing": ["@eslint/*"],
        // "allowedVersions": { "react": "17" },
        // "allowAny": ["@babel/*"]
      },

      /**
       * The `globalPackageExtension` setting provides a way to patch arbitrary package.json fields
       * for any PNPM dependency of the monorepo.  The settings are copied into the `pnpm.packageExtensions`
       * field of the `common/temp/package.json` file that is generated by Rush during installation.
       * The `globalPackageExtension` setting has similar capabilities as `.pnpmfile.cjs` but without
       * the downsides of an executable script (nondeterminism, unreliable caching, performance concerns).
       *
       * Order of precedence: `.pnpmfile.cjs` has the highest precedence, followed by
       * `unsupportedPackageJsonSettings`, `globalPeerDependencyRules`, `globalPackageExtensions`,
       * and `globalOverrides` has lowest precedence.
       *
       * PNPM documentation: https://pnpm.io/package_json#pnpmpackageextensions
       */
      "globalPackageExtensions": {
        // "fork-ts-checker-webpack-plugin": {
        //   "dependencies": {
        //     "@babel/core": "1"
        //   },
        //   "peerDependencies": {
        //     "eslint": ">= 6"
        //   },
        //   "peerDependenciesMeta": {
        //     "eslint": {
        //       "optional": true
        //     }
        //   }
        // }
      },

      /**
       * The `globalNeverBuiltDependencies` setting suppresses the `preinstall`, `install`, and `postinstall`
       * lifecycle events for the specified NPM dependencies.  This is useful for scripts with poor practices
       * such as downloading large binaries without retries or attempting to invoke OS tools such as
       * a C++ compiler.  (PNPM's terminology refers to these lifecycle events as "building" a package;
       * it has nothing to do with build system operations such as `rush build` or `rushx build`.)
       * The settings are copied into the `pnpm.neverBuiltDependencies` field of the `common/temp/package.json`
       * file that is generated by Rush during installation.
       *
       * PNPM documentation: https://pnpm.io/package_json#pnpmneverbuiltdependencies
       */
      "globalNeverBuiltDependencies": [
        // "fsevents"
      ],

      /**
       * The `globalAllowedDeprecatedVersions` setting suppresses installation warnings for package
       * versions that the NPM registry reports as being deprecated.  This is useful if the
       * deprecated package is an indirect dependency of an external package that has not released a fix.
       * The settings are copied into the `pnpm.allowedDeprecatedVersions` field of the `common/temp/package.json`
       * file that is generated by Rush during installation.
       *
       * PNPM documentation: https://pnpm.io/package_json#pnpmalloweddeprecatedversions
       *
       * If you are working to eliminate a deprecated version, it's better to specify `allowedDeprecatedVersions`
       * in the package.json file for individual Rush projects.
       */
      "globalAllowedDeprecatedVersions": {
        // "request": "*"
      },

      /**
       * (USE AT YOUR OWN RISK)  This is a free-form property bag that will be copied into
       * the `common/temp/package.json` file that is generated by Rush during installation.
       * This provides a way to experiment with new PNPM features.  These settings will override
       * any other Rush configuration associated with a given JSON field except for `.pnpmfile.cjs`.
       *
       * USAGE OF THIS SETTING IS NOT SUPPORTED BY THE RUSH MAINTAINERS AND MAY CAUSE RUSH
       * TO MALFUNCTION.  If you encounter a missing PNPM setting that you believe should
       * be supported, please create a GitHub issue or PR.  Note that Rush does not aim to
       * support every possible PNPM setting, but rather to promote a battle-tested installation
       * strategy that is known to provide a good experience for large teams with lots of projects.
       */
      "unsupportedPackageJsonSettings": {
        // "dependencies": {
        //   "not-a-good-practice": "*"
        // },
        // "scripts": {
        //   "do-something": "echo Also not a good practice"
        // },
        // "pnpm": { "futurePnpmFeature": true }
      }
    }
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/pnpmfile_cjs/index.html b/zh-cn/pages/configs/pnpmfile_cjs/index.html index aa9ccfb7..548aa6fe 100644 --- a/zh-cn/pages/configs/pnpmfile_cjs/index.html +++ b/zh-cn/pages/configs/pnpmfile_cjs/index.html @@ -6,14 +6,14 @@ .pnpmfile.cjs | Rush - +
    Rush StackShopBlogEvents

    .pnpmfile.cjs

    This is the template that rush init generates for the monorepo pnpmfile.js file:

    common/config/rush/.pnpmfile.cjs

    'use strict';

    /**
     * When using the PNPM package manager, you can use pnpmfile.js to workaround
     * dependencies that have mistakes in their package.json file.  (This feature is
     * functionally similar to Yarn's "resolutions".)
     *
     * For details, see the PNPM documentation:
     * https://pnpm.js.org/docs/en/hooks.html
     *
     * IMPORTANT: SINCE THIS FILE CONTAINS EXECUTABLE CODE, MODIFYING IT IS LIKELY TO INVALIDATE
     * ANY CACHED DEPENDENCY ANALYSIS.  After any modification to pnpmfile.js, it's recommended to run
     * "rush update --full" so that PNPM will recalculate all version selections.
     */
    module.exports = {
      hooks: {
        readPackage
      }
    };

    /**
     * This hook is invoked during installation before a package's dependencies
     * are selected.
     * The `packageJson` parameter is the deserialized package.json
     * contents for the package that is about to be installed.
     * The `context` parameter provides a log() function.
     * The return value is the updated object.
     */
    function readPackage(packageJson, context) {
      // // The karma types have a missing dependency on typings from the log4js package.
      // if (packageJson.name === '@types/karma') {
      //  context.log('Fixed up dependencies for @types/karma');
      //  packageJson.dependencies['log4js'] = '0.6.38';
      // }

      return packageJson;
    }
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/rush-plugin-manifest_json/index.html b/zh-cn/pages/configs/rush-plugin-manifest_json/index.html index ce774f18..fdd3368e 100644 --- a/zh-cn/pages/configs/rush-plugin-manifest_json/index.html +++ b/zh-cn/pages/configs/rush-plugin-manifest_json/index.html @@ -6,14 +6,14 @@ rush-plugin-manifest.json (experimental) | Rush - +
    Rush StackShopBlogEvents

    rush-plugin-manifest.json (experimental)

    This is the template for the rush-plugin-manifest.json file that is used when creating a Rush plugin.

    <your plugin project>/rush-plugin-manifest.json

    /**
     * This file defines the Rush plugins that are provided by this package.
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush-plugin-manifest.schema.json",

      /**
       * An array of one or more plugin definitions provided by this NPM package.
       *
       * For more granular installations, it is recommended for plugins to be implemented by an
       * NPM package that does try to serve other roles such as providing APIs or command-line binaries.
       * The package name should start with "rush-".  The name should end with "-plugin" or "-plugins".
       * For example: "@scope/rush-business-policy-plugin"
       */
      "plugins": [
        {
          /**
           * (Required) The name of the plugin.  The plugin name must be comprised of letters and numbers
           * forming one or more words that are separated by hyphens.  Note that if the plugin has a
           * JSON config file, that filename will be the same as the plugin name.  See "optionsSchema" below
           * for details.
           *
           * If the manifest defines exactly one plugin, then it is suggested to reuse the name from the
           * NPM package.  For example, if the NPM package is "@scope/rush-business-policy-plugin"
           * then the plugin name might be "business-policy" and with config file "business-policy.json".
           */
          "pluginName": "example",

          /**
           * (Required) Provide some documentation that summarizes the problem solved by this plugin,
           * how to invoke it, and what operations it performs.
           */
          "description": "An example plugin",

          /**
           * (Optional) A path to a JavaScript code module that implements the "IRushPlugin" interface.
           * This module can use the "@rushstack/rush-sdk" API to register handlers for Rush events
           * and services.  The module path is relative to the folder containing the "package.json" file.
           */
          // "entryPoint": "lib/example/RushExamplePlugin.js",

          /**
           * (Optional) A path to a "command-line.json" file that defines Rush command line actions
           * and parameters contributed by this plugin.  This config file has the same JSON schema
           * as Rush's "common/config/rush/command-line.json" file.
           */
          // "commandLineJsonFilePath": "lib/example/command-line.json",

          /**
           * (Optional) A path to a JSON schema for validating the config file that end users can
           * create to customize this plugin's behavior.  Plugin config files are stored in the folder
           * "common/config/rush-plugins/" with a filename corresponding to the "pluginName" field
           * from the manifest.  For example: "common/config/rush-plugins/business-policy.json"
           * whose schema is "business-policy.schema.json".
           */
          // "optionsSchema": "lib/example/example.schema.json",

          /**
           * (Optional) A list of associated Rush command names such as "build" from "rush build".
           * If specified, then the plugin's "entryPoint" code module be loaded only if
           * one of the specified commands is invoked.  This improves performance by avoiding
           * loading the code module when it is not needed.  If "associatedCommands" is
           * not specified, then the code module will always be loaded.
           */
          // "associatedCommands": [ "build" ]
        }
      ]
    }

    See also​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/rush-plugins_json/index.html b/zh-cn/pages/configs/rush-plugins_json/index.html index 25ca530a..cf6ee1ce 100644 --- a/zh-cn/pages/configs/rush-plugins_json/index.html +++ b/zh-cn/pages/configs/rush-plugins_json/index.html @@ -6,14 +6,14 @@ rush-plugins.json (experimental) | Rush - +
    Rush StackShopBlogEvents

    rush-plugins.json (experimental)

    This is the template for the rush-plugins.json file that is used to enable Rush plugins.

    common/config/rush/command-line.json

    /**
     * This configuration file manages Rush's plugin feature.
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush-plugins.schema.json",
      "plugins": [
        /**
         * Each item configures a plugin to be loaded by Rush.
         */
        // {
        //   /**
        //    * The name of the NPM package that provides the plugin.
        //    */
        //   "packageName": "@scope/my-rush-plugin",
        //
        //   /**
        //    * The name of the plugin.  This can be found in the "pluginName"
        //    * field of the "rush-plugin-manifest.json" file in the NPM package folder.
        //    */
        //   "pluginName": "my-plugin-name",
        //
        //   /**
        //    * The name of a Rush autoinstaller that will be used for installation, which
        //    * can be created using "rush init-autoinstaller".  Add the plugin's NPM package
        //    * to the package.json "dependencies" of your autoinstaller, then run
        //    * "rush update-autoinstaller".
        //    */
        //   "autoinstallerName": "rush-plugins"
        // }
      ]
    }

    See also​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/rush-project_json/index.html b/zh-cn/pages/configs/rush-project_json/index.html index 1d0fa388..e112ea06 100644 --- a/zh-cn/pages/configs/rush-project_json/index.html +++ b/zh-cn/pages/configs/rush-project_json/index.html @@ -6,13 +6,13 @@ rush-project.json | Rush - +
    Rush StackShopBlogEvents

    rush-project.json

    rush-project.json 是可选的配置文件，该文件通过 rig 包 提供。

    <your project>/config/rush-project.json

    /**
     * "config/rush-project.json" 文件用来给仓库内的项目单独配置 Rush-specific
     * 更多信息可以参考 Rush 官网： https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush-project.schema.json",

      /**
       * 可选参数，指定另一个 JSON 配置文件，当前文件继承自该文件。这提供了一种在多个项目内
       * 共享配置文件的方法，
       */
      // "extends": "my-rig/profiles/default/config/rush-project.json",

      /**
       * 指定工具链写入输出文件的目。启用后，Rush 构建缓存将从缓存中
       * 恢复这个文件。
       *
       * 这些字符串是根目录下的文件名，这些文件不应该被 Git 追踪。
       * 它们不能包含符号连接。
       */
      "projectOutputFolderNames": [
        // "lib", "dist"
      ],

      /**
       * 配置构建缓存。
       */
      "buildCacheOptions":{
        /**
         * 选择性地禁用项目构建缓存，选中的项目将不能从缓存中恢复。
         *
         * 如果项目的构建脚本与缓存有冲突，那么可以使用这个方法解决。
         * 例如在项目文件夹外写文件。在可能的情况下，更好的方法是
         * 改进构建脚本，使其与缓存兼容。
         */
        // "disableBuildCache": true,

        /**
         * 对 Rush 命令的缓存进行细粒度的控制。
         */
        "optionsForCommands": [
        //   {
        //     /**
        //      * Rush 指令名, 定义在 custom-commands.json 文件中
        //      */
        //     "name": "my-command",
        //
        //     /**
        //      * 选择性地禁用项目构建缓存，选中的项目将不能从缓存中恢复。

        //      *
        //      * 如果项目的构建脚本与缓存有冲突，那么可以使用这个方法解决。
        //      * 例如在项目文件夹外写文件。在可能的情况下，更好的方法是
        //      * 改进构建脚本，使其与缓存兼容。
        //      */
        //     "disableBuildCache": true
        //   }
        ]
      }
    }

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/rush_json/index.html b/zh-cn/pages/configs/rush_json/index.html index 1d164b79..c7df3157 100644 --- a/zh-cn/pages/configs/rush_json/index.html +++ b/zh-cn/pages/configs/rush_json/index.html @@ -6,13 +6,13 @@ rush.json | Rush - +
    Rush StackShopBlogEvents

    rush.json

    这是 rush init 生成的模版下的 rush.json 文件（在项目根目录下）：

    <repo root>rush.json

    /**
     * 这是 Rush 的主要配置文件。
     * 更多信息可以参考 Rush 官网： https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",

      /**
       * （必须）指定仓库内 Rush 引擎的版本。
       * Rush 的“版本选择”功能可以确保无论全局安装的哪个版本，都会在使用时用指定的版本。
       *
       * common/scripts/install-run-rush.js 也会使用这个版本。
       *
       * 注意：如果你升级了 Rush 的主版本，那么你应该所有 Rush 配置文件中替换 "$schema" 字段中的 "v5". 它可以在诸如 VSCode 的编辑器内确保 tab 补全、错误捕获等功能正确运行。
       */
      "rushVersion": "5.40.0",

      /**
       * 下面的字段选定了使用哪个包管理器及其版本。
       * Rush 会在自己的本地安装包管理器的副本，以确保构建过程与本地环境的工具完全隔离。
       *
       * 选择 "pnpmVersion", "npmVersion", 或 "yarnVersion" 中一个，可以查阅
       * Rush 文档来获取更多细节。
       */
      "pnpmVersion": "5.15.2",

      // "npmVersion": "4.5.0",
      // "yarnVersion": "1.9.4",

      /**
       * 当使用 PNPM 时的选项。
       */
      "pnpmOptions": {
        /**
         * PNPM 存储的位置，这里有两个选择：
         *
         * - "local" - 默认使用临时文件夹 "common/temp/pnpm-store" 中的 "pnpm-store" 目录。
         * - "global" - 使用 PNPM 的全局存储，其优点是可以在多个仓库中共享，缺点是构建的隔离性较差（例如，当两个仓库使用不同版本的 PNPM 时，会出现 bug 或兼容问题)。
         *
         * RUSH_PNPM_STORE_PATH 可以重写使用哪个目录来存储
         *
         * 在所有情况下，存储路径将会被环境变量 RUSH_PNPM_STORE_PATH 所覆盖。
         *
         * 默认值为 "local".
         */
        // "pnpmStore": "local",

        /**
         * 若为 true,  Rush 调用 pnpm 会增加 "--strict-peer-dependencies" 参数。
         * 如果不满足同级依赖时，此时 "rush install" 会执行失败。
         * (由于历史原因，JavaScript 的包管理器不会视作无效状态为一个错误）
         *
         * 默认值为 false 来避免避免的兼容性问题，强烈推荐设定 strictPeerDependencies=true.
         */
        // "strictPeerDependencies": true,

        /**
         * 该配置项用于指定安装期间的版本选择策略。
         *
         * 该功能需要 PNPM 的版本新于 3.1, 它对应了 PNPM 中 "--resolution-strategy"
         * 的选项。可选的值为 "fast" 和 "fewer-dependencies". PNPM 的默认值为 "fast"
         * 但是不兼容某些库，例如 DefinitelyTyped 中的 "@types" 库。Rush 默认采用了
         * "fewer-dependencies", 这会导致 PNPM 在某个版本已经安装的情况下不再安装新版本。
         * 这与 NPM 算法类似。
         *
         * 修改完该字段后，建议执行 "rush update --full" 来使得包管理器重新计算版本。
         */
        // "resolutionStrategy": "fast",

        /**
         * 如果设定为 true, 当 PNPM shrinkwrap 文件变动后没有执行 "rush update",
         * 会导致 `rush install` 抛出一个错误。
         *
         * 该功能可以防止 pnpm 的 shrinkwrap 文件("pnpm-lock.yaml") 手动修改后导致
         * 的不一致的问题。开启该功能后，"rush update" 会把哈希值作为注释附加到 shrinkwrap
         * 文件中。之后 "rush update" 和 "rush install" 会校验哈希值。注意，这不会
         * 禁止手动修改，只需要执行 "rush update" 后确保 PNPM 能报告或修复潜在的不一致。
         *
         * 使用 "--bypass-policy" 可以暂时在调用 "rush install" 时关闭校验。
         *
         * 默认值为 false.
         */
        // "preventManualShrinkwrapChanges": true,

        /**
         * 若为 true, `rush install` 会使用 PNPM 的 workspace 功能。
         *
         * 该功能使用  PNPM 来执行安装。当使用 workspace 时，Rush 会生成 "pnpm-workspace.yaml"
         * 文件，它引用了本地所有安装的项目。
         * Rush 会生成 "pnpmfile.js" 来支持优先版本功能。当安装时，pnpmfile
         * 被用来替换依赖版本中的较小的子集。如果优先版本并不是原有版本的子集，那么会保持原状。再次之前，
         * 仓库内 pnpmfile.js（如果存在）将被调用来修改依赖。
         *
         * This option is experimental. 默认值为 false.
         */
        // "useWorkspaces": true
      },

      /**
       * 老版本的 Node.js 或许缺失所需功能，其他版本的功能可能会有 bug.
       * 尤其是“最新”版本不是长期支持的版本，可能出现倒退。
       *
       * 指定语义化版本来确保开发者使用恰当的 Node.js 版本。
       *
       * LTS 日程: https://nodejs.org/en/about/releases/
       * LTS 版本: https://nodejs.org/en/download/releases/
       */
      "nodeSupportedVersionRange": ">=12.13.0 <13.0.0 || >=14.15.0 <15.0.0",

      /**
       * Node.js 奇数位的版本是实验版本。偶数位的版本在成为 LTS 前，有六个月的稳定期。
       * 例如, 8.9.0 是 Node.js 8 的第一个 LTS 版本，由于 bug 不推荐生产环境下使
       * 用 LTS 前的版本，这些 bug 可能导致 Rush 出现问题。
       *
       * 正常情况下 Rush 一旦检测到 LTS 前的 Node 版本将会发出警告。
       * 如果你正在测试 LTS 前的版本，可以设置该选项来关闭警告
       *
       */
      // "suppressNodeLtsWarning": false,

      /**
       * 如果你希望依赖版本是一致的, 可以关闭注释，它类似于在以下指令前
       * 执行 "rush check".
       *
       *   rush install, rush update, rush link, rush version, rush publish
       *
       * 有时你想要开启该功能，但是需要某个包使用不同的版本，则可以使用
       * common-versions.json 中的 "allowedAlternativeVersions".
       */
      // "ensureConsistentVersions": true,

      /**
       * 如果项目目录不遵循一致的、可识别的模式，那么大型 monorepo 会令新人生畏。
       * 当系统允许文件树嵌套时，我们发现团队经常使用子目录来创建隔离的新项目。这阻止了
       * 协作与代码共享。
       *
       * Rush 开发者推荐使用“种类目录”模式，可构建的项目必须永远放到根目录下的第二层。
       * 父亲树扮演着种类的效果。它提供了一个划分相关项目的基本设施（例如："apps", "libraries",  "tools", "prototypes"），这同时鼓励团队将其项目使用统一的分类。限制成两层在初
       * 期看起来很严格，但当你有了 20 个目录，每个种类有 20 个项目后，这个范式可以轻松地
       * 支持大型项目。实践中，你会发现文件夹的层次结构偶尔需要重新平衡，但是如果这个过程非常痛苦，
       * 那么可能是你的开发风格不适合重构。重新组织种类应该是一个启发人心的讨论，它将人聚集在一起，
       * 同时也可能发现不好的代码习惯（例如，在不使用 Node.js 模块解析的情况下将文件饮用到其他项
       * 目中）。
       *
       * 默认是 projectFolderMinDepth=1 和 projectFolderMaxDepth=2.
       *
       * 为了移除这个限制，可以设定 projectFolderMinDepth=1, 同时
       * 设定 projectFolderMaxDepth 为一个更大的数字。
       */
      // "projectFolderMinDepth": 2,
      // "projectFolderMaxDepth": 2,

      /**
       * 如果 npmjs.com 源中醒了严格的包命名规则，但是早期并没有标准。
       * 一些遗留的包依旧使用非标准的包名，有时私有源也会允许这样。
       * 设定 "allowMostlyStandardPackageNames" 为 true 会降低 Rush 的
       * 包命名标准，会允许使用大写字母和未来可能放宽的规则，然而我们想要减少这
       * 些异常。许多流行的工具使用某些标点符号作为分隔符，是因为猜测它们永远不
       * 会出现在包名中，因此如果我们放松规则，很有可能出现非常混乱的问题。
       *
       * 默认值为 false.
       */
      // "allowMostlyStandardPackageNames": true,

      /**
       * 该功能帮助你审查和批准仓库内某些新引入的。例如，你也许担心许可证、
       * 代码质量、性能、或者叠加功能相同的库。在两个配置文件 "browser-approved-packages.json"
       * 和 "nonbrowser-approved-packages.json" 中可以跟踪审查情况。
       * 查看 Rush 的文档来获取更多细节。
       */
      // "approvedPackagesPolicy": {
      //   /**
      //    * 审查种类，例如：“这个库允许在原型中使用，但不允许在生产中使用”。
      //    *
      //    * 每个项目可以通过 rush.json 下 "project" 的 "reviewCategory"
      //    * 字段关联一个审查类别。审查行为被记录在
      //    * "common/config/rush/browser-approved-packages.json" 和
      //    * "nonbrowser-approved-packages.json" 文件中，它们会由 "rush
      //    * update" 自动生成。
      //    *
      //    * 对于你审查而言，指定任何颗粒度的种类都是合适的，或者你可以仅仅添
      //    * 加一个名为 "default" 的类别。
      //    */
      //   "reviewCategories": [
      //     // 一些示例类别:
      //     "production", // 生产模式下的项目
      //     "tools",      // 非生产模式，只是开发者的工具链
      //     "prototypes"  // 多数情况下应该被忽略的项目
      //   ],
      //
      //   /**
      //    * 一系列 NPM 包 scope 可以被排除在审查中。
      //    * 我们建议排出 TypeScript 的类型(@type), 因为如果它对应的代码包
      //    * 被批准，那么类型包也应该被批准。
      //    */
      //   // "ignoredNpmScopes": ["@types"]
      // },

      /**
       * 如果使用 Git 作为版本公知，那么该字段可以提供一些
       * 额外的功能。
       */
      "gitPolicy": {
        /**
         * 在一个大公司工作？ 疲惫于在工作中发现了 Git 提交中不专业的邮箱，诸如
         * "beer-lover@my-college.edu？ Rush 可以在开发者开始工作前校验
         * 邮箱。
         *
         * 定义一系列正则表达式的列表，它们表示允许的提交到 Git 上的邮箱格式。
         * 它们是不区分大小写的 JavaScript 正则。 例子：".*@example\.com"
         *
         * 重要： 由于正则表达式被编码为 JSON 字符串字面量，因此
         * 正则表达式中的转义字符需要两个反斜线，即 "\\.".
         */
        // "allowedEmailRegExps": [
        //   "[^@]+@users\\.noreply\\.github\\.com",
        //   "travis@example\\.org"
        // ],

        /**
         * 当 Rush 报告邮箱有问题时，这条通过可以包含一个推荐邮箱写法的示例
         * 确保它符合 allowedEmailRegExps 表达式。
         */
        // "sampleEmail": "mrexample@users.noreply.github.com",

        /**
         * "rush publish" 期间提交修改的提交信息
         *
         * 例如，如果你希望阻止这些提交触发 CI, 那么你可以配置你的系统
         * 遇到诸如 "[skip-ci]" 的特殊字符串来指示 CI 应该跳过，之后
         * 自定义的 Rush 消息中含有这个字符串。
         */
        // "versionBumpCommitMessage": "Applying package updates. [skip-ci]",

        /**
         * "rush version" 期间提交修改的提交信息
         *
         * 例如，如果你希望阻止这些提交触发 CI, 那么你可以配置你的系统
         * 遇到诸如 "[skip-ci]" 的特殊字符串来指示 CI 应该跳过，之后
         * 自定义的 Rush 消息中含有这个字符串。
         */
        // "changeLogUpdateCommitMessage": "Applying package updates. [skip-ci]"
      },

      "repository": {
        /**
         * Git 仓库的 URL, 被 "rush change" 使用来决定那个是你 PR 的基础分支。
         *
         * "rush change" 指令需要确定你的 PR 影响了哪些文件。
         * 如果你的 PR 中从主分支合并或 cherry-picked 了一些提交，那么这些提交
         * 将会被排除在 diff 中（因为它们属于别的 PR）。为了做到这点，Rush
         * 知道如何在 PR 中到照基础分支。这个信息不能从 Git 中单独获取，因为
         * "pull request" 不是 Git 的概念。理想情况是 Rush 使用了特定的协议
         * 来从诸如 Github, Azure DevOps 上获取这些信息。
         * 但为了简单，"rush change" 只是假设你的 PR 只是针对 rush.json 中的
         * repository.url 的仓库的主分支。如果你从 Github 上 "fork" 了一个
         * 仓库，那么该设定就不同于你的 PR 分支的仓库 URL, 此时 "rush change"
         * 会自动掉哟过 "git fetch" 来检索远程主分支的最新活动。
         *
         */
        // "url": "https://github.com/microsoft/rush-example",

        /**
         * 默认分支名，它告知 "rush change" 要与远程按个分支进行比较。
         * 默认值为 "main".
         */
        // "defaultBranch": "main",

        /**
         * 默认的远端。当 URL 没提供时候，
         * 它告知 "rush change" 要从哪个远端来进行比较。
         */
        // "defaultRemote": "origin"
      },

      /**
       * 事件钩子是指自定义的脚本。当指定事件发生时， Rush 会执行这些钩子。
       */
      "eventHooks": {
        /**
         * Rush install 发生前执行的一系列脚本。
         */
        "preRushInstall": [
          // "common/scripts/pre-rush-install.js"
        ],

        /**
         * Rush install 完成后执行的一系列脚本。
         */
        "postRushInstall": [],

        /**
        * Rush build 发生前执行的一系列脚本。
         */
        "preRushBuild": [],

        /**
          * Rush build 完成后执行的一系列脚本。
         */
        "postRushBuild": []
      },

      /**
       * 安装变种允许你维护一套平行的配置文件，它们可以用于以另一套依赖来构建整个仓库。
       * 例如，假设你将你所有的项目使用的一个重要框架的升级到新版本，但是在此期间你想要
       * 维持与旧版本的兼容性。此时，你也许想让你的 CI 两次校验整个仓库的构建产物：一次是
       * 旧版本，一次是新版本。
       *
       * Rush 的 "安装变种" 对应于以下文件夹的配置文件：
       *
       *   common/config/rush/variants/<variant_name>
       *
       * 变种文件夹包含一系列可供选择的 common-version.json 文件。其“优先版本”
       * 字段可以用来选择依赖的旧版本（在 package.json 中语义版本的范围内）
       * 执行 "rush install --variant <variant_name>". 来安装一个变量。
       *
       * 更多信息，可以参考 https://rushjs.io/pages/advanced/installation_variants/
       */
      "variants": [
        // {
        //   /**
        //    * 变种名。
        //    */
        //   "variantName": "old-sdk",
        //
        //   /**
        //    * 详实的描述
        //    */
        //   "description": "Build this repo using the previous release of the SDK"
        // }
      ],

      /**
       * Rush 可以匿名收集开发者日常数据，例如安装、构建和其他操作。你可以用它来识别工具链或
       * Rush 本身的问题。这些数据不会与微软共享。
       * 它会以 JSON 的形式被写入 common/temp 目录下。 你可以读写这些 JSON 文件并对其进行
       * 处理，这些处理脚本通常放到 "eventHooks" 中。
       */
      // "telemetryEnabled": false,

      /**
       * 允许热修复。该功能目前处于实验阶段，因此默认关闭。
       * 如果设定该属性，那么 'rush change' 只会允许被指定为“热修复”类型。该类型会
       * 在随后发布时使用到。
       */
      // "hotfixChangeEnabled": false,

      /**
       * （必须）Rush 中的项目清单
       *
       * Rush 不会使用通配符自动扫描项目，有以下原因：
       * 1. 深度优先搜索开销太大，尤其是需要重复收集列表时；
       * 2. 在带有缓存的 CI 机器上，搜索可能会遗漏掉之前构建中的文件；
       * 3. 集中式的管理所有项目以及其重要的元数据是很有用的。
       */
      "projects": [
        // {
        //   /**
        //    * 项目的 NPM 包名（必须与 package.json 匹配）
        //    */
        //   "packageName": "my-app",
        //
        //   /**
        //    * 项目的路径，相对于 rush.json 所在的目录而言。
        //    */
        //   "projectFolder": "apps/my-app",
        //
        //   /**
        //    * 可选的种类，它用于 "browser-approved-packages.json"
        //    * 和 "nonbrowser-approved-packages.json" 文件。该值必须
        //    * 是上文 "reviewCategories" 中定义的字符串。
        //    */
        //   "reviewCategory": "production",
        //
        //   /**
        //    * 本地项目列表，它们以 devDependencies 的形式出现，但是不能被被本地链接，
        //    * 因为它会创建一个循环依赖。相反，最后发布的版本将会被安装到公共目录下。
        //    */
        //   "cyclicDependencyProjects": [
        //     // "my-toolchain"
        //   ],
        //
        //   /**
        //    * 如果该值为 true, 那么项目将会被 "rush check" 忽略。
        //    * 默认值为 false.
        //    */
        //   // "skipRushCheck": false,
        //
        //   /**
        //    * 一个参数表明该项目是否需要被发布到 npm 上，它将影响到 Rush change
        //    * 和发布工作流，默认结果为 false.
        //    * 注意： "versionPolicyName" 和 "shouldPublish" 是二选一的，你不能
        //    * 同时定义这两个。
        //    */
        //   // "shouldPublish": false,
        //
        //   /**
        //    * 便于发布前对项目文件进行处理。
        //    *
        //    * 一旦指定，"publishFolder" 是项目子目录的相对路径。
        //    * "rush publish" 会发布子目录而不是项目目录。子目录必须包括
        //    * "package.json", 它通常是构建输出。
        //    */
        //   // "publishFolder": "temp/publish",
        //
        //   /**
        //    * 可选参数，是指项目的版本策略。版本策略定义在 "version-policies.json"
        //    * 文件内。可以查阅 "rush publish" 文档了解更多。
        //    * 注意： "versionPolicyName" 和 "shouldPublish" 是二选一的，你不能同时定义二者
        //    */
        //   // "versionPolicyName": ""
        // },
        //
        // {
        //   "packageName": "my-controls",
        //   "projectFolder": "libraries/my-controls",
        //   "reviewCategory": "production"
        // },
        //
        // {
        //   "packageName": "my-toolchain",
        //   "projectFolder": "tools/my-toolchain",
        //   "reviewCategory": "tools"
        // }
      ]
    }
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/version-policies_json/index.html b/zh-cn/pages/configs/version-policies_json/index.html index 99f97461..4ca30e09 100644 --- a/zh-cn/pages/configs/version-policies_json/index.html +++ b/zh-cn/pages/configs/version-policies_json/index.html @@ -6,13 +6,13 @@ version-policies.json | Rush - +
    Rush StackShopBlogEvents

    version-policies.json

    该文件是 rush init 生成的 version-policies.json 模板：

    common/config/rush/version-policies.json

    /**
     * 该配置文件用于使用 Rush 发布时的高级配置。
     * 更多信息可以参考 Rush 官网： https://rushjs.io
     */

    /**
     * 一系列版本策略的定义。“版本政策”是一个自定义的包，它会影响 "rush change",
     * "rush version", 和 "rush publish". 这个策略适用于在 rush.json 下指定了
     * "versionPolicyName" 字段的项目。
     */
    [
      // {
      //   /**
      //    * （必须） 表明版本政策的种类。
      //    * （"lockStepVersion" 或 "individualVersion"）
      //    *
      //    * "lockStepVersion" 模式是指项目将会使用 "lock-step versioning". 该策略
      //    * 适用于一组作为同一个产品的可选择组件的包。整套包是一期发布，并使用相同的 NPM
      //    * 版本号。当这组内的某个包依赖其他时，语义化版本通常被限制为单一版本。
      //    */
      //   "definitionName": "lockStepVersion",
      //
      //   /**
      //    * （必须）政策名将被用于 rush.json 下的 "versionPolicyName" 字段。
      //    * 该字段同样被用于命令行参数中，例如 "--version-policy" 和 "--to-version-policy".
      //    */
      //   "policyName": "MyBigFramework",
      //
      //   /**
      //    * （必须）当前版本。当前分支下，集合内的所有包应当都是当前版本，当版本号变化时候
      //    *  Rush 用此来决定下一个版本。
      //    * (不考虑 package.json 下 "version" 字段。)
      //    */
      //   "version": "1.0.0",
      //
      //   /**
      //    * （必须） 变更类型，适用于发布下一个版本。
      //    * 当在 Git 上创建发布分支时，该字段应当根据发布类型更新。
      //    *
      //    * 有效值： "prerelease", "release", "minor", "patch", "major"
      //    */
      //   "nextBump": "prerelease",
      //
      //   /**
      //    * （可选）一旦指定，集合内的所有包共享 CHANGELOG.md 文件。
      //    * 该文件存储了所有被指定为 "main" 的项目，这些项目属于该集合。
      //    *
      //    * 如果该文件被忽略，那么集合内的每个项目会维护单独的 CHANGELOG.md.
      //    */
      //   "mainProject": "my-app"
      // },
      //
      // {
      //   /**
      //    * （必须） 表明版本政策的种类。
      //    * （"lockStepVersion" 或 "individualVersion"）
      //    *
      //    * "individualVersion" 模式表明项目将使用“单独的版本”。
      //    * 这是典型的 NPM 模式，每个项目都有独立的版本号和 CHANGELOG.md 文件。
      //    * 尽管单个 CI 负责发包，但是它们没有任何特殊关系。版本变更会依照开发者
      //    * 回答的 "rush change" 的问题。
      //    */
      //   "definitionName": "individualVersion",
      //
      //   "policyName": "MyRandomLibraries",
      //
      //   /**
      //    * （可选）该属性确保集合内的所有包使用一个主版本号。例如因为相同的主版本分支。
      //    * 他还可以阻止人们不小心对 "major" 语义版本进行了不适当的更改。 "minor" 或
      //    * "patch" 版本会依据 "rush change" 来给每个变化的项目进行独立的更改。
      //    */
      //   "lockedMajor": 3,
      //
      //   /**
      //    * （可选）当使用 Rush 管理发布时, 默认使用 "rush change" 命令来为每个被修改
      //    * 的项目进行版本变更。这些变更会产生 CHANGELOG.md 文件。如果你授权你的 CHANGELOG.md
      //    * 由手动管理或者其他的方式，那么设定 "exemptFromRushChange" 为 true 来告诉  "rush
      //    * change" 忽略这些项目。
      //    */
      //   "exemptFromRushChange": false
      // }
    ];
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/configs/version_policies_json/index.html b/zh-cn/pages/configs/version_policies_json/index.html index 370d98be..f1828bed 100644 --- a/zh-cn/pages/configs/version_policies_json/index.html +++ b/zh-cn/pages/configs/version_policies_json/index.html @@ -6,13 +6,13 @@ version_policies_json | Rush - +
    Rush StackShopBlogEvents

    Redirecting...

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/contributing/index.html b/zh-cn/pages/contributing/index.html index 8aa33213..b3986ae3 100644 --- a/zh-cn/pages/contributing/index.html +++ b/zh-cn/pages/contributing/index.html @@ -6,13 +6,13 @@ 贡献 | Rush - +
    Rush StackShopBlogEvents

    贡献

    Rush 是在 Rush Stack 项目下进行开发：

         https://github.com/microsoft/rushstack

    在 rushjs.io-website 仓库中贡献文档。

    请阅读 Contributing 文档以获取更多关于构建 Rush 和提交 PR 的指南。

    相关的仓库目录是：

    测试 Rush 构建​

    一旦你完成了修复和构建了你的分支（就像贡献一文中描述的），你需要测试你的 Rush 构建。

    Rush 有一个版本选择器功能，它读取从 rush.json 中读取了 rushVersion, 之后自动下载并调用指定的引擎版本。因此如果我们启用你构建的 @microsoft/rush, 它将并不会执行你的代码。为了跳过这个版本选择器，我们需要直接调用 @microsoft/rush-lib 引擎：

    $ cd rushstack/libraries/rush-lib
    $ node ./lib/start.js --help

    如果你想从其他位置上更容易地调用你的测试构建，我们建议创建一个 testrush 命令。

    对于 Mac OS 或 Linux 系统的 Bash:

    # 用自己构建的rush-lib的完整路径来代替。
    alias testrush="node ~/git/rushstack/libraries/rush-lib/lib/start.js"

    对于 Windows, 可以创建一个 testrush.cmd 并将其加到系统路径 PATH:

    @ECHO OFF
    REM Substitute the full path to your own build of rush-lib:
    node "C:\Git\rushstack\apps\rush-lib\lib\start.js" %*

    调试 Rush​

    使用 VS Code 的调试器来调试 Rush 也是如此。创建一个如下的配置文件：

    rushstack/libraries/rush-lib/.vscode/launch.json

    {
      // Use IntelliSense to learn about possible attributes.
      // Hover to view descriptions of existing attributes.
      // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
      "version": "0.2.0",
      "configurations": [
        {
          "type": "node",
          "request": "launch",
          "name": "Debug Rush",
          "program": "${workspaceFolder}/lib/start.js",
          "args": [ "list", "--json" ],  // <====== 定义你自己的 Rush 命令
          "cwd": "(repo folder that you want to debug)"  // <===== 定义你的工作目录
        }
      ]
    }

    保存完上述文件后，在 VSCode 中点击 "View" --> "Run" 并选择 "Debug Rush" 配置。之后点击 "Run" --> "Start Debugging" 开始调试。调试器会正确地工作。

    不使用单元测试来构建​

    Rush 目前使用 gulp-core-build 来进行构建，它默认执行了单元测试，这将花费很长时间。你可以通过直接调用 gulp 来跳过它们。

    # 完整的构建 Rush 及其依赖，包括单元测试。
    $ rush build --to rush-lib --verbose

    # "rush-lib" 快速构建，没有单元测试。
    $ npm install -g gulp
    $ cd rushstack/libraries/rush-lib
    $ gulp build
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/developer/everyday_commands/index.html b/zh-cn/pages/developer/everyday_commands/index.html index 5b1d790d..9fc273d0 100644 --- a/zh-cn/pages/developer/everyday_commands/index.html +++ b/zh-cn/pages/developer/everyday_commands/index.html @@ -6,13 +6,13 @@ 日常用到的指令 | Rush - +
    Rush StackShopBlogEvents

    日常用到的指令

    日常的开发仅仅需要以下几个 Rush 指令：

    rush update​

    当 package.json 文件发生变化时，请务必运行 rush update, 换句话说：

    • 当从 git 上拉取新的更改（例如 git pull）后。

    • 当项目内 package.json 文件被手动修改后。

    • 当 common/config 目录下可能影响版本的文件（例如 pnpmfile.js, common-versions.json 等）被修改后。

    rush update 操作可能会改变 common/config 下的一些文件，当这些文件发生变化时，你需要通过 commit 到 Git 中，并在相应的 PR 中包含它们。若不确定是否需要 commit，执行 rush update 就可以了 —— 如果已经是最新的，则不需要等待！

    rush update 内做了些什么：

    1. Rush 检查或应用各种可能会改变 common/config 内文件的策略。

    2. Rush 会将所有项目内的 package.json 文件与仓库的公共 shrinkwrap 文件进行比较来检查是否有效。

    3. 若无效，则包管理工具会更新 shrinkwrap 文件。

    4. 无论如何，包管理工具都会将所有依赖安装到 common/temp/node_modules 目录下。

    5. 最后，Rush 会给每个项目下构建一个 node_modules 文件夹，该文件夹下内容通过符合链接到 common/temp/node_modules. （该操作等同于 rush link）

    shrinkwrap 文件是什么？

    需要项目中并没有将依赖指定为诸如 1.2.3 这样精确的版本，而是使用诸如 1.x 或者 ^1.2.3 这样语义化版本。语义化的版本意味着依赖安装时的最新版本，这种非确定性的策略存在一定问题：当依赖的库新版本发布时，周一建立分支周二便可能因此而失败，这就很让人抓狂。shrinkwrap 文件就解决了这个问题，它存储了一个完整的安装计划，并被会 Git 记录。

    shrinkwrap 文件在不同的 包管理器 中有不同的名字：shrinkwrap.yaml, npm-shrinkwrap.json 或者 yarn.lock 等。

    你可以观察到，CI 流水线中使用 rush install 来替代 rush update, 二者的不同点是 rush install 不会更新任何文件，相反，如果存在过失的数据，则会在 PR 上报错，并提示你执行 rush update 或者提示你 commit 其结果。（一些开发者为了防止 shrinkwrap 文件中不符合预期的更新，他们选择使用 rush install 当作常用指令，而不是 rush build）

    rush rebuild​

    一旦你拉取到最新的修改，那么就应该进行编译所有项目。rush rebuild 将给仓库内的所有项目执行一个完整的、清除式的构建。

    如果你的工具链支持增量构建，那么你可以执行 rush build 来构建那些变动过的项目。

    rushx​

    如果你仅仅想构建一个项目，那么可以使用 rushx 指令。你可以在对应的项目下运行 rushx 指令，rushx 指令与 npm run 的指令类似，但它输入更简单、报错提示更友好、同时还有命令行帮助信息。

    rush check​

    当编辑完 package.json 文件后，你可以执行 rush check 来检查多个项目是否依赖同一个库的不同版本，在 monorepo 环境下，这种行为是不可取的。许多仓库使用 rush check 作为 CI 的起始，此时如果你提交的 PR 中提交了依赖不同版本，他们会报错。

    rush change​

    如果你从事库会被 NPM 发布，那么你的仓库可能需要你在 PR 中添加相应的变更日志。如果没有添加，你的 PR 构建会在 rush change --verify 步骤失败。

    为了书写变更日志，首先需要把变动以 commit 的形式提交到 Git 中，之后在仓库下执行 rush change, 该指令会检查 Git 历史，并根据变动情况提示你为每个变化的项目书写更新日志。每一条日志会被存储在 common/changes 下的独立文件中。你应该把这些文件添加到 Git 中，以便于后续的提交。

    随后，Rush 的自动发布工作流会检查这些文件，以确定哪些包需要发布。它会删除这些文件，并将你的更新信息复制到包的 CHANGELOG.md 文件中。

    ⏵ 查看 更新日志编写 来获取更多写变更记录的提示。

    常见情况

    上面就是 Rush 的一些常用的指令。

    结合起来，日常的指令可能会像这样：

    # 从 Git 获取最新的代码
    $ git pull

    # 按需安装 NPM 包
    $ rush update

    # 清理并重新构建所有项目
    $ rush rebuild

    # 进入某个项目内
    $ cd ./my-project

    # 假设 package.json 内存在 "start" 指令。
    # (通过 "rushx" 来查看可用的命令)
    $ rushx start
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/developer/modifying_package_json/index.html b/zh-cn/pages/developer/modifying_package_json/index.html index f332f217..a604ffaf 100644 --- a/zh-cn/pages/developer/modifying_package_json/index.html +++ b/zh-cn/pages/developer/modifying_package_json/index.html @@ -6,13 +6,13 @@ 修改 package.json | Rush - +
    Rush StackShopBlogEvents

    修改 package.json

    如果你需要在项目中添加一个名为 "example-lib" 的依赖。如果没有使用 Rush，你可以这样做：

    # 请不要在 Rush 仓库内使用以下命令
    ~/my-repo$ cd apps/my-app
    ~/my-repo/apps/my-app$ npm install --save example-lib

    在 Rush 仓库内，你应该使用 rush add 命令：

    ~/my-repo$ cd apps/my-app

    # 在 "my-app" 项目中添加 "example-lib" 的依赖，随后会自动执行 "rush update"
    ~/my-repo/apps/my-app$ rush add --package example-lib

    rush add 命令也可以用来更新某个已有依赖的版本：

    # 将 "my-app" 中的 "example-lib" 版本更新为 "1.2.3"
    ~/my-repo/apps/my-app$ rush add --package example-lib@1.2.3

    # 或者将 "example-lib" 版本更新为 "^1.2.3"
    ~/my-repo/apps/my-app$ rush add --package example-lib@1.2.3 --caret


    # 这有一个更高级的示例：通过 NPM 源处查询兼容 "^1.2.0" 的最新语义化版本，然后将其添加为 "~1.5.3" 的依赖。
    #
    # 注意：当在命令行中指定符号字符时，请使用引号，避免与 shell 发生冲突。
    ~/my-repo/apps/my-app$ rush add --package "example-lib@^1.2.0"

    # 如果仓库内的其他项目正在使用 "example-lib", 可以一次性将其更新为 "1.2.3" 版本
    ~/my-repo/apps/my-app$ rush add --package example-lib@1.2.3 --make-consistent

    如果你想了解更多，可以查看rush add.

    提示：VS Code 内一个有趣的功能

    如果你正在使用 VSCode, 也可以直接编辑 package.json 文件，在 dependencies 或 depDependencies 下输入 "example-lib":, VS Code 将自动查询 NPM 源的版本，并提供补全建议。在某些情况下，这种方式比 rush add 更便捷。

    当然，如果你手动修改了 package.json, 随后记得执行 rush update.

    更新 NPM 包的版本​

    rush update --full 指令可以安装满足 package.json 的最新版本。然而，如果你想更新 package.json 文件中的版本到较新的版本，目前 Rush 还无法在全局范围内实现。

    npm-check-update 会升级 Rush 仓库中的单个项目下 package.json 内版本，记得随后执行 rush update（而不是 npm install)

    注意：PNPM workspace 已经推出, 启用此功能后，可以使用 pnpm update 指令进行批量更新。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/developer/new_developer/index.html b/zh-cn/pages/developer/new_developer/index.html index 5e6a184c..398221a3 100644 --- a/zh-cn/pages/developer/new_developer/index.html +++ b/zh-cn/pages/developer/new_developer/index.html @@ -6,13 +6,13 @@ 以开发者的身份开始 | Rush - +
    Rush StackShopBlogEvents

    以开发者的身份开始

    前提​

    为了使用 Rush, 首先需要 NodeJS, 我们推荐最新的长期维护版本，因为非稳定的 NodeJS 时常有一些 bugs, 你可以使用 nvm-windows 和 nvm (Mac/Linux) 安装，这样你就可以方便地切换到不同的 NodeJS 版本，这些版本可能会用于不同的项目。

    你也需要安装 Rush 本身，这非常简单，从你的 shell 或命令行窗口输入这个命令：

    $ npm install -g @microsoft/rush

    注意：如果上述命令由于你没有 NPM 全局权限安装失败，你可以查看修复你的 NPM 配置。

    为了查看 Rush 的命令行帮助，你可以输入：

    $ rush -h

    命令行帮助也被发布到命令参考内。

    一些细节​

    在我们开始之前，有一些重要的提示：

    1. Rush 仓库内不要使用某些指令​

    Rush 会在某个中心文件夹安装所有的依赖，之后使用符号链接给每个项目创建 "node_modules" 文件夹。

    不要使用包管理工具来安装或链接依赖。例如，npm run 会正常执行，但是诸如 npm install, npm update, npm link, npm dedupe 等命令会干扰 Rush 的符号链接，同样，对于其他包管理工具，也要避免使用 pnpm install 或者 yarn install 等命令。如果你想使用这些命令，首先运行 rush unlink 来删除 Rush 创建的符号链接。

    如果你使用 git clean -dfx 来清理文件夹，注意它对符号链接的处理不够好。在使用 git clean -dfx 之前，请确保你已经运行 rush unlink.

    最后，你可以运行 rush update 重新生成符号连接。(有一个单独的 rush link 命令，但是很少使用它。)

    2. 如果你怀疑安装出现问题​

    Rush 的包管理工具命令是“增量”式的，这意味着可以通过跳过不必要的安装来节省时间。因为当 Rush 运行在自动构建环境中时，有很多保障措施来确保检查的准确性。然而，当你在本地调试时，有时会导致你的 NPM “node_modules” 文件夹变得不正确，最终导致奇怪的错误。

    如果你怀疑你的安装已经出现问题，尝试执行 rush update --purge, 该指令会强制重新完全安装你的包，通常它会带你回到正常的状态。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/developer/other_commands/index.html b/zh-cn/pages/developer/other_commands/index.html index 99f2716f..0fc3f598 100644 --- a/zh-cn/pages/developer/other_commands/index.html +++ b/zh-cn/pages/developer/other_commands/index.html @@ -6,13 +6,13 @@ 其他有用的指令 | Rush - +
    Rush StackShopBlogEvents

    其他有用的指令

    安装最新的语义化兼容的版本​

    rush update 通常情况下只会以最小增量更新的方式来满足项目内 package.json 文件，如果你想要将所有项目的依赖都更新到最新版本，可以这样做：

    # 它会高效地删除 shrinkwrap 文件，并会下载 package.json 文件中指定的最新兼容版本。
    # 注意，package.json 文件本身不会被修改。
    $ rush update --full

    对于日常工作而言，--full 可能导致你的 PR 出现一些问题，例如，如果某一个依赖没有很好地遵循语义化版本规则。对于小型仓库而言，这不是什么问题，但对于大型的 monorepo，我们建议使用日常使用 rush update，同时在某条独立的 CI 或指定人员定期使用 rush update --full.

    更快的构建方式​

    • 如果你用到的项目很少：假如你的 Git 仓库内包含 50 个项目，但是你只用在 widget 和 widget-demo 项目内工作，你可以通过 rush rebuild --to widget --to widget-demo 来构建这两个库以及他们的依赖。

    • 如果你变更了某个库：假设你的 Git 仓库包含 50 个项目，同时你仅仅在 widget 库中修复了一些 bugs, 同时你需要给所有用到该库的项目进行单元测试，但是重新构建所有项目有些浪费时间，因此可以通过 rush rebuild --from widget 来构建只包含该库的项目。

    只选择部分项目一文详细描述了如何只选择部分项目。

    一种更快的安装方式​

    如果你的仓库正在使用 PNPM 并在 rush.json 中启用了 useWorkspaces=true，那么就可以使用 “部分安装” 的功能，该功能可以通过仅在指定的项目中安装 NPM 包来减少安装时间。

    例如：

    # 仅安装构建 "my-project" 所需的 NPM 包
    #（包括安装 "my-project" 在仓库内依赖的项目的依赖）
    $ rush install --to my-project

    # 与 "rush build" 类似，可以使用 "." 来指向当前 shell 所处的工作目录
    $ cd my-project
    $ rush install --to .

    # 该指令安装了执行 "rush build --from my-project" 所需的依赖
    $ rush install --from my-project

    返回到一个干净的状态​

    在使用 Rush 后，你可能需要清理一下，比如将一个目录打包成压缩文件。这里有一些清理指令：

    # 移除所有被 Rush 创建的链接
    $ rush unlink

    # 移除 Rush 创建的所有临时文件，包括删除公共文件夹下已下载的 NPM 包。
    $ rush purge
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/developer/project_tags/index.html b/zh-cn/pages/developer/project_tags/index.html index 8c36e5cd..c54b2887 100644 --- a/zh-cn/pages/developer/project_tags/index.html +++ b/zh-cn/pages/developer/project_tags/index.html @@ -6,14 +6,14 @@ 使用项目标签 | Rush - +
    Rush StackShopBlogEvents

    使用项目标签

    Rush 的 项目标签 提供了一个很方便的办法来引用任意的 Rush 项目组， 在 rush.json 配置文件中使用 "tags" 属性可以将标签应用于项目中。

    举个例子:

    rush.json

      . . .
      "projects": [
        {
          "packageName": "my-controls",
          "projectFolder": "libraries/my-controls",
          "reviewCategory": "production",

          /**
            * 设置一个可选的自定义标签可以用于筛选这个项目
            * 举例：添加 "my-custom-tag" 将允许这个项目
            * 被该命令选中 "rush list --only tag:my-custom-tag"
            */
          "tags": [ "1.0.0-release", "frontend-team" ]
        },

        {
          "packageName": "my-toolchain",
          "projectFolder": "tools/my-toolchain",
          "reviewCategory": "tools",
          "tags": [ "tools" ]
        }
      ]
      . . .

    关于 tag:my-custom-tag 选择器语法的详细信息, 参考 选择部分项目。

    标签语法​

    标签名称必须是一个或者多个由连字符或者斜杠分隔的单词, 单词可能包含小写 ASCII 字母、数字、. 和 @ 字符。一些例子：

    rush list --to tag:my-custom-tag
    rush list --to tag:api-extractor.com
    rush list --to tag:1.0.0

    标签校验​

    在 rush.json 的 "projects" 数组中允许任意的 "tags" 字符串很容易出错。如果有人不小心拼错了标签，或者他们使用了现在已经过时的旧标签，那可能需要一段时间才能发现这个错误。你可以使用 "allowedProjectTags" 设置来定义一个在你的 monorepo 中要使用的固定标签列表，这也提供了一个集中的地方来记录它们的含义。

    rush.json

      . . .
      /**
        * 这是一个可以应用于 Rust 项目里的允许标签的可选但推荐的列表
        * 使用该文件中的 "tags" 设置，这个列表对于防止拼写等错误时很有用，
        * 并且它还提供了一个集中的地方来记录你的标签。如果 "allowedProjectTags" 列表是
        * 未指定的，那么允许任何有效的标签。标签名称必须是一个或者多个单词
        * 由连字符或者斜杠分隔, 单词可能包含小写 ASCII 字母、数字、
        * "." 和 "@" 字符。
        */
      "allowedProjectTags": [
        // 将此标签应用于所有是 CLI 工具的 Rust 项目
        "tools",

        // 将此标签应用于所有属于我们公司前端团队的项目
        "frontend-team",

        // 使用这个标签来标记包含 QA 测试通过的项目
        // 用于即将推出的产品。
        "1.0.0-release"
      ],  . . .
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/developer/selecting_subsets/index.html b/zh-cn/pages/developer/selecting_subsets/index.html index 4ea6eb52..24ac9d19 100644 --- a/zh-cn/pages/developer/selecting_subsets/index.html +++ b/zh-cn/pages/developer/selecting_subsets/index.html @@ -6,7 +6,7 @@ 选择部分项目 | Rush - + @@ -14,7 +14,7 @@
    Rush StackShopBlogEvents

    选择部分项目

    诸如 rush build 和 rush rebuild 等 Bulk 指令 默认会操作该 monorepo 内的所有项目。当你的项目越来越多时，这种操作变得十分耗时，为了加速这一过程，Rush 提供了一系列命令行参数来选择部分项目。

    假设我们的 Rush 工程形式如下图：

    a sample monorepo

    上图中圆圈表示本地项目，并没有 NPM 依赖，从 D 到 C 的箭头表示 D 依赖 C, 这意味着如果想要构建 D, 则 C 要首先被构建。我们会在下面的示例中使用 rush build 命令，但这些参数可以用于任何 Bulk 指令。

    --to​

    场景：假设我们刚刚克隆了 monorepo 仓库，现在想在项目 B 中进行开发，则需要构建 B 和 B 依赖的所有项目。

    我们可以这样做：

    # 构建项目 B 以及 B 依赖的所有项目
    $ rush build --to B

    上面的命令选择了 A, B 和 E 三个项目：

    rush build --to B

    --to-except​

    场景：很多时候我们不需要使用 rush build 来处理项目 B, 因为我们的下一步将会是在调用 Webpack 或者 Jest 的 "watch mode" 模式来处理项目 B. 此时可以使用 --to-except 来代替 --to, 该参数会仅构建项目 B 的依赖。

    # 构建 B 依赖的所有项目，但不包括项目 `B`
    $ rush build --to-except B

    # 在项目 `B` 中调用 Jest 的 watch 模式来构建
    $ heft test --watch

    该指令选择了 A 和 E 两个项目：

    rush build --to-except B

    --from​

    场景：假设现在我们完成了对项目 B 的修改，我们想要构建下游的 C 和 D 项目来保证没有破坏性的变动。为了构建项目 D, 我们同样需要构建其依赖 G. --from 的作用就是这样，它也会包括 A 和 E，因为它们是 B 的依赖。(因为 rush build 是增量构建，所以 A 和 E 可能会被跳过，因为它们可能还没有变化)

    # 构建 B 下游的所有项目，包括任何潜在的依赖
    $ rush build --from B

    该命令选中了除 F 的所有项目。

    rush build --from B

    兼容性提示： 如何在 rush.json 中设定的 rushVersion 小于 5.38.0, 则 --from 的行为类似于 --impacted-by, 在 Rush 5.38.0 版本中，该命令的含义有些变化，因为许多用户预期 --from 包含它的依赖。

    --impacted-by （不安全）​

    场景：假如为完成 B 内所需的工作需要改动对项目 E, 那么 Rush 的增量构建会假设 E 内的所有下游项目都需要被重新构建，例如 F. 这影响面可能会很大。也许你自己对他们了解更多——也许你稍后会撤回在 E 上的修改，也或者你会手动调用 E 的工具链，也许你对 E 的变动与现阶段所需无关。

    这种情况下 --impacted-by 便可发挥作用：它意味着 “只选择那些可能带给 B 破坏性变动的项目，信任那些依赖处于可用状态下的依赖。”

    # 构建 B 以及 B 下游的项目，但不包括这些项目的依赖
    $ rush build --impacted-by B

    该命令选中的项目是 B, C 和 D.

    rush build --impacted-by B

    --impacted-by-expect （不安全）​

    场景：与 --impacted-by 相同，但是不包括 B 本身。

    # 构建 B 下游的项目，但不包括这些项目的依赖
    $ rush build --impacted-by-except B

    该命令会选中 C 和 D 两个项目。

    rush build --impacted-by-except B

    --only （不安全）​

    场景：正如该参数名所示：--only 参数只会选择指定的一个项目，忽略依赖。

    # 只构建 B
    $ rush build --only B
    rush build --only B

    --only 可以与其他参数一起使用。例如在上文中，当我们使用 rush build --impacted-by B 时，可能还没有构建 G, 我们可以通过 rush build --impacted-by B --only G 来包含它。

    “不安全”参数： 如果所需的依赖没有被构建，那么诸如 --only, --impacted-by 和 --impacted-by-except 等命令可能执行失败 当你比 Rush 更了解哪些项目需要构建时，可以通过上述三个参数来节省时间。如果该前提不存在，则可以使用 rush build.

    选择器格式​

    当你指定上述参数之一时，你可以使用各种不同的格式来指定你需要的项目。

    项目名​

    最直接的方式是使用项目名（在 rush.json 文件中所列）。

    示例：

    rush build --to my-project-name

    rush build --from my-project-name

    rush list --impacted-by my-project-name

    在当前项目下使用 .​

    如果你的的终端位于某个项目目录下，可以使用 .来表示当前项目。

    示例：

    rush build --to .

    rush list --to-except .

    commit 之后发生变动的项目​

    你通过提供一个 git （分支、标签或 commit 哈希）来指定该节点以来所有修改过的项目。这种查询的类型与 rush change 使用了相同的逻辑来记录变化。

    rush build --to git:origin/main

    rush list --impacted-by git:release/v3.0.0

    组合参数​

    • 你可以在指令中组合任何参数，其结果是所有参数的并集。

    • 相同的参数可以重复多次，例如 rush build --only A --only B --only C 会选中 A, B, C.

    • 注意 Rush 不会提供任何可能会减少选中项目的参数。在 #1241 中我们会实现更复杂的选择。

    这里有一些复杂的组合指令：

    $ rush build --only A --impacted-by-except B --to F
    $ rush build --only A --impacted-by-except B --to F

    上述示例中选中的项目为 A, C, D, E 以及 F:

    rush build --only A --impacted-by-except B --to F

    更多​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/developer/tab_completion/index.html b/zh-cn/pages/developer/tab_completion/index.html index 5c697926..ffaa4f64 100644 --- a/zh-cn/pages/developer/tab_completion/index.html +++ b/zh-cn/pages/developer/tab_completion/index.html @@ -6,14 +6,14 @@ 配置 tab 补全 | Rush - +
    Rush StackShopBlogEvents

    配置 tab 补全

    在 5.34.0 版本中，Rush 支持 tab 补全，这样可以让用户按下 TAB 键来快速输入 shell 命令。以下内容参考自 .NET Core CLI 的 tab 补全。

    PowerShell​

    为了在 PowerShell 中开启 tab 补全，需要创建或编辑 $PROFILE 中的变量，更多信息可以参考：如何创建 profile 和 Profile 的执行原理.

    在你的 profile 中添加以下代码：

    # 适用于 Rush CLI 的 PowerShell 参数补全工具
    Register-ArgumentCompleter -Native -CommandName rush -ScriptBlock {
      param($commandName, $commandAst, $cursorPosition)
        [string]$value = $commandAst.ToString()
        # Handle input like `rush install; rush bui` + Tab
        [int]$position = [Math]::Min($cursorPosition, $value.Length)

        rush tab-complete --position $position --word "$value" | ForEach-Object {
          [System.Management.Automation.CompletionResult]::new($_, $_, 'ParameterValue', $_)
        }
     }

    Bash​

    为了在 Bash 中开启自动补全，需要在 .bashrc 文件中添加以下代码：

    # 适用于 Rush CLI 的 bash 参数补全工具

    _rush_bash_complete()
    {
      local word=${COMP_WORDS[COMP_CWORD]}

      local completions
      completions="$(rush tab-complete --position "${COMP_POINT}" --word "${COMP_LINE}" 2>/dev/null)"
      if [ $? -ne 0 ]; then
        completions=""
      fi

      COMPREPLY=( $(compgen -W "$completions" -- "$word") )
    }

    complete -f -F _rush_bash_complete rush
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/extensibility/api/index.html b/zh-cn/pages/extensibility/api/index.html index a2fd7816..06c9cbfb 100644 --- a/zh-cn/pages/extensibility/api/index.html +++ b/zh-cn/pages/extensibility/api/index.html @@ -6,13 +6,13 @@ The "rush-lib" API | Rush - +
    Rush StackShopBlogEvents

    The "rush-lib" API

    Rush provides an API for use by automation scripts. It is documented in the integrated API reference for all Rush Stack projects:

         API Reference: @microsoft/rush-lib package

    Below are some usage examples.

    Although these code samples are presented as plain JavaScript, we strongly recommend to use TypeScript and model your scripts as regular Rush projects. It is more work to set up initially, but it generally saves time and simplifies maintenance in the long run.

    Reading the rush.json configuration​

    Rather than trying to load rush.json as a JSON file, it is recommended to use the RushConfiguration class which provides a richer set of data views.

    For example, this script will show all the Rush projects and their folders:

    const rushLib = require('@microsoft/rush-lib');

    // loadFromDefaultLocation() will search parent folders to find "rush.json" and then
    // take care of parsing it and loading related config files.
    const rushConfiguration = rushLib.RushConfiguration.loadFromDefaultLocation({
      startingFolder: process.cwd()
    });

    for (const project of rushConfiguration.projects) {
      console.log(project.packageName + ':');
      console.log('  ' + project.projectRelativeFolder);
    }

    Modifying package.json files​

    If you want to modify a package.json file, the PackageJsonEditor class provides helpful validation and normalization:

    const rushLib = require('@microsoft/rush-lib');

    const rushConfiguration = rushLib.RushConfiguration.loadFromDefaultLocation({
      startingFolder: process.cwd()
    });

    // This will find "@rushstack/ts-command-line" in rush.json, without needing to specify the NPM scope
    const project = rushConfiguration.findProjectByShorthandName('ts-command-line');

    // Add lodash as an optional dependency
    project.packageJsonEditor.addOrUpdateDependency('lodash', '4.17.15', 'optionalDependencies');

    // Save the modified package.json file
    project.packageJsonEditor.saveIfModified();

    Generating a README.md summary​

    For a more realistic example, the repo-toolbox/src/ReadmeAction.ts tool uses these APIs to generate the README.md inventory for the Rush Stack monorepo.

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/extensibility/creating_plugins/index.html b/zh-cn/pages/extensibility/creating_plugins/index.html index 086b5ee0..52d44247 100644 --- a/zh-cn/pages/extensibility/creating_plugins/index.html +++ b/zh-cn/pages/extensibility/creating_plugins/index.html @@ -6,7 +6,7 @@ Creating Rush plugins (experimental) | Rush - + @@ -30,7 +30,7 @@ is that the plugin's config file should be stored in the folder common/config/rush-plugins with the same filename as the "pluginName" field from the manifest.

    Here's a complete example of this naming pattern:

    Plugin componentExample naming pattern
    NPM package name:@your-company/rush-policy-plugins
    "pluginName" in rush-plugin-manifest.json:"email-policy"
    end user config file:<repo>/common/config/rush-plugins/email-policy.json
    config file JSON schema:src/schemas/email-policy.schema.json
    code module:src/RushEmailPolicyPlugin.ts

    To enable Rush's automatic validation of your plugin's config file, specify the optionsSchema setting in your plugin manifest:

    rush-policy-plugins/rush-plugin-manifest.json

        . . .
        /**
         * (Optional) A path to a JSON schema for validating the config file that end users can
         * create to customize this plugin's behavior.  Plugin config files are stored in the folder
         * "common/config/rush-plugins/" with a filename corresponding to the "pluginName" field
         * from the manifest.  For example: "common/config/rush-plugins/business-policy.json"
         * whose schema is "business-policy.schema.json".
         */
        "optionsSchema": "lib/schemas/email-policy.schema.json",
        . . .

    See also​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/help/faq/index.html b/zh-cn/pages/help/faq/index.html index 7e9fb009..c2411029 100644 --- a/zh-cn/pages/help/faq/index.html +++ b/zh-cn/pages/help/faq/index.html @@ -6,13 +6,13 @@ 常见问题回答 | Rush - +
    Rush StackShopBlogEvents

    常见问题回答

    我的项目都放在一个大的仓库里？这是一个好主意吗？​

    回答在 这篇文章 中。

    我该如何报告错误或请求新功能？​

    在 rushstack 仓库下开启一个 issue, 并在 issue 标题中包含 "Rush"。

    在一个大的仓库里有很多项目，"npm install" 将会花很长时间？​

    您可能会想：“Hmm.. 如果我的当前安装需要 3 分钟，而您想把 20 个项目放在一个仓库里，我的 NPM 安装时间会不会涨到 60 分钟？” 哦，不对。Rush 会将您的依赖放在一个 "common" 目录下，并且只会执行一次 "npm install"，它与你安装单个应用耗时基本相同。

    Rush 将会使我的工具非标准化吗？​

    不对！Rush 会在现有的系统和标准中工作。它只会更好地做事，更快。

    • 每个项目目录依然是自成一体的（没有模糊包的界限）
    • 依然可以在没有 Rush 的情况下构建项目；仅需要执行 npm install 和 gulp.
    • 可以在任何一个时间内将项目移动到单独的目录中，而不用任何代码变化。

    Rush Stack 是否和 Rush 相同？​

    不。Rush Stack 是一组项目，由一组共同使命为构建大规模 TypeScript 专业工具链的开发人员维护。Rush 时 Rush Stack 的一部分。其他部分都是可选的。 Rush 本身是无关的工具链，它可以单独工作得很好。更多细节可以在 Rush Stack 网站上查看。

    安装完 Rush 之后，还是看到旧版本了？​

    问题并不是 Rush 上，但是我们听到了很多关于此的问题因为 Rush 是开始在仓库工作钱第一个需要调用的工具，其症状如下：

    $ npm install -g @microsoft/rush
    C:\Program Files\nodejs\rush -> C:\Program Files\nodejs\node_modules\@microsoft\
    rush\bin\rush
    C:\Program Files\nodejs
    `-- @microsoft/rush@3.0.1

    $ rush
    Rush Multi-Package Build Tool 2.5.0 - http://aka.ms/rush

    NPM 看起来表示安装了 3.0.1 版本，但是我们执行指令时，展示的是 2.5.0 版本，发生了什么？

    问题在于当你在输入诸如 "gulp" 和 "rush" 的命令时，它们在你的系统路径中被发现，这可能指向了以前安装的 NodeJS 或 NPM 的目录。

    修复方法：

    1. 运行 npm ls -g --depth 0 来确定你的 NPM 包被安装在哪里。
    2. 运行 set 命令，检查你的 PATH 环境变量。
    3. 确保你从步骤 1 拿到的 PATH 环境变量中没有其他 NPM 或 NodeJS 目录。
    4. 在 PATH 中删除无用的目录，例如从 NPM 之前的安装，NodeJS，nodist，nvm-windows，等等。
    5. 如果你之前使用过这些另一种引擎，很有可能你的硬盘上还有一些无用的 NPM 包。建议你跟踪它们并删除它们。

    查看：

    C:\Program Files\nodejs
    C:\Program Files (x86)\nodist
    %APPDATA%\npm
    %APPDATA%\nvm

    "npm install" 步骤报告网络错误，该怎么办？​

    如果你从一个自定义的 NPM 源安装包（例如公司的私有服务），那么你的项目需要在 .npmrc 中添加特殊的配置。如果这些配置不正确，"npm install" 可能会报告一些令人迷惑的错误，这些错误看起来像是网络问题。NPM 会在多个位置上寻找 ".npmrc" 文件，并忽略其他位置，理解这一点很重要。

    没有 Rush 时，NPM 会在两个地方寻找 ".npmrc"，并合并它们的内容：

    • 你当前 package.json 的目录下（适用于在 Git 中存储项目特定的配置）
    • 你的用户主目录（这里存放着你的认证令牌）

    当使用 Rush 调用 "npm install", 将在两个地方寻找 ".npmrc":

    • "./common/config/rush/.npmrc" （安装期间拷贝了 "./common/temp/.npmrc"）
    • 你的用户主目录

    为什么 Rush 的 JSON 配置文件中包含 // 注释，GitHub 在红色显示？​

    JSON 起初是用于作为数据交换格式，不支持代码注释。最近 JSON 这样人类可编辑的配置文件格式得到了广泛的流行，很明显它必须要求注释。因此，大多数严格的 JSON 库都可以处理注释，而不会有任何问题。（一个显而易见的例外是 JSON.parse()；不要使用它 -- 它不能验证范式，他的错误报告也很糟糕）

    VS Code 默认会将 JSON 注释高亮为错误，但是它提供了一个 "JSON with comments" 模式。要启用这个模式，在 settings.json 中添加这行：

    "files.associations": { "*.json": "jsonc" }

    默认情况下，Github 以错误的形式高亮注释。为了修复此问题，你可以在 .gitattributes 文件中添加这行（为解决 Github 缓存问题，你也可能需要提交一个改变）：

    *.json  linguist-language=JSON-with-Comments

    讨论其他更多的可能性，参考 issue #1088.

    为了避免与其他工具干扰，如何清理 Rush 的安装？​

    通常建议使用 Rush 来管理所有的 monorepo. Rush 在项目 node_modules 文件夹下创建的符号链接可能会干扰诸如 NPM 或 Yarn 的其他工具，因为它们不同的安装模式而导致故障。然而，有时这是不可避免的。例如，当迁移一个 repo 到 Rush 下时，CI 系统可能需要重用一个现有的工作文件夹来使用不同的安装方式构建不同的分支。为了防止干扰，你的 CI 任务首先需要调用一个命令来删除以前的文件。

    对于 Yarn 或 NPM, 类似 git clean -dfx 的命令通常足够。（改操作会删除文件 -- 调用前请参考手册）

    为了清理 Rush 安装，并不推荐 git clean, 这是因为它们不能很可靠的处理符号连接。相反，使用 rush purge 来删除由 Rush 创建的 node_modules 文件夹。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/help/support/index.html b/zh-cn/pages/help/support/index.html index 28c7553d..c75e16a0 100644 --- a/zh-cn/pages/help/support/index.html +++ b/zh-cn/pages/help/support/index.html @@ -6,7 +6,7 @@ 获取支持 | Rush - + @@ -14,7 +14,7 @@
    Rush StackShopBlogEvents

    获取支持

    Rush 目前由 MS Office 团队开发，不过 Microsoft 不提供官方支持，但有许多社区选项可供您使用：

    • 常见问题回答

    • 发现了一个 bug? 你可以在 rushstack 仓库下开启一个 issue

    • Zulip: 在 Rush Stack Zulip chat room 与 Rush 的开发者交流。

    • 如果一个 PR 需要被关注，尝试询问 #contributor-helpline 聊天室。我们会在合并前小心的审核每个提交，这是一项非常耗时的工作。维护者都是日常管理大型协同 monorepo 的人，所以 PR 经常被忽略。 您的贡献对我们非常重要，我们真切的希望 PR 可以被审核！

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/intro/get_started/index.html b/zh-cn/pages/intro/get_started/index.html index 1ffd385e..8e724b41 100644 --- a/zh-cn/pages/intro/get_started/index.html +++ b/zh-cn/pages/intro/get_started/index.html @@ -6,13 +6,13 @@ 快速开始 | Rush - +
    Rush StackShopBlogEvents

    快速开始

    三分钟上手​

    想要实际体验下 Rush? 首先你需要安装 NodeJS.

    从你的 shell 中安装 Rush:

    $ npm install -g @microsoft/rush

    （当然，不要输入 "$".）:-)

    如果你想看 Rush 的命令行帮助，请这样做：

    $ rush -h

    如果你想看看 Rush 构建的真实项目，可以执行以下指令：

    $ git clone https://github.com/microsoft/rushstack
    $ cd rushstack

    # 安装 NPM 包：
    # (如果你没有配置 Github email, 那么加上 "--bypass-policy" 选项。)
    $ rush update

    # 增量安装：
    $ rush update  # <-- 瞬时完成！

    # 强制所有项目重新构建：
    $ rush rebuild

    # 增量构建：
    $ rush build    # <-- 瞬时完成！

    # 使用 "--verbose" 来展示每个项目在构建过程中的日志信息。
    # 尽管项目是并行构建的，但是它们的日志是有序的。
    $ rush rebuild --verbose

    让我们开始吧！​

    选择适合你的教程

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/intro/welcome/index.html b/zh-cn/pages/intro/welcome/index.html index 03481623..23729e90 100644 --- a/zh-cn/pages/intro/welcome/index.html +++ b/zh-cn/pages/intro/welcome/index.html @@ -6,13 +6,13 @@ 欢迎使用 Rush | Rush - +
    -
    Rush StackShopBlogEvents

    欢迎使用 Rush

    Rush

    Rush 可以让 JavaScript 开发者更轻松地同时构建、发布多个 NPM 包。如果你正在将你的所有项目整合到一个仓库内，那么你来对地方了！Rush 是一个快速、专业的解决方案，它可以帮助你：

    • 仅需一次 NPM 安装: 仅需一步，Rush 便可以将你项目的所有依赖安装到一个公共文件夹下，该文件夹并不像 "package.json" 一样位于项目的根目录（放到根目录的设计可能存在幻影依赖的问题），相反，Rush 使用符号链接来为每个项目重新构建一个准确的 "node_modules" 文件。

    ⏵ 该算法支持 PNPM, NPM, and Yarn 等包管理工具.

    • 本地自动链接： 在 Rush 仓库内的所有项目之间被自动链接，当代码发生变动时，你可以在不发布的情况下看到下游所有的变动，同时，也不会困扰于 npm link 如何使用；如果你不想让某一个仓库被链接，那也很容易做到。

    快速构建： Rush 会检测依赖图，并按照正确的顺序构建你的项目。如果两个库没有被互相依赖，Rush 会使用独立的 NodeJS 进程来并行构建（同时这些并行的进程会以 可读的顺序 下显示控制台输出）。在实践中，这种多进程方式可以比所有异步函数运行在在单线程的 Gulpfile 中提供显著的速度提升。

    • 子集构建和增量构建： 如果你仅仅想构建一部分项目，可以使用 rush rebuild --to <project> 来实现一个仅包含上游依赖的清理式构建，它会重新构建该 project 及其依赖的项目；rush rebuild --from <project> 可以实现一个仅包含下游依赖的清理式构建，它会重新构建该 project 以及所有依赖该 project 的项目。如果你的工具链启用了 package-deps-hash, rush build 会生成一个强有力的跨项目增量构建（也支持子集构建）。

    • 循环依赖： 当一个库间接依赖自己的旧版本时，处于循环中的项目会使用最后一个发布的版本，而其他项目仍然会获得最新的版本。

    • 批量发布： 发布时，Rush 可以检测哪些包发生了变动，同时会自动的提高相应的版本号，并在每个文件夹那执行 npm publish, 如果你喜欢，你可以配置你的服务器，让它每小时自动执行 rush publish。

    • 跟踪更新日志： 每当创建一个 PR, 你可以要求开发者为受到影响的项目提供一个 major/minor/path 的更新条目。发布时，这些日志会被以优雅的格式整合到 CHANGELOG.md 文件中.

    • 企业级政策：想要在某个依赖被加进 package.json 前对该依赖进行审核，但是又担心重复的问题？想要让你的项目内的所有依赖都有相同版本？是否有不专业的私人邮箱混入到了你公司的 Git 历史中？Rush 可以让多人开发和多项目混合时保持一致的生态。

    还有更多！ Rush 由 Microsoft SharePoint 团队创建。我们每天构建数百个适用于生产环境的 NPM 包，从内部到开源的 Git 仓库，服务第三方 SDK 和实时服务的百万用户。如果在包管理上存在需要解决的重要问题，那么很有可能被 Rush 的某个功能特习惯解决。

    © 2022 Microsoft
    - +
    Rush StackShopBlogEvents

    欢迎使用 Rush

    Rush

    Rush 可以让 JavaScript 开发者更轻松地同时构建、发布多个 NPM 包。如果你正在将你的所有项目整合到一个仓库内，那么你来对地方了！Rush 是一个快速、专业的解决方案，它可以帮助你：

    • 仅需一次 NPM 安装: 仅需一步，Rush 便可以将你项目的所有依赖安装到一个公共文件夹下，该文件夹并不像 "package.json" 一样位于项目的根目录（放到根目录的设计可能存在幻影依赖的问题），相反，Rush 使用符号链接来为每个项目重新构建一个准确的 "node_modules" 文件。

    ⏵ 该算法支持 PNPM, NPM, and Yarn 等包管理工具.

    • 本地自动链接： 在 Rush 仓库内的所有项目之间被自动链接，当代码发生变动时，你可以在不发布的情况下看到下游所有的变动，同时，也不会困扰于 npm link 如何使用；如果你不想让某一个仓库被链接，那也很容易做到。

    快速构建： Rush 会检测依赖图，并按照正确的顺序构建你的项目。如果两个库没有被互相依赖，Rush 会使用独立的 NodeJS 进程来并行构建（同时这些并行的进程会以 可读的顺序 下显示控制台输出）。在实践中，这种多进程方式可以比所有异步函数运行在在单线程的 Gulpfile 中提供显著的速度提升。

    • 子集构建和增量构建： 如果你仅仅想构建一部分项目，可以使用 rush rebuild --to <project> 来实现一个仅包含上游依赖的清理式构建，它会重新构建该 project 及其依赖的项目；rush rebuild --from <project> 可以实现一个仅包含下游依赖的清理式构建，它会重新构建该 project 以及所有依赖该 project 的项目。如果你的工具链启用了 package-deps-hash, rush build 会生成一个强有力的跨项目增量构建（也支持子集构建）。

    • 循环依赖： 当一个库间接依赖自己的旧版本时，处于循环中的项目会使用最后一个发布的版本，而其他项目仍然会获得最新的版本。

    • 批量发布： 发布时，Rush 可以检测哪些包发生了变动，同时会自动的提高相应的版本号，并在每个文件夹那执行 npm publish, 如果你喜欢，你可以配置你的服务器，让它每小时自动执行 rush publish。

    • 跟踪更新日志： 每当创建一个 PR, 你可以要求开发者为受到影响的项目提供一个 major/minor/path 的更新条目。发布时，这些日志会被以优雅的格式整合到 CHANGELOG.md 文件中.

    • 企业级政策：想要在某个依赖被加进 package.json 前对该依赖进行审核，但是又担心重复的问题？想要让你的项目内的所有依赖都有相同版本？是否有不专业的私人邮箱混入到了你公司的 Git 历史中？Rush 可以让多人开发和多项目混合时保持一致的生态。

    还有更多！ Rush 由 Microsoft SharePoint 团队创建。我们每天构建数百个适用于生产环境的 NPM 包，从内部到开源的 Git 仓库，服务第三方 SDK 和实时服务的百万用户。如果在包管理上存在需要解决的重要问题，那么很有可能被 Rush 的某个功能特性解决。

    © 2022 Microsoft
    + \ No newline at end of file diff --git a/zh-cn/pages/intro/why_mono/index.html b/zh-cn/pages/intro/why_mono/index.html index 31427dce..5051d297 100644 --- a/zh-cn/pages/intro/why_mono/index.html +++ b/zh-cn/pages/intro/why_mono/index.html @@ -6,13 +6,13 @@ 为什么使用一个大仓库？！ | Rush - +
    Rush StackShopBlogEvents

    为什么使用一个大仓库？！

    开源的 NPM 包看起来是在许多小的 GitHub 仓库中开发的。听起来理所当然，对吧？

    如果你正在构建毫无关系的组件，并且它们不适合整合在一起，当然可以。但是商业软件并不是这样的。它更像这样：

    大多数人开始构建一个 web 应用，而不是一些库，当你的应用发布后，它的体积会逐渐增大， 直到有一天你需要在一些不同的仓库内共享一些代码，此时你发现代码已经乱成一窝，又需要花费时间重构！

    显然，你必须将这些分割为可管理的组件。在 JavaScript 代码中，NPM 包是一种解决问题的方案。但查阅后才发现，NPM 似乎要求一个 GitHub 仓库对应一个 NPM 包。于是在一周乃至数周内，你创建了 10 个 Git 仓库来分割你的代码，并试着使用它们...

    ...但是使用 10 个 Git 仓库来管理代码后会出现一些让人头疼的问题：

    • 无暇顾及他人的工作：如果一个同事大部分时间在 5 号和 6 号仓库工作，他看起来完全忽略了来自其他 8 个仓库的 pull requests。每天都会有新的仓库出现，而你甚至却不知道它们的存在。

    • 层级式的发版： 从 lib3 发布一个修复到你的应用项目需要更新/构建/发布许多 Git 仓库，顺序是：lib3 --> lib2 --> lib1 --> application. 当 lib3 变动频繁时，上述过程会变的异常繁琐。人们如何记住正确的发版顺序？互联网上有地方可以询问这个问题，但是你人力有限，别人也很忙。

    • 下游的受害者：当 Bob 在 lib3 上做了一些改动并发布，所有的下游项目需要花费一定的时间才能升级并使用它。如果升级版本存在问题，那么可能是一周后 Alice 在 lib1 中尝试 "npm update" 时发现的。那时，Bob 可能动身去欧洲旅行了。为什么 Alice 要修复其他人升级导致的问题？貌似每次升级都会存在破坏性变动！

    • 疯狂的链接：为了直接测试 lib3 的变动，解决方法看起来是使用 npm link 将你的应用和 lib3 链接起来。但是 NPM 会创建一个全局范围内的符号连接，如果在同一台电脑上多个存在 lib3 多个分支，那么就会有问题。而且有 10+ 个库，很难记录哪两个库需要链接起来。

    一个库对应一个包的方式对于陌生人之间维护孤立的项目是很有意义的（同样，这些库的更新频率也比较低，因此上述问题也更容易解决）。但是在我们的示例中，所有人都在同一个公司工作，这些库更多地扮演体系内的一个组件。代码会频繁的变动，某处的变动很可能破坏系统的其它部分。将多个项目整合起来构建，可以让你在每个变动中运行所有的单元测试，这样可以将修复问题的责任转移到最初更改代码的人身上。

    于是，一个 Git 仓库一个团队的方式开始出现了，更贴切的描述是用尽可能少的 Git 仓库来完成工作。

    monorepo block diagram

    Lots of people 许多开发大型业务软件的人，似乎最终都把所有代码放在一个大的 "monorepo" 中。JavaScript 是最后一个这么做的语言。

    monorepo 策略下最大的担忧是显著的构建耗时。JavaScript 工具链明显比编译型语言慢，如果一个工程构建需要花费一分钟，那么假如你有 75 个工程，理论上构建将花费75 分钟。这看起来很吓人，但有了工业级的工具链，在构建耗时成为问题之前，你可以进行非常大的扩展。我们对Rush和gulp-core-build的大部分路线图都集中在构建耗时上，而且我们乐观的认为这里仍然有很大的优化空间。使用子集构建或增量构建，理论上可以避免重建所有的东西，除非一个变化真的影响到所有的东西 ，—— 对于那种变化，为了能尽早发现故障而需要等待更长的构建时间，到底值不值得，这很难说。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/add_to_repo/index.html b/zh-cn/pages/maintainer/add_to_repo/index.html index 26de8da6..ffaedd95 100644 --- a/zh-cn/pages/maintainer/add_to_repo/index.html +++ b/zh-cn/pages/maintainer/add_to_repo/index.html @@ -6,7 +6,7 @@ 仓库中添加项目 | Rush - + @@ -15,7 +15,7 @@ 但该 “lock” 与文件的访问权限并无关系。在该文档中，由于我们并不知道你使用了哪种包管理工具，因此使用 "shrinkwrap" 来泛指这些文件。

    通常，包管理工具会在每个项目文件夹内创建 shrinkwrap 文件，但是在 Rush 中，整个项目共用存储在 **common/config/rush" 目录下的一个 shrinkwrap 文件，它会被存储在 Git 内。 将所有依赖信息整合到单独一个 shrinkwrap 内有一些优势，例如减少冲突、方便查看 diff, 还能提高安装速度。

    提交新的项目文件到 Git:

    ~/my-repo/tools/my-toolchain$ cd ../..
    ~/my-repo$ git add .
    ~/my-repo$ git commit -m "Adding my-toolchain"

    步骤 5: 第一次运行 "rush update"​

    当将项目文件拷贝完后，我们需要编辑 rush.json, 应该在 projects 字段下增加一个对象：

      "projects": [
        {
          "packageName": "my-toolchain",
          "projectFolder": "tools/my-toolchain"
        }
      ]

    这告知 Rush 需要接管 my-toolchain 这个项目。

    为什么 Rush 不能自动检测到这个项目？

    Rush 并不会使用通配符来检测项目。该设计有以下考虑：

    1. 深度优先搜索开销太大，尤其是需要重复收集列表时；
    2. 在带有缓存的 CI 机器上，搜索可能会遗漏掉之前构建中的文件；
    3. 集中式的管理所有项目以及其重要的元数据是很有用的，例如，可以让审批等策略更简单。

    随后通过执行 rush update 来安装 my-toolchain 的依赖，该命令可以在 Rush 仓库内的任何子目录下运行。

    ~/my-repo$ rush update
    ~/my-repo$ git add .
    ~/my-repo$ git commit -m "rush update"

    因为这是仓库内的第一个项目，你将会发现 rush update 创建了一些新文件：

    • common/config/rush/shrinkwrap.yaml: 公共的 shrinkwrap 文件 (此处假定使用了 PNPM)

    • common/scripts/install-run-rush.js: 用于在 CI 任务中以一种可靠的方式来启动 Rush

    • common/scripts/install-run.js: 用于在 CI 任务中以一种可靠的方式来启动任意工具

    步骤 6: 验证新项目是否构建成功​

    为了构建项目，Rush 会寻找项目内的 package.json 文件内 "scripts" 字段下的 "build" 指令，在 rush 示例中，使用简单的 shell 脚本 "rimraf ./lib/ && tsc" 来执行构建。

    {
      "name": "my-toolchain",
      "version": "1.0.0",
      "description": "An example toolchain used to build projects in this repo",
      "license": "MIT",
      "bin": {
        "my-build": "bin/my-build.js"
      },
      "scripts": {
        "build": "rimraf ./lib/ && tsc"
      },
      "dependencies": {
        "colors": "^1.3.2"
      },
      "devDependencies": {
        "@types/node": "^10.9.4",
        "rimraf": "^2.6.2",
        "typescript": "^3.0.3"
      }
    }

    当创建 "build" 指令时，需要注意以下几件事：

    Rush 通常会使用系统的 PATH 环境变量来查找脚本，然而，如果你制定了诸如 "gulp" 或者 "make" 等单个单词的指令，Rush 会首先在 common\temp\node_modules\.bin 目录下查找该指令。

    如果进程返回非零退出码，Rush 将判定为失败，并阻塞随后的构建。

    如果指令对 stderr 存在任意输入，则 Rush 将以错误、警告报告等形式来解释该输入。这将会中断构建流程（设计如此，如果你允许开发者以这种 “狼来了” 的形式合并 PR，很快你就会发现，报警提示很快就会堆积到没人再去看它们）。诸如 Jest 等的工具库认为向 stderr 写入信息是常见操作，对此需要你重定向它们的输出.

    即使某个项目不需要被 rush build 处理，你依然需要保留 build 字段，将其设定为空字符串("") 后 Rush 会忽略它们。

    现在我们来构建你的项目，在 Rush 仓库下的任何子目录都可以执行下面命令（它将会构建仓库内的所有项目）：

    $ rush build

    Rush 提供了大量命令行选项来构建项目，可以参考 rush build 和 rush rebuild.

    幻影依赖错误

    Rush 和 PNPM 使用符号连接来防止项目中引入幻影依赖，如果一个 NPM 依赖并没有在项目内的 package.json 中声明，那么当你尝试引入它时会有一个运行时报错。当你将项目迁移到 Rush 时，幻影依赖报错是最常见的问题之一。通常的解决方案是将缺失的依赖添加到 package.json 文件中。

    rush scan 指令可以快速地检查出这些问题。

    步骤 7: 添加更多的项目​

    你可以依据步骤 4 来添加更多的项目，在我们的事例中，接下来将会添加 my-controls 工程（因为它依赖 my-toolchain），最后是 my-application（因为它依赖其他两个项目)。由于我们的设想的场景中可能有更多这类项目，因此预期会添加一些类别文件夹（"libraries" 和 "apps"），因为我们的场景中会有更多这类项目。完整的 "projects" 字段示例如下：

      "projects": [
        {
          "packageName": "my-app",
          "projectFolder": "apps/my-app"
        },

        {
          "packageName": "my-controls",
          "projectFolder": "libraries/my-controls",
          "reviewCategory": "production"
        },

        {
          "packageName": "my-toolchain",
          "projectFolder": "tools/my-toolchain",
          "reviewCategory": "tools"
        }
      ]

    如果你已经成功添加了所有项目，便可以开始考虑启用其他功能。配置文件中包含大量的代码片段，你可以将它们注释掉后使用。rush 示例 中使用了这些代码片段。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/autoinstallers/index.html b/zh-cn/pages/maintainer/autoinstallers/index.html index 3e843d0c..4cd9bbe1 100644 --- a/zh-cn/pages/maintainer/autoinstallers/index.html +++ b/zh-cn/pages/maintainer/autoinstallers/index.html @@ -6,7 +6,7 @@ Autoinstallers | Rush - + @@ -43,7 +43,7 @@ You should redo this step whenever you modify the package.json file.

    # Create or update common/autoinstallers/my-autoinstaller/pnpm-lock.yaml
    # This file should be committed and tracked by Git.
    rush update-autoinstaller --name my-autoinstaller

  • Commit the updated files to git

    git add common/autoinstallers/my-autoinstaller/

    git commit -m "Updated autoinstaller"

    • To associate an autoinstaller with a custom command, specify its name in the autoinstallerName field in command-line.json.

    To associate an autoinstaller with a Rush plugin, see the Creating Rush plugins documentation.

    Maintaining an autoinstaller​

    • To modify an autoinstaller, edit its package.json file.

      # This will also upgrade any indirect dependencies.
      rush update-autoinstaller --name my-autoinstaller

      # Commit the updated pnpm-lock.yaml
      git commit -m "Updated autoinstaller"

    • To delete the autoinstaller, simply delete its folder:

      # BE CAREFUL WHEN RECURSIVELY DELETING FOLDERS
      rm -Rf common/autoinstallers/my-autoinstaller

      # Commit the changes to Git
      git add common/autoinstallers

      git commit -m "Deleted autoinstaller"

    See also​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/build_cache/index.html b/zh-cn/pages/maintainer/build_cache/index.html index 13659909..783860ba 100644 --- a/zh-cn/pages/maintainer/build_cache/index.html +++ b/zh-cn/pages/maintainer/build_cache/index.html @@ -6,14 +6,14 @@ 启用构建缓存（实验性） | Rush - +
    Rush StackShopBlogEvents

    启用构建缓存（实验性）

    Rush 一直支持 增量分析 功能，它允许 rush build 来跳过一些自上次构建后没有文件修改的项目（该优化同样适用于自定义指令，只要在 custom-commands.json 中开启 incremental 即可）。然而，构建产物并没有并时刻保存，因此当切换到另外一个分支时，通常需要执行 rebuild 来重新构建。

    Rush 中实验性的构建缓存将在每个项目的构建产物中创建一个 tar 文件，该文件会被缓存，如果 rush build 可以匹配到缓存，则会从缓存中读取该文件，从而避免了重新构建。这就可以显著提高构建速度，例如将一个 30 分钟的构建耗时缩短到 30 秒。缓存的键值是源文件和 NPM 依赖的哈希值，与增量分析的基本规则相同。

    构建缓存的文件将保存在两个地方：

    • 本地磁盘的缓存目录下。这样做可以在切换分支时候不会丢掉数据，你甚至可以在机器上配置一个共享的缓存目录，其默认位置是 common/temp/build-cache.

    • 云端（可选）。一般而言，CI 系统可以配置成允许写入云端存储，同时每个用户只有可读权限。例如，每次 PR 被合并到 main 分支时，CI 系统会以此为基准进行构建并将其上传到云上。这样，对于即使是 git clone 的开发者而言，他们的 rush build 也是非常快的。

    构建缓存被认为是跳过构建的替代方案，一旦被启动，支持增量构建的指令将从缓存中读取数据，而不是之前的“跳过”。 如果项目没有配置构建缓存，或者故意的禁止掉构建缓存，将会使用默认的跳过。

    启用本地磁盘缓存​

    在 build-cache.json 中可以开启本地构建缓存，你可以从该页面拷贝或者使用 rush init 创建这个文件。

    本地构建缓存有两个配置项：

    common/config/rush/build-cache.json

    {
      . . .
      /**
       * （必须）实验性 -当该值为 true 时将会启动构建缓存。
       *
       * 可以查阅 https://rushjs.io/pages/maintainer/build_cache/ 了解更多
       */
      "buildCacheEnabled": true,

      /**
       * （必须）选择哪些项目的构建产物需要被缓存。
       *
       * 可能的值："local-only"，"azure-blob-storage"，"amazon-s3"
       */
      "cacheProvider": "local-only",

      . . .
    }

    升级提示：早期版本的该功能需要在 experiments.json 中设定 "buildCache": true. 这个配置项已经被 build-cache.json 下的 "buildCacheEnabled" 替代。

    配置项目的输出目录​

    当你运行 rush rebuild --verbose 时，会看到如下警告：

    Project does not have a rush-project.json configuration file, or one provided by a rig, so it does not support caching.

    构建缓存需要知道哪些目录需要被存储在 tar 的压缩包中，这些细节可能由于工具链的不同而不同，因此每个项目都需要使用 rush-project.json 来单独配置。

    例如：

    <your-project>/config/rush-project.json

      . . .

      /**
       * 指定你的工具链的产物输出目录，如果此字段开启，Rush 构建缓存将从缓存中恢复这些目录。
       *
       * 字符串是项目根目录下的目录名，这些项目不应被 Git 记录到，并且必须不能包含符号链接。
       */
      "projectOutputFolderNames": ["lib", "dist"]
      . . .
    }

    建议使用 rig 包 来避免每个项目目录中都拷贝一份。

    测试构建缓存​

    当开启缓存后项目的输出日志示例为：

    $ rush rebuild --verbose

    . . .

    ==[ example-project ]==============================================[ 1 of 5 ]==

    This project was not found in the build cache.

    Invoking: heft test --clean

    . . .

    Caching build output folders: lib

    Successfully set cache entry.

    "example-project" completed successfully in 11.27 seconds.

    当第二次执行相同的命令时，Rush 会将压缩包解压，而不是再次执行构建任务。

    $ rush rebuild --verbose

    . . .

    ==[ example-project ]==============================================[ 1 of 5 ]==

    Build cache hit.

    Clearing cached folders: lib, dist

    Successfully restored output from the build cache.

    example-project was restored from the build cache.

    注意 rush rebuild 将不会再读取缓存。将 RUSH_BUILD_CACHE_WRITE_ALLOWED 的环境变量设置为 0 可以禁止在 rush rebuild 时阶段写入缓存，

    默认而言，缓存的 tar 压缩包存储在 common/temp/build-cache 目录中，因此可以被 rush purge 删除。

    启用云端存储​

    目前 cacheProvider 有三个选项：​

    • "local-only"：不启用云端存储，压缩包只保存在本地磁盘上
    • "azure-blob-storage"：Microsoft Azure blob storage container
    • "amazon-s3"：Amazon S3 bucket

    （以上能力由 modeled as Rush plugins. 自定义的云存储服务可参考该插件实现）

    例如，这里是如何配置 Azure blob 容器的方法：

    common/config/rush/build-cache.json

    {
      . . .
      /**
       * （必须）实验性的 - 设定为 true 启用构建缓存功能。
       *
       * 更多信息可参考 https://rushjs.io/pages/maintainer/build_cache/
       */
      "buildCacheEnabled": true,

      /**
       * （必须）选择哪些项目的构建产物需要被缓存。
       *
       * 可能的值："local-only"，"azure-blob-storage"，"amazon-s3"
       */
      "cacheProvider": "azure-blob-storage",

      /**
       * 设定 "azure-blob-storage" 时使用此配置
       */
      "azureBlobStorageConfiguration": {
        /**
         * (必须) Azure 账户名
         */
        "storageAccountName": "example",

        /**
         * Azure 存储账户中的容器名称
         */
        "storageContainerName": "my-container"

        /**
         * 当其值为 true 时候，允许像 cache 中写入
         * 默认为 false
         */
        "isCacheWriteAllowed": false

      . . .

    注意，当设定 "isCacheWriteAllowed": false 时，可以防止普通用户写入容器。(稍后会使用环境变量覆盖此配置，以便 CI 任务能够写入容器。)

    用户权限​

    如果你的仓库并不关心安全性，那么你可以简单地配置容器以允许匿名访问。容器可以通过包含随机字符串的 HTTPS 协议的 URL 来访问，这个 URL 很难背猜到，除非其他人可以在 Git 仓库中查看。这点通过隐蔽性来保障安全。

    更安全的组织方式是对于即使只读的情况也要用户认证，Rush 提供了 rush update-cloud-credentials指令来让用户进行更简单的配置：

    $ rush update-cloud-credentials --interactive


    Rush Multi-Project Build Tool 5.45.6 (unmanaged) - https://rushjs.io
    Node.js version is 12.20.1 (LTS)


    Starting "rush update-cloud-credentials"

     ╔═════════════════════════════════════════════════════════════════════════╗
     ║             To sign in, use a web browser to open the page              ║
     ║     https://microsoft.com/devicelogin and enter the code XAYBQEGRK      ║
     ║                            to authenticate.                             ║
     ╚═════════════════════════════════════════════════════════════════════════╝

    认证信息会被保存在用户的主目录下的 ~/.rush-user/credentials.json.

    CI 设置​

    通常配置下，用户只有只读权限，缓存通常被一个账号自动更新。例如，每次 PR 被合并到 main 后会执行一个 CI 任务。在上述事例中，"isCacheWriteAllowed": false 是为了防止了用户写入缓存。CI 任务可以通过设置 RUSH_BUILD_CACHE_WRITE_ALLOWED 环境变量来覆盖此配置，并通过 RUSH_BUILD_CACHE_CREDENTIAL 环境变量来提供认证信息。

    对于 Azure 而言，必须使用序列化的 SAS 口令来充当一个 query 参数，可以查看此篇文章 来获取更多信息，你可以通过 设置 > 访问密钥 页面来获取你的存储账号的访问密钥。

    构建缓存功能依然在开发中，有意见或者建议请联系我们！

    一些相关的 GitHub 提问：

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/cobuilds/index.html b/zh-cn/pages/maintainer/cobuilds/index.html index e88aadb0..bed29b12 100644 --- a/zh-cn/pages/maintainer/cobuilds/index.html +++ b/zh-cn/pages/maintainer/cobuilds/index.html @@ -6,7 +6,7 @@ Cobuilds (experimental) | Rush - + @@ -106,7 +106,7 @@ of the operation's execution result and the corresponding cache_id. Before attempting to acquire a lock, a machine will first query this completion result information. If there is a completion result available, the result is reused based on the parsed information.

    See also​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/custom_commands/index.html b/zh-cn/pages/maintainer/custom_commands/index.html index 8d05ee28..bac8c1d8 100644 --- a/zh-cn/pages/maintainer/custom_commands/index.html +++ b/zh-cn/pages/maintainer/custom_commands/index.html @@ -6,13 +6,13 @@ 自定义指令 | Rush - +
    Rush StackShopBlogEvents

    自定义指令

    如果你的工具链有特殊的模式或功能，你可以将它们作为自定义指令或 Rush 工具的参数来暴露出来。

    自定义指令和参数​

    common/config/rush/command-line.json 下有一个配置文件用于自定义指令和参数，你的配置文件应该满足 command-line.schema.json 范式，考虑以下示例：

    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/command-line.schema.json",

      "commands": [
        {
          /**
           * （必须）用于确定自定义指令的类型。
           * Rush 的 "bulk" 类型指令将会在每个项目中都被调用，Rush 会寻找项目 package.json 内的 "scripts" 字段中匹配该命令行的字段。
           * 默认情况下，Rush 会根据依赖图来确定要运行的项目（与 "rush build" 的工作原理类似）。
           * 也可以通过诸如 "--to" 或 "--from" 参数来限制项目集合。
           */
          "commandKind": "bulk",
          "name": "import-strings",
          "summary": "Imports translated strings into each project.",
          "description": "Requests translated strings from the translation service and imports them into each project.",
          "enableParallelism": true
        },
        {
           /**
           *（必须）用于确定自定义指令的类型。
           * Rush 的 "global" 类型的指令会在整个仓库调用一次。
           */
          "commandKind": "global",

          "name": "deploy-app",
          "summary": "Deploys the application",
          "description": "Run this command to deploy the application",

          "shellCommand": "node common/scripts/deploy-app.js"
        }
      ],

      "parameters": [
        {
          /**
           * (必须) 决定自定义参数的类型
           * "flag" 类型的参数是一个布尔属性的参数
           */
          "parameterKind": "flag",
          "longName": "--ship",
          "shortName": "-s",
          "description": "Perform a production build, including minification and localization steps",
          "associatedCommands": [ "build", "rebuild", "import-strings" ],
        },

        {
          "parameterKind": "flag",
          "longName": "--minimal",
          "shortName": "-m",
          "description": "Perform a fast build, which disables certain tasks such as unit tests and linting",
          "associatedCommands": [ "build", "rebuild" ]
        },
        {
          /**
           * (必须) 决定自定义参数的类型
           * "choice" 类型的参数需要从可供选择的参数中选取一个
           */
          "parameterKind": "choice",
          "longName": "--locale",
          "description": "Selects a single instead of the default locale (en-us) for non-ship builds or all locales for ship builds.",
          "associatedCommands": [ "build", "rebuild", "import-strings" ],
          "alternatives": [
            {
              "name": "en-us",
              "description": "US English"
            },
            {
              "name": "fr-fr",
              "description": "French (France)"
            },
            {
              "name": "es-es",
              "description": "Spanish (Spain)"
            },
            {
              "name": "zh-cn",
              "description": "Chinese (China)"
            }
          ]
        }
      ]
    }

    自定义指令：你可以像 Rush 内置的指令（例如 rush build, rush check 等）一样自定义自己的指令，这有两种类型：

    • bulk: bulk 类型的指令会在每个项目中被调用，其原理与 rush build. 设定 "enableParallelism": true 后，项目可以并行运行。
    • global: global 类型的指令会在整个仓库内执行指定的脚本文件。

    你也可以自定义命令行“参数”。一个参数可以通过 associatedCommands 来被一个或多个指令关联。你甚至可以将自定义参数关联到 Rush 内置的 build 和 rebuild 指令上。在上述示例中，我们将 --ship 参数关联到 rush build, rush rebuild 和自定义的 rush import-strings 上。

    目前有三种 parameterKind 类型：

    • flag: flag 是一个布尔属性的参数，例如 --ship.
    • choice: choice 是一个从列表选择的额外参数，例如 --locale fr-fr.
    • string: string 是一个可以接受任何字符串值的参数，例如 --name my-new-package.

    未来会支持更多参数类型（它们使用 ts-command-line 来解析）

    使用自定义命令和选项​

    你可以自定义指令和其描述将被会被 Rush 的命令行帮助中（当在仓库的工作目录中调用时），继续上述示例，如果我们运行 rush import-strings --help，我们将看到这样的内容：

    Rush Multi-Project Build Tool 5.1.0 - https://rushjs.io

    usage: rush import-strings [-h] [-p COUNT] [-t PROJECT1]
                               [--to-version-policy VERSION_POLICY_NAME]
                               [-f PROJECT2] [-v] [-s]
                               [--locale {en-us,fr-fr,es-es,zh-cn}]

    Requests translated strings from the translation service and imports them
    into each project.

    Optional arguments:
      -h, --help            Show this help message and exit.
      -p COUNT, --parallelism COUNT
                            Specify the number of concurrent build processes The
                            value "max" can be specified to indicate the number
                            of CPU cores. If this parameter omitted, the default
                            value depends on the operating system and number of
                            CPU cores.
      -t PROJECT1, --to PROJECT1
                            Run command in the specified project and all of its
                            dependencies
      --to-version-policy VERSION_POLICY_NAME
                            Run command in all projects with the specified
                            version policy and all of their dependencies
      -f PROJECT2, --from PROJECT2
                            Run command in all projects that directly or
                            indirectly depend on the specified project
      -v, --verbose         Display the logs during the build, rather than just
                            displaying the build status summary
      -s, --ship            Perform a production build, including minification
                            and localization steps
      --locale {en-us,fr-fr,es-es,zh-cn}
                            Selects a single instead of the default locale
                            (en-us) for non-ship builds or all locales for ship
                            builds.

    如果实现一个自定义指令和自定义参数？对于 global 指令而言，Rush 仅仅会唤起其 shellCommand 并传递参数；对于 bulk 指令，Rush 会在 package.json 中查找对应的脚本。假设我们有以下内容：

    example/package.json

    {
      "name": "example",
      "version": "1.0.0",
      "main": "lib/index.js",
      "typings": "lib/index.d.ts",
      "scripts": {
        "import-strings": "./node_modules/.bin/loc-importer",
        "build": "./node_modules/.bin/gulp"
      }
    }

    如果执行 rush import-strings --locale fr-fr，Rush 将会读取 "import-strings" 脚本体并执行如下：

    ./node_modules/.bin/loc-importer --locale fr-fr

    （Rush 直接在 shell 中执行，并不依赖 npm run.）因为这个 choice 参数有默认值，如果我们运行 rush import-strings，那么 loc-importer 将会执行如下：

    ./node_modules/.bin/loc-importer --locale en-us

    换句话说，Rush 的自定义参数只是简单的在 package.json 中的脚本内添加一些内容，这意味着当你使用诸如 "rimraf ./lib && rimraf ./temp" 等 shell 脚本时，可能会出现问题，因为这些脚本不支持这些参数，或者需要在中间插入这些参数。这是因为设计的原因在于：我们不建议在 JSON 中写入复杂的构建脚本。相反，最好把这些操作移到一个方便注释和审查的脚本文件中。当 monorepo 仓库逐渐扩大时，你也许想要讲这个脚本移动到一个可以在多个项目中共享的库里。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/custom_tips/index.html b/zh-cn/pages/maintainer/custom_tips/index.html index f432d1ba..65fef35b 100644 --- a/zh-cn/pages/maintainer/custom_tips/index.html +++ b/zh-cn/pages/maintainer/custom_tips/index.html @@ -6,7 +6,7 @@ Custom tips (实验性功能) | Rush - + @@ -14,7 +14,7 @@
    Rush StackShopBlogEvents

    Custom tips (实验性功能)

    Custom tips 允许您为 Rush 打印的命令行消息添加为您的特定单仓库量身定制的建议 (tips)。

    以下是一个 custom tips 能够帮忙的例子：假设您的公司使用一个私有的 NPM registry，该注册表定期从上游的 npmjs.com 服务器同步最新的包版本。有时用户可能试图安装刚刚发布的版本，而该版本尚未同步，此时 rush update 可能会显示以下错误：

    Progress: resolved 0, reused 1, downloaded 0, added 0
    /users/example/code/my-repo/apps/my-app:
     ERR_PNPM_NO_MATCHING_VERSION  No matching version found for example-library@1.2.3

    This error happened while installing a direct dependency of my-app

    The latest release of example-library is "1.1.0".

    此错误有些令人困惑，因为 npm 上的最新发布版本确实是 1.2.3，而错误是因为您公司私有的 NPM registry 同步的最新最新版本还在 1.1.0。如果您的团队为 monorepo 维护一个帮助热线（比如 oncall 群），您可能会经常收到关于这个错误的 on-call。这可以通过显示 custom tip 来避免。

    配置 custom tip​

    上面的 ERR_PNPM_NO_MATCHING_VERSION 代码来自 PNPM。Rush 对应的提示 ID 是 TIP_PNPM_NO_MATCHING_VERSION。我们可以如下定义提示：

    common/config/rush/custom-tips.json

    /**
     * 这个配置文件允许仓库维护者配置与某些 Rush 消息一起打印的额外详细信息。更多文档可在
     * Rush 官方网站上找到：https://rushjs.io
     */
    {
      "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/custom-tips.schema.json",

      /**
       * 指定 Rush 要显示的 custom tips。
       */
      "customTips": [
        // {
        //   /**
        //    * (必须) 一个标识符，表示 Rush 可能打印的消息。
        //    * 如果打印了该消息，则将显示此 custom tip。
        //    * 请参阅 Rush 文档以获取可能的标识符的当前列表。
        //    */
        //   "tipId": "TIP_RUSH_INCONSISTENT_VERSIONS",
        //
        //   /**
        //    * (必须) 要为此提示显示的消息文本。
        //    */
        //   "message": "要获取额外的故障排除信息，请参阅此 wiki 文章：\n\nhttps://intranet.contoso.com/docs/pnpm-mismatch"
        // }
        {
          "tipId": "TIP_PNPM_NO_MATCHING_VERSION",
           "message": "PNPM 的这个“no matching version”的错误经常是由于新版本尚未同步到我们公司的内部 NPM registry所导致的。\n\n要获取故障排除指南，请查阅我们的团队 wiki：\n\nhttps://example.com/wiki/npm-syncing"
        }
      ]
    }

    如果您没有此文件，您可以使用 rush init 生成它。

    随着这次更改，用户现在将在原始错误旁边看到 custom tip：

    Progress: resolved 0, reused 1, downloaded 0, added 0
    /users/example/code/my-repo/apps/my-app:
     ERR_PNPM_NO_MATCHING_VERSION  No matching version found for example-library@1.2.3

    This error happened while installing a direct dependency of my-app

    The latest release of example-library is "1.1.0".

    | Custom Tip (TIP_PNPM_NO_MATCHING_VERSION)
    |
    | PNPM 的这个“no matching version found”的错误经常是由于新版本尚未同步到我们公司的内部 NPM registry 所导致的。
    |
    | 要获取故障排除指南，请查阅我们的团队 wiki：
    |
    | https://example.com/wiki/npm-syncing

    请注意，Rush 用 | 前缀 custom tips，以将其与 Rush 软件的官方消息区分开。

    贡献新的 tips​

    有没有你想自定义的 Rush 消息，但没有可用的 tipId？实现新的 tips 相对容易。代码位于 rush-lib/src/api/CustomTipsConfiguration.ts， 请随时创建拉取请求来提议新的 tips。

    Custom tip 标识符​

    TIP_PNPM_INVALID_NODE_VERSION​

    对应于 PNPM 的 ERR_PNPM_INVALID_NODE_VERSION。

    TIP_PNPM_MISMATCHED_RELEASE_CHANNEL​

    对应于 PNPM 的 ERR_PNPM_MISMATCHED_RELEASE_CHANNEL。

    TIP_PNPM_NO_MATCHING_VERSION​

    对应于 PNPM 的 ERR_PNPM_NO_MATCHING_VERSION。

    TIP_PNPM_NO_MATCHING_VERSION_INSIDE_WORKSPACE​

    对应于 PNPM 的 ERR_PNPM_NO_MATCHING_VERSION_INSIDE_WORKSPACE。

    TIP_PNPM_OUTDATED_LOCKFILE​

    对应于 PNPM 的 ERR_PNPM_OUTDATED_LOCKFILE。

    TIP_PNPM_PEER_DEP_ISSUES​

    对应于 PNPM 的 ERR_PNPM_PEER_DEP_ISSUES。

    TIP_PNPM_TARBALL_INTEGRITY​

    对应于 PNPM 的 ERR_PNPM_TARBALL_INTEGRITY。

    TIP_PNPM_UNEXPECTED_STORE​

    对应于 PNPM 的 ERR_PNPM_UNEXPECTED_STORE。

    TIP_RUSH_INCONSISTENT_VERSIONS​

    当项目有不一致的依赖版本时，此消息由 rush install 或 rush update 打印，前提是你的项目在 rush.json 中启用了 ensureConsistentVersions（我们也推荐如此）。

    Rush 输出示例：

    Found 5 mis-matching dependencies!

    另请参阅​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/deploying/index.html b/zh-cn/pages/maintainer/deploying/index.html index bb0ec827..605fd2cb 100644 --- a/zh-cn/pages/maintainer/deploying/index.html +++ b/zh-cn/pages/maintainer/deploying/index.html @@ -6,13 +6,13 @@ 部署项目 | Rush - +
    Rush StackShopBlogEvents

    部署项目

    假定你的 monrepo 项目含有一个 web 服务器的 Node.js 服务，举例来说，本地 Rush 仓库内的 Node.js 服务的项目名为 app1, 该仓库的组织如下：

    • apps/app1:
      • dependencies 为 NPM 上的 ext-lib7 和本地 lib3
      • devDependencies 为 NPM 上的 ext-tool8 和本地 tool6
    • apps/app2: 依赖 lib3 和 lib4
    • libraries/lib3: 依赖 lib5
    • libraries/lib4: 没有依赖
    • libraries/lib5: 同级依赖 ext-lib7
    • tools/tool6: 没有依赖

    一个构建方式是执行 rush install 和 rush build, 但是该操作会将整个仓库传递到 Node 服务上，然而，这也会引入很多无关的文件和 NPM 包。相反，我们可以只处理 app1 和其依赖 ext-lib7, lib3, lib5, 我们并不想引入诸如 ext-tool8 等开发依赖。

    rush deploy 指令可以将这组文件传入到指定的服务器上。

    配置 "rush deploy"​

    rush deploy 指令从 common/config/rush/deploy.json 中读取配置，该文件并不是 rush init 生成的，而是需要执行 rush init-deploy 来创建。

    继续我们的示例，我们可以使用下面指令来创建文件

    # 创建用于 "app1" 的配置文件：common/config/rush/deploy.json
    $ rush init-deploy --project app1

    当 deploy.json 配置完成后，需要对其执行 Git commit.

    准备构建​

    为了将文件复制到构建目录中，需要执行：

    # 安装依赖
    $ rush install

    # 构建 monorepo
    $ rush build

    # 拷贝 app1 及其依赖到默认的目录 common/deploy
    $ rush deploy

    这将通过复制 app1 及其依赖到目标目录下来准备部署环境，复制后的目录结构与 monorepo 的文件结构类似：

    • common/deploy/apps/app1/...
    • common/deploy/common/temp/node_modules/ext-lib7/...
    • common/deploy/libraries/lib3/...
    • common/deploy/libraries/lib4/...

    你可以在构建产物的目录中执行 app1 来验证是否有问题。

    # 将工作目录切换到产物下的 app1 路径
    $ cd common/deploy/apps/app1

    # 通过 package.json 中的脚本来唤起网络服务
    $ rushx start

    如果项目运行失败（但是原本 apps/app1 下可以正常运行），那么你可能需要配置下 deploy.json, 一旦可以运行，下依旧就是将 common/deploy 上传到服务器上。

    处理链接​

    执行 rush install 会给 common/deploy 目录创建符号链接，例如，如果你使用 PNPM, 那么 common/deploy/apps/app1/node_modules/ext-lib7 可能是指向 common/deploy/common/temp/node_modules/.pnpm/... 目下的一个链接，使用诸如 tar 和 ftp 等工具上传时可能出现问题。

    deploy.json 下中字段 linkCreation 下有三个处理链接的选项。

    • "default": 拷贝文件时创建链接，这是默认选项，如果你的上传工具可以正确处理这些链接，则可以使用该选项。
    • "scripts": 将会在目录下写入一个名为 create-links.js 的脚本，该配置会在上传后的服务器上创建链接。
    • "none": 什么都不会，一些其他基于 deploy-metadata.json 的脚本可能在随后创建链接。

    deploy-metadata.json 被写入部署文件中，它包含一个需要被创建链接的清单，其实力如下：

    {
      "scenarioName": "deploy.json",
      "mainProjectName": "app1",
      "links": [
        {
          "kind": "folderLink",
          "linkPath": "common/deploy/apps/app1/node_modules/ext-lib7",
          "targetPath": "common/deploy/common/temp/node_modules/.pnpm/registry.npmjs.org/ext-lib7/1.0.0/node_modules/ext-lib7"
        },
        . . .
      ]
    }

    如果你使用 "linkCreation": "script" 之后执行 rush deploy 会创建没有链接的 common/deploy 的目录，当你将这些文件上传到服务器后，你可以调用下面脚本来创建链接：

    # 当文件被上传后在服务器上执行下面命令
    $ node create-links.js create

    注意：当使用 "linkCreation": "script" 时，目前的实现还没在 node_modules/.bin 下生成可执行命令，如果你对该问题有兴趣，请参考该 PR.

    引入另外的项目​

    继续我们的示例，假设我们想要将 app1 和 app2 合并成一个部署，由于 app2 并不是 app1 的依赖，因此不会被自动包含进去。我们可以考虑将 app1 放到“主项目”中（在 deploymentProjectNames 内配置），之后创建 app2 为“额外的项目”，配置文件如下：

    common/config/rush/deploy.json

    {
      . . .
      // 主项目
      "deploymentProjectNames": ["app1"],
      . . .
      "projectSettings": [
        {
          "projectName": "app1",

          // 当部署 "app1" 时同时部署 "app2",
          // 我们需要明确指明它，因为 "app2" 不是 "app1" 的依赖
          "additionalProjectsToInclude": [ "app2" ]
        }
      ]
    }

    使用同一个配置文件进行多部署​

    继续我们的示例，假定我们想要 app1 和 app2 分别部署到两个不同的 web 服务器上。如果设置相同，我们可以简单地将它们添加到 deploymentProjectNames 数组中，如下：

    common/config/rush/deploy.json

      . . .
      "deploymentProjectNames": [ "app1", "app2" ],
      . . .

    部署时，使用 --project 参数选择需要被部署的项目。例如：

    # 将 app1 和其依赖项复制到 /mnt/deploy/app1
    $ rush deploy --project app1 --target-folder /mnt/deploy/app1

    # 将 app2 和其依赖项复制到 /mnt/deploy/app2
    $ rush deploy --project app2 --target-folder /mnt/deploy/app2

    --target-folder 参数用于将文件复制到自定义目录下，其默认值为 common/deploy/.

    使用不同的配置文件进行多部署​

    继续我们的示例，假定 app2 单独部署，同时它的设置与 app1 不同。例如，假设 app1 的 "linkCreation": "default", 但是 app2 的 "linkCreation": "script". 我们创建两个配置文件：

    • common/config/rush/deploy.json - 默认配置文件，它将被用于 app1.
    • common/config/rush/deploy-app2-example.json - 适用于 app2-example 的配置文件, 它将被用于 app2.

    上述文件都可以被 rush init-deploy 创建：

    # 创建 common/config/rush/deploy.json
    $ rush init-deploy --project app1

    # 创建 common/config/rush/deploy-app2-example.json
    $ rush init-deploy --project app2 --scenario app2-example

    在 deploy-app2-example.json 中指定 "linkCreation": "script", 然后同时使用 --scenario 和 rush deploy:

    # 使用 common/config/rush/deploy.json 将 app1 和其依赖复制到 /mnt/deploy/app1
    $ rush deploy --target-folder /mnt/deploy/app1

    # 使用 common/config/rush/deploy-app2-example.json 将 app2 和其依赖复制到 /mnt/deploy/app2
    $ rush deploy --target-folder /mnt/deploy/app2 --scenario app2-example

    注意，rush deploy 不需要 --project 参数，因为每个配置文件中只有一个项目在 "deploymentProjectNames" 数组中。

    参考​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/enabling_ci_builds/index.html b/zh-cn/pages/maintainer/enabling_ci_builds/index.html index 517d1180..d7770518 100644 --- a/zh-cn/pages/maintainer/enabling_ci_builds/index.html +++ b/zh-cn/pages/maintainer/enabling_ci_builds/index.html @@ -6,13 +6,13 @@ 启用 CI | Rush - +
    Rush StackShopBlogEvents

    启用 CI

    持续集成要求在提交 PR 时设定一个构建行为，这个自动化的脚本可以一些运行类似于开发人员手动执行的命令。这里会展示一些有用的额外配置项。

    如果手动执行以下指令，其效果类似于：

    # 获取主分支代码
    $ git fetch origin main:refs/remotes/origin/main -a

    # （可选）如果开发者没有创建更新日志则失败。
    # 这意味着脚本因为 Rush 返回非零状态码而终止。
    $ rush change -v

    # 在公共文件夹下安装 NPM 包安装 NPM 包，但是并没有自动执行 "rush link"
    $ rush install --no-link

    # 单独执行 "rush link", 这样 CI 可以将其作为一个单独的步骤来计算开销
    $ rush link

    # 全量构建并实时输出细节日志
    # （假定 "--ship" 已在 common/config/rush/command-line.json 中被定义）
    $ rush rebuild --ship --verbose

    这里有个小插曲 —— 如果你的 CI 环境没有预先安装 Rush, 则可以在项目的根目录下放置一个 package.json, 然后通过 npm install 来安装 Rush. 但这样也会引入一个 node_modules 目录, 进而导致 Rush 的防止幻影依赖的功能失效。

    install-run-rush.js 来启动 Rush​

    幸运的是，这里有更优雅的方式来在 CI 上安装 Rush, 所有的 Rush 仓库都会有一个 common/scripts/install-run-rush.js 脚本, 它会：

    • 寻找 rush.json 文件

    • 读取指定在该文件内的 rushVersion

    • 自动在 common/temp/install-run 目录下安装该版本的 Rush

    • 使用仓库内的 .npmrc 文件进行适当的设置

    • 之后调用 Rush 工具链，并传递给它任何你提供的命令行参数

    上述安装过程是有缓存的，所以上述操作并不会比直接调用 Rush 慢，事实上，对于保存之前运行结果的 CI 系统而言， install-run-rush.js 比 npm install 更快，因为它可以缓存 Git 分支上构建的不同版本的 Rush.

    尝试从你的 shell 中执行脚本:

    ~$ cd my-repo
    ~/my-repo$ node common/scripts/install-run-rush.js --help
    ~/my-repo$ node common/scripts/install-run-rush.js install

    下面我们将介绍如何将这个脚本包含到 Travis 构建定义中。

    install-run.js 来执行其他命令​

    此外，Rush 也提供了第二个脚本 install-run.js 允许你借此来执行任意的 NPM 包。例如，下面时一个打印 Rush 站点二维码的指令： :-)

    ~/my-repo$ node common/scripts/install-run.js qrcode@1.2.2 qrcode https://rushjs.io

    注意 install-run.js 指令有一些不同：它必须要包含包名和其版本（可以是语义化版本，但最好写确定版本），它还需要第二个参数来指令可执行文件的具体名称（通常而言，可执行文件名与包名相同），在上述事例中，我们调用 qrcode 的可执行文件并指定起参数为 https://rushjs.io.

    当然，更直接的方式是将 qrcode 视为某个 package.json 内的一个依赖，例如将其 package.json 放到 tools/repo-scripts 项目下，这种方式会被视为日常安装的一步，并被仓库的 shrinkwrap 文件记录。但是在诸如不需要 rush install 的 CI 任务或者即使 rush install 出现故障时 Git hooks 依旧可用的情况下，这种方式是不可取的。

    "rush init" 中的 Travis 示例​

    Travis CI 是一个整合了 Github 的持续集成工具，它开源且免费，rush init 会创建一个便于使用的 .travis.yml 文件。注意，它使用 install-run-rush.js 来调用 Rush 工具。

    language: node_js
    node_js:
      - '8.9.4'
    script:
      - set -e

      - echo 'Checking for missing change logs...' && echo -en 'travis_fold:start:change\\r'
      - git fetch origin main:refs/remotes/origin/main -a
      - node common/scripts/install-run-rush.js change -v
      - echo -en 'travis_fold:end:change\\r'

      - echo 'Installing...' && echo -en 'travis_fold:start:install\\r'
      - node common/scripts/install-run-rush.js install
      - echo -en 'travis_fold:end:install\\r'

      - echo 'Building...' && echo -en 'travis_fold:start:build\\r'
      - node common/scripts/install-run-rush.js rebuild --verbose
      - echo -en 'travis_fold:end:build\\r'

    关于使用 Azure Devops 构建的示例，你可以参考用于部署 Rush 的 build.yaml 文件.

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/enabling_prettier/index.html b/zh-cn/pages/maintainer/enabling_prettier/index.html index 4b533ff3..082a057e 100644 --- a/zh-cn/pages/maintainer/enabling_prettier/index.html +++ b/zh-cn/pages/maintainer/enabling_prettier/index.html @@ -6,13 +6,13 @@ 启用 Prettier | Rush - +
    Rush StackShopBlogEvents

    启用 Prettier

    Rush 中的格式化策略 推荐使用 Prettier 来确保代码的一致性，该方法下，ESLint 和 Prettier 具有互补的作用：

    推荐的 ESLint 使用方式：

    • ESLint 通过一组规则来保障代码的规范性。
      例如：“函数名应该使用骆驼式命名”。
    • 修复这些问题可能会导致测试失败或者 API 不符合约定，ESLint 可能会导致构建失败。
    • 规则是高度可定制的，不同的项目可能需要不同的规则。
    • 因此，我们建议在不同的项目中分开调用 ESLint，作为构建该项目的一部分。

    推荐的 Prettier 使用方式：

    • Prettier 可以优化代码格式。
      例如：缩进和逗号放置
    • 修复这些问题永远不应该影响代码含义，Prettier 可以自动运行并且不可见。
    • Prettier 不建议自定义，一个规范就够了。
    • 因此，我们建议将 Prettier 应用到整个项目中。

    在这篇文章中，我们将说明如何配置 Prettier, 最终让它在 git commit 时自动运行。我们也建议开发者安装 Prettier 的 VS Code 插件, 它会在每次保存时自动格式化文件。

    准备 Prettier​

    我们处理 Git 钩子之前，首先配置 Prettier, 并以此让你的文件格式化。

    1. 由于 Prettier 的运行范围是所有文件，它的配置文件应该放到仓库的根目录上，Prettier 允许多个不同的配置文件名，但 JSON 不能写注释，因此推荐使用 .js 文件扩展名：

      <repo root>/.prettierrc.js

      // 配置可参考 https://prettier.io/en/configuration.html
      module.exports = {
        // 使用较大的打印宽度，因为 Prettier 的换行设置似乎是针对没有注释的 JavaScript.
        printWidth: 110,

        // 使用 .gitattributes 来管理换行
        endOfLine: 'auto',

        // 单引号代替双引号
        singleQuote: true,

        // 对于 ES5 而言, 尾逗号不能用于函数参数，因此使用它们只能用于数组
        trailingComma: 'none'
      };

    2. 你也可以使用 .prettierignore 来告知 Prettier 跳过哪些文件，注意，Git 钩子将会自动过滤掉哪些没有被 commit 的文件，然而诸如 Prettier extension for VS Code 等其他工具并不是如此，因此建议将 .prettierignore 中的内容与 .gitingore 一致：

      <repo root>/.prettierignore

      #-------------------------------------------------------------------------------------------------------------------
      # 保持与 .gitignore 同步
      #-------------------------------------------------------------------------------------------------------------------

      👋 (此处将你的 .gitignore 文件内容复制粘贴过来) 👋

      #-------------------------------------------------------------------------------------------------------------------
      # Prettier 通用配置
      #-------------------------------------------------------------------------------------------------------------------

      # Rush 文件
      common/changes/
      common/scripts/
      common/config/
      CHANGELOG.*

      # 包管理文件
      pnpm-lock.yaml
      yarn.lock
      package-lock.json
      shrinkwrap.json

      # 构建产物
      dist
      lib

      # 在 Markdown 中，Prettier 将会对代码块进行格式化，这会影响输出
      *.md

    3. 配置完后，下一步需要手动调用 Prettier 并将代码格式化，你可以通过查看 Git diff 来调整 .prettierignore 配置，如下：

      # 安装 prettier
      $ npm install --global prettier

      # 进入仓库根目录
      $ cd my-repo

      # 查看 Prettier 会操作哪些文件；并据此该个命令来调整你的 .prettierignore 规则
      $ prettier . --list-different

      # 当你准备好时，这个命令将会批量修复所有的源文件
      $ prettier . --write

    如果你的仓库有很多文件，那么第一次执行 Prettier 时，可能会生成一个巨大的 diff. 在这种情况下，你可以将这些变更合并到一个 PR 中，这样可以方便下一步的审核。

    Git 钩子的要求​

    这次我们将实现一个 Git 钩子，它会在 commit 时自动调用 Prettier。

    注意，git commit 是最关键的操作，因此需要保持它快速且可靠，开发者也许想在没有运行 rush install 前提交更改。在某些情况下，rush install 不能被执行，因为分支可能处于工作状态，因此我们的 Git 钩子不应该依赖于 monorepo 的安装机制。

    我们可以使用 Rush 的 install-run.js 脚本来启动按需 Prettier, 但是它会涉及到一些依赖：

    • pretty-quick: 为了加速操作，我们使用 pretty-quick 来计算出需要 commit 的文件，只有这些文件需要处理，Prettier 不能处理这一部分，因为它不能与 Git 交互。
    • prettier: pretty-quick 的依赖 Prettier.
    • 可选插件：如果你使用了 Prettier 的任何插件，它们需要被 prettier 解析到。

    对于上述情况，Rush 的 "autoisntaller" 功能提供了一个替代 install-run.js 的方案。

    启用 Git 钩子​

    1. 首先，使用 rush init-autoinstaller 来创建一个自动安装程序：

      # 下面指令会创建 common/autoinstallers/rush-prettier/package.json 文件
      $ rush init-autoinstaller --name rush-prettier

    2. 安装依赖并创建 pnpm-lock.yaml 文件：

      $ cd common/autoinstallers/rush-prettier

      # 可以不过下面指令来安装依赖， 也可以直接编辑 package.json 中 'dependencies" 字段
      $ pnpm install prettier
      $ pnpm install pretty-quick

      # （如果你需要插件，也可以安装它们）

      # 完成上面步骤后，执行以下步骤来确保 common/autoinstallers/rush-prettier/ppnpm-lock.yaml 文件是最新的
      $ rush update-autoinstaller --name rush-prettier

    3. 现在，在 common/autoinstallers/rush-prettier 应该有两个文件：package.json 和 pnpm-lock.yaml, 将它们添加到 Git 仓库中，并且提交。

      $ git add package.json
      $ git add pnpm-lock.yaml
      $ git commit -m "Create rush-prettier autoinstaller"

    4. 之后，我们可以创建自定义指令 rush prettier 来唤起 pretty-quick, 将这些指令添加到 command-line.json 文件中：

      common/config/rush/command-line.json

        . . .
        "commands": [
          {
            "name": "prettier",
            "commandKind": "global",
            "summary": "Used by the pre-commit Git hook. This command invokes Prettier to reformat staged changes.",
            "safeForSimultaneousRushProcesses": true,

            "autoinstallerName": "rush-prettier",

            // 它将会唤起 common/autoinstallers/rush-prettier/node_modules/.bin/pretty-quick
            "shellCommand": "pretty-quick --staged"
          }
          . . .

      "autoinstallerName": "rush-prettier" 确保在执行 shell 命令之前安装 Prettier, pretty-quick --staged 将会在 common/autoinstallers/rush-prettier 目录中执行。

    5. 保存完变化后，来通过执行 rush prettier 来测试自定义指令，你可以看到 Rush 会在第一次运行时自动执行一些步骤：(1) 安装正确的 Rush 版本；(2) 安装正确的 PNPM 版本；(3) 安装 rush-prettier/package.json 和它的依赖；(4) 调用 pretty-quick --staged。但当第二次运行时，第一步和第二步已经完成，所以步骤 (4) 不会有任何延迟。

    6. 最后一步是添加一个 Git 钩子，该钩子在 git commit 执行完后自动调用 rush prettier, 为了实现该功能，在 common/git-hooks 目录下创建 pre-commit 文件：

      common/git-hooks/pre-commit

      #!/bin/sh
      # 在 "git commit" 执行时，该钩子会被调用，并且没有参数。如果该钩子想要阻止提交，那么它应该以返回非零状态推出。

      # Invoke the "rush prettier" custom command to reformat files whenever they
      # are committed. The command is defined in common/config/rush/command-line.json
      # and uses the "rush-prettier" autoinstaller.
      # 当 commit 时调用自定义指令 "rush prettier" 来重新格式化文件。该指令定义在 common/config/rush/command-line.json, 并通过 "rush-prettier" 自动安装并使用。
      node common/scripts/install-run-rush.js prettier || exit $?

    7. 安装钩子，运行 rush install。

    8. 在最后合并 PR 之前，你可能想运行 prettier . --write 来重新格式化安装钩子之前的所有文件。

    完成！当 Git 中的更改被提交时，它们将被自动格式化。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/git_hooks/index.html b/zh-cn/pages/maintainer/git_hooks/index.html index e48b1847..d2b628bc 100644 --- a/zh-cn/pages/maintainer/git_hooks/index.html +++ b/zh-cn/pages/maintainer/git_hooks/index.html @@ -6,13 +6,13 @@ 安装 Git 钩子 | Rush - +
    Rush StackShopBlogEvents

    安装 Git 钩子

    Git 版本管理系统允许配置一些钩子脚本，这些脚本将在某个行为执行前唤起（参考 自定义 Git），最基本的实现方式是创建一个带有通用名称的 shell 脚本，例如 pre-commit，post-update，prepare-commit-msg 等等。如果 Git 发现这些脚本在本地的 .git/hooks 目录中，它将在对应的操作执行前执行这些脚本。

    出于安全性考虑，当你克隆一个仓库时候，这些脚本不会被 Git 自动拷贝下来，相反，每个开发者必须手动创建这些文件夹并将其权限设定为可执行，Rush 可以帮你自动完成这个工作。

    配置 Rush 来安装一个 Git 钩子脚本​

    作为示例，假设我们发现开发者写了一个没有很好描述其工作的 commit, 这会导致 Git 记录难以理解。为了解决这个问题，可以添加一个 commit-msg 钩子，该钩子要求 commit 需要满足一定要求，例如，这个简单的 Bash 脚本要求至少有 3 个单词：

    common/git-hooks/commit-msg

    #!/bin/sh
    #
    # 这是一个 Rush 内使用 Git 示例的示例，为了开启这个钩子，需要将文件名重命名为 "commit-msg"
    # 之后执行 `rush install`, 将它从 common/git-hooks 拷贝到 .git/hooks 目录下。
    #
    # 了解更多 Git 钩子
    #
    # Git 的文档可以参考： https://git-scm.com/githooks
    # 一些有用的资源： https://githooks.com
    #
    # 关于这个示例
    #
    # 这个 commit-msg 钩子被 "git commit" 传入一个参数后并调用，该参数是 commit 消息文件的名称。
    # 当遇到问题后，该钩子会以非零状态码退出并显示出合适的消息。
    # 该钩子被允许编辑 commit 消息。

    # 该示例强制要求 commit 消息中至少包含一定数量的单词。
    if [ `cat $1 | wc -w` -lt 3 ]; then
      echo ""
      echo "Invalid commit message: The message must contain at least 3 words."
        exit 1
    fi

    rush init 后生成的示例文件中含有上述事例，你可能需要将 common/git-hooks/commit-msg.sample 拷贝到自己的仓库。

    你可以按照如下方式使用它。

    1. 在 common/git-hooks 目录下添加该文件，并在 Git 上提交。
    2. 当开发者执行 rush install 时，Rush 将会拷贝该文件到 .git/hooks/commit-msg 目录下。
    3. 当你执行 git commit 时，Git 将找到该脚本并调用它。
    4. 如果 commit 消息过短，脚本会返回非零状态码，Git 显示 Invalid commit message 提示并且拒绝操作。

    使用 Rush 来安装这个钩子脚本需要避免使用 Husky 等独立解决方案。注意 Husky 预期你的仓库在根目录上有一个 package.json 和 node_modules 目录，并且 Husky 将会执行每个 Git 操作的 shell 命令（即使未使用的钩子）；使用 Rush 来安装钩子可以避免这些限制。

    注意：如果你需要卸载钩子，可以删除你的 .git/hooks/ 目录下的文件。

    在 "git commit" 时调用 Prettier​

    Prettier 工具保证代码遵守统一的缩进、逗号等格式。通过配置一个 git commit 钩子来自动调用 Prettier, 便可以在不影响其他开发者的情况下进行修复。

    启用 Prettier 一文有手把手的教学。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/npm_registry_auth/index.html b/zh-cn/pages/maintainer/npm_registry_auth/index.html index 8d1d07e4..f1d0b452 100644 --- a/zh-cn/pages/maintainer/npm_registry_auth/index.html +++ b/zh-cn/pages/maintainer/npm_registry_auth/index.html @@ -6,14 +6,14 @@ NPM 仓库认证 | Rush - +
    Rush StackShopBlogEvents

    NPM 仓库认证

    私有 NPM 源可以让你的 NPM 包在内部发布并使用，除了私有源需要授权外，其工作方式与公开的 https://www.npmjs.com/ 类似。每个用户需要获取一个访问口令，通常口令会被保存在 ~/.npmrc 文件内。

    需要私有 NPM 源的大型项目往往有利于：

    • 在团队内以私有的形式分享代码
    • 代理公开仓库的代码来提高可靠性，并审计公开库，并进行安全筛选
    • 通过安装预编译的工具包加速 CI 操作，而不是在每次调用工具前执行 rush install && rush build
    • 在发布到公开的 NPM 仓库前进行安装测试
    • 发布包装后的第三方库
      (与 GitHub URL dependencies 相比，NPM 包提供了更好的 SemVer 版本管理和更好的缓存机制。)

    常用的提供商有：

    对于以测试为目的的私有源头，Verdaccio是一个基于 Node.js 的轻量级 Node.js 服务器，可以运行在 http://localhost 上，并实现了完整的私有仓库功能。

    源的映射​

    私有源的映射被定义在 monorepo .npmrc 文件中。

    下面的示例将从私有源中安装公司的库，从公共源中获取其他包，公司的库的 NPM scope 为 @example.

    common/config/rush/.npmrc

    # 将公司的 NPM scope ("@example")映射到私有源：
    @example:registry=https://my-registry.example.com/npm-private/

    # 否则，使用公共 NPM 仓库
    registry=https://registry.npmjs.org/
    always-auth=false

    # 此处介绍如何在私有源中进行身份校验。
    # 出于安全性的考虑，CI 任务需要从环境变量中获取口令，具体内容由私有源决定。
    # 如果某一行的环境变量时未定义的，那么 Rush 会忽略这一行，这是为了避免从 ~/.npmrc. 中获取口令时产生一个无效的字符串。
    //my-registry.example.com/npm-private/:_password=${MY_CI_TOKEN}
    //my-registry.example.com/npm-private/:username=${MY_CI_USER}
    //my-registry.example.com/npm-private/:always-auth=true

    普遍的是，私有源会有缓存代理，它可以从公共仓库中拿到包，此时，就不需要 NPM scopes 映射了，你的配置项就会是如下：

    common/config/rush/.npmrc

    # 将所有都映射到私有源
    registry=https://my-registry.example.com/npm-private/
    always-auth=true

    # 此处介绍如何在私有源中进行身份校验。
    # 出于安全性的考虑，CI 任务需要从环境变量中获取口令，具体内容由私有源决定。
    # 如果某一行的环境变量时未定义的，那么 Rush 会忽略这一行，这是为了避免从 ~/.npmrc. 中获取口令时产生一个无效的字符串。
    //my-registry.example.com/npm-private/:_password=${MY_CI_TOKEN}
    //my-registry.example.com/npm-private/:username=${MY_CI_USER}

    可以通过 .npmrc 页来了解一些比 .npmrc 优先级更高的配置。

    使用 "rush setup" 来获取口令​

    Rush 近期引入了一个实验性的功能：rush install 可以检测用户的源权限缺失或过期，如果过期，则会询问是否执行 "rush setup", 该命令会引导用户来获取口令，然后更新他们的 ~/.npmrc 文件，新的配置会被合并到以前的配置中。

    "rush setup" 交互示例如下：

    NPM credentials are missing or expired

    ==> Fix this problem now? (y/N) Yes

    This monorepo consumes packages from an Artifactory private NPM registry.

    ==> Do you already have an Artifactory user account? (y/n) Yes

    Please open this URL in your web browser:

      https://my-company.jfrog.io/

    Your user name appears in the upper-right corner of the JFrog website.

    ==> What is your Artifactory user name? example-user

    Click "Edit Profile" on the JFrog website.  Click the "Generate API Key" button if you haven't already done so
    previously.

    ==> What is your Artifactory API key? ***************

    Fetching an NPM token from the Artifactory service...

    Adding Artifactory token to: /home/example-user/.npmrc

    该实现目前只支持 JFrog Artifactory, 其他服务将在未来支持。

    需要在 artifactory.json 配置文件中设置 "registryUrl" 字段，并设置 "enabled": true 后就可以使用该功能。文件模版包含其他可选配置的文档，这些可以用来自定义该交互。

    参考更多​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/package_managers/index.html b/zh-cn/pages/maintainer/package_managers/index.html index f0d60377..2142e1bc 100644 --- a/zh-cn/pages/maintainer/package_managers/index.html +++ b/zh-cn/pages/maintainer/package_managers/index.html @@ -6,13 +6,13 @@ NPM vs PNPM vs Yarn | Rush - +
    Rush StackShopBlogEvents

    NPM vs PNPM vs Yarn

    当你安装 JavaScript 库之前，你需要选择一个包管理工具（由于 JavaScript 社区非常自由活跃，因此包管理工具不止一个）。Rush 支持目前最流行的三种包管理工具，按照时间顺序依次为：

    • NPM: 它是当今最广泛的 JavaScript 包管理工具，它开创了包管理标准，其开发者还维护了世界上最多人使用的分布式开源 JavaScript 包管理网站 npmjs.com.

    • Yarn: 它重新实现了 NPM, 与之相比，Yarn 具有相同的管理方式，但是安装速度更快，稳定性更好，而且提供了一些新特性（例如 Yarn workspaces），用于大型开发。

    • PNPM: 它提供了一个全新的包管理模式，该模式解决了“幻影依赖”和“ NPM 分身”的问题，同时符号链接使之与 NodeJS 模块解析标准保持 100% 兼容。

    当使用 Rush 时应该选择哪个？​

    看你需求而定，Rush 开发者并不宣传特定的包管理工具，但是基于 monorepo 的管理经验而言，我们有以下观点：

    关于 NPM 的思考​

    • NPM 是最具兼容性的选择，并且一些“不友好”的库也可以得到处理。

    • 如果你选择 NPM, 如果你选择使用旧版本，NPM 5.x 和 6.x 都可能导致 Rush 仓库出现问题。NPM 4.5.0 是最新的可靠版本，但是它实在是太旧了（我们使用 GitHub issue #886 来记录进展，非常欢迎并感谢大家来帮助解决目前的问题）。

    如果使用 Rush 与 NPM 结合出现问题时，首先尝试下降级到 "npmVersion": "4.5.0, 如果这样解决了问题，那么你的问题可能就是 NPM 导致的，并且不太方便在 Rush 中解决，我们仍然处理这些问题，但追踪这些问题的方式不同。

    关于 PNPM 的思考​

    • PNPM 是解决 NPM 分身 的唯一选择。在复杂的 monorepo 项目中，NPM 分身 可能会导致很多麻烦，PNPM 在这方面有一个重要的优势。

    • 尽管 PNPM 的链接策略遵循了当下 NodeJS 版本解析辨准，但是很多老包并没有，这可能存在一些兼容性问题。当尝试从 Yarn/NPM 迁移到 PNPM 时，团队需要对一些存在“问题的包”进行一些处理。不兼容性问题经常会出现在：(1) 忘记在 package.json 中列出依赖项；(2) 不以标准的方式实现符号链接。这些“问题”包有非常直接的解决方式，但是对于小团队而言可能比较艰难（PNPM Discord 聊天室 是一个很好寻求帮助的地方）。

    • PNPM 比 NPM 或 Yarn 更新，更少人用，但是它是一个很优秀的软件，微软内有上百个仓库使用了 Rush + PNPM 的组合，我们发现它迅速且可靠。

    • PNPM 是目前唯一支持 --strict-peer-dependencies 的包管理器（参考 rush.json 中的 "strictPeerDependencies" 在 rush.json 中）的选择。

    关于 Yarn 的思考​

    • Rush 对 Yarn 的支持尚处于起步阶段，我们非常希望看到一些反馈并解决它们。

    • Yarn 的安装速度比 NPM 更快（但是比 PNPM 要慢）。

    • Yarn 的 "workspaces" 并没有被 Rush 采用，因为它们的安装方式并没有解决幻影依赖，然而 Rush 链接策略与 workspaces 相似。

    指定你的包管理器​

    在 rush.json 中可以选定包管理器，可以通过编辑三个字段中的一个来指定（(npmVersion, pnpmVersion, 或 yarnVersion）：

    rush.json

    /**
      * 以下字段是用来选定包选择器及其版本。
      * Rush 会安装适用于自身版本的包管理器，这可以保证构建过程和本地环境隔离。
      *
      * 选中一个包选择器："pnpmVersion", "npmVersion", 或 "yarnVersion"。详细信息请参考 Rush 文档。
      */
    "pnpmVersion": "2.15.1",

    // "npmVersion": "4.5.0",
    // "yarnVersion": "1.9.4",

    选完后，删除 common/config/rush 中之前的 shrinkwrap 文件和其他包管理器相关文件。（否则 Rush 将会报告不支持配置文件），然后运行 rush update --full --purge.

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/phased_builds/index.html b/zh-cn/pages/maintainer/phased_builds/index.html index 57ef4376..5ea8bc51 100644 --- a/zh-cn/pages/maintainer/phased_builds/index.html +++ b/zh-cn/pages/maintainer/phased_builds/index.html @@ -6,7 +6,7 @@ Enabling phased builds | Rush - + @@ -15,7 +15,7 @@ script is a single operation.

    Phased builds are a way to increase parallelism, by defining individual operations as phases that can be executed on a project. As an example, if project B depends on project A, we could first build project A, and then begin building project B while running the unit tests for project A in parallel.

    NOTE: Phased builds are built on top of, and require, the build cache feature -- if you haven't already enabled the build cache for your monorepo, see Enabling build cache.

    Enable the experiment​

    In common/config/rush/experiments.json, enable the "phasedCommands" experiment.

    {
      "phasedCommands": true
    }

    Define phases​

    In common/config/rush/command-line.json, add a section "phases", as follows:

    {
      "phases": [
        {
          /**
           * The name of the phase. Note that this value must start with the \"_phase:\" prefix.
           */
          "name": "_phase:build",

          /**
           * The dependencies of this phase.
           */
          "dependencies": {
            "upstream": ["_phase:build"]
          },

          /**
           * Normally Rush requires that each project's package.json has a \"scripts\" entry matching the phase name. To disable this check, set \"ignoreMissingScript\" to true.
           */
          "ignoreMissingScript": true,

          /**
           * By default, Rush returns a nonzero exit code if errors or warnings occur during a command. If this option is set to \"true\", Rush will return a zero exit code if warnings occur during the execution of this phase.
           */
          "allowWarningsOnSuccess": false
        },
        {
          "name": "_phase:test",
          "dependencies": {
            "self": ["_phase:build"]
          },
          "ignoreMissingScript": true,
          "allowWarningsOnSuccess": false
        }
      ]
    }

    In this example, we define two phases -- _phase:build and _phase:test. The _phase:build operation depends on the _phase:build operation of its upstream projects (using the traditional Rush dependency graph). The _phase:test operation does not depend on any upstream projects, but requires the _phase:build operation of its own project to be completed first. Note that phase names must start with _phase:.

    Individual projects can choose not to implement a phase (if ignoreMissingScript is enabled), but they cannot define their own phases, or change the dependencies of phases. This ensures that phases will behave consistently within your monorepo, regardless of what subset of projects you are building.

    Redefine the build and test commands​

    In common/config/rush/command-line.json, in the "commands" section, redefine the "build" command to be a phased command instead of a bulk command, and specify what phases you would like it to run. In the example below we also define a "test" command.

    {
      "commands": [
        {
          "commandKind": "phased",
          "name": "build",
          "phases": ["_phase:build"],
          "enableParallelism": true,
          "incremental": true
        },

        // No need to define "rebuild", by default, it is the same as build
        // but with incremental=false.

        {
          "commandKind": "phased",
          "name": "test",
          "summary": "Build and test all projects.",
          "phases": ["_phase:build", "_phase:test"],
          "enableParallelism": true,
          "incremental": true
        },

        {
          "commandKind": "phased",
          "name": "retest",
          "summary": "Build and test all projects.",
          "phases": ["_phase:build", "_phase:test"],
          "enableParallelism": true,
          "incremental": false
        }
      ]
    }

    This command definition shows off another useful feature of phased builds: we can create our "phase" building blocks and then build commands out of them. Instead of rush build running builds and tests for all projects, we can define rush build to mean "build everything without tests", and rush test to mean "build everything and run tests".

    Assign parameters to phases​

    If you have defined any custom parameters for your build command in command-line.json, you'll now need to associate them to phases, so Rush knows which phases can accept your parameter.

    Here are some examples:

    {
      "parameters": [
        {
          "longName": "--production",
          "parameterKind": "flag",
          "description": "Perform a production build, including minification and localization steps",
          "associatedCommands": ["build", "rebuild", "test", "retest"],
          "associatedPhases": ["_phase:build"]
        },
        {
          "longName": "--update-snapshots",
          "parameterKind": "flag",
          "description": "Update unit test snapshots for all projects",
          "associatedCommands": ["test", "retest"],
          "associatedPhases": ["_phase:test"]
        }
      ]
    }

    Here, we've defined one flag (--production) that can be specified on all 4 variations of our build command, but it will only be passed to the build phase. And, we've defined anothe flag (--update-snapshots) that can be specified only on the test and retest commands, and is only passed to the test phase.

    So, if we were to execute this command:

    rush test --production --update-snapshots

    Rush will pass the --production parameter to the _phase:build script for each project, and then pass the --update-snapshots parameter to the _phase:test script for each project.

    Add the phase scripts to your projects​

    Within the package.json file for every project in your monorepo, add the new _phase: scripts:

    {
      "scripts": {
        "_phase:build": "heft build --clean",
        "_phase:test": "heft test --no-build",
        "build": "heft build --clean",
        "test": "heft test --clean"
      }
    }

    The example above attempts to align developer expectations for the build and test commands:

    • Moving into the project folder and running rushx build cleans and builds the project, without testing.
    • Moving into the project folder and running rushx test cleans, builds, and tests the project.
    • Running rush build --only <project> cleans and builds the project, without testing.
    • Running rush test --only <project> cleans, builds, and tests the project.

    Where possible, for any custom phases you define, keep this pattern in mind -- what's important isn't that phases are implemented identically to rushx commands, but rather that rush <something> and rushx <something> produce similar results, if applicable.

    Some projects may not have any meaningful work to do for a phase, in which case you can define it as an empty operation (""), or leave it off entirely, if ignoreMissingScript was specified in the phase definition.

    Define per-phase output folder names​

    Within the rush-project.json configuration file of each project (or, preferably, each rig profile), redefine your operationSettings so that each folder is specified in only one phase. For example:

    {
      "operationSettings": [
        // Old configuration (before phases)
        {
          "operationName": "build",
          "outputFolderNames": ["lib", "lib-commonjs", "dist", "temp"]
        },
        // New configuration (after phases)
        {
          "operationName": "_phase:build",
          "outputFolderNames": ["lib", "lib-commonjs", "dist"]
        },
        {
          "operationName": "_phase:test",
          "outputFolderNames": ["temp/coverage", "temp/jest-reports"]
        }
      ]
    }

    Note how there's no overlap between the output folders specified by _phase:build and _phase:test -- this is an important new requirement for phased builds. In general, it's not possible for Rush to reliably cache the output of an operation if that output can be modified by a different operation, so you should structure your operations such that if _phase:build produces a "lib" folder, no other operation will put output in that folder.

    The phased builds feature is still under development. Feedback is welcome!

    Some relevant GitHub issues to follow:

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/publishing/index.html b/zh-cn/pages/maintainer/publishing/index.html index b8a99b20..23eea141 100644 --- a/zh-cn/pages/maintainer/publishing/index.html +++ b/zh-cn/pages/maintainer/publishing/index.html @@ -6,13 +6,13 @@ 发布包 | Rush - +
    Rush StackShopBlogEvents

    如何在构建流程中使用 Rush 来自动发布更新的包

    Rush 的发布流程中包含两个阶段：第一阶段是在开发期间，开发者需要提供一个变更文件来记录需要发布的变动；第二阶段是在发布期间，Rush 可以收集所有的变更新文件来更新版本、更新发布日志，并发布新的包到 npm 仓库。

    1. 跟踪变更​

    只有当公共的包发生变化时候需要被记录，开发者可以在 rush.json 的 shouldPublish 字段中指定哪些项目需要被发布，哪些不需要被发布。一旦定义公共库后，仓库管理者可以强制开发者更改公开的库后提供变更文件。开发者可以使用一个工具来生成变更文件，并在答题后提交。

    如果让开发者强制提供变更文件​

    rush change --verify

    如果开发者修改了公开的仓库后但没有提供相关的变更文件，该指令会执行失败。建议将该指令添加到 CI 中，可以使没有变更文件时执行失败。

    开发者如何生成变更文件​

    rush change

    执行 rush change 后会向开发者提出几个问题，并根据开发者的回答生成变更记录。变更记录文件包含了版本变化的类型和其描述，该文件应该被提交的仓库中。

    2. 发布包​

    rush publish

    当发布更新的包时候，rush publish 指令会增加包的版本，并发布更新的包，它内部会处理很多事：收集所有的日志文件来确定版本变化的类型、确定需要发布的包、增加依赖包的版本，清理变更文件等。

    该指令有他自己的定义，所以开发者可以在发布包的时候触发它。

    对于不同的目标，rush publish 有一些不同的参数，例如，它支持一个模拟发布模式，该模式下可以验证变更文件并测试变更包，其用例可以参考：

    模拟发布模式​

    rush publish有几种模拟运行的方式，允许您执行发布过程的中间步骤，而不会实际发布到npm上。这对于测试以及在没有npm源用于发布的情况下创建版本增量和更改日志非常有用。

    rush publish

    当没有任何参数运行时，它以只读模式执行整个过程，这意味着更改不会保存到磁盘，不会提交到源代码仓库，也不会真正发布软件包。如果您想检查版本增加和更改日志更新是否正确，这将非常有用。

    rush publish --apply

    在这种模式下，更改会添加到CHANGELOG文件中，并且package.json文件会更新为新的版本号，但不会提交到源代码仓库或发布。如果您希望在提交到源代码仓库或发布到软件包存储库之前查看或编辑其中任何文件，这将非常有用。

    rush publish --apply --target-branch targetBranch

    在这种模式下，更改会被提交到一个新的Git分支（以publish- 为前缀），该分支将基于 targetBranch 创建。如果将 targetBranch 设置为 repository.defaultBranch 中指定的分支，运行此命令将实际上执行几乎与“实时”发布相同的操作（包括提交到Git源），只是没有实际发布到npm源。

    发布模式​

    发布模式下还有一些额外的参数：发布到哪个源上，使用哪个 token，是否包含提交信息。

    rush publish --apply --target-branch targetBranch --publish

    上述指令将增加版本号，commit 记录到目标分支上，以及基于环境中的 npm 源来将包发布到指定源上。

    rush publish --apply --target-branch targetBranch --publish --registry registryUrl --npm-auth-token npmToken

    除了之前指令的效果外，上述指令还可以使用指定的 token 来发布到指定源上。

    rush publish --apply --target-branch targetBranch --publish --registry registryUrl --npm-auth-token npmToken --add-commit-details

    除了之前指令的效果外，上述指令还将包含变更日志中的提交信息。

    打包模式​

    除了发布外，还可以将输出打包到 .tgz 文件中。

    rush publish --pack --include-all --publish

    注意：--publish 参数将禁运掉模拟发布模式，这样可以将文件内容写入到磁盘上。

    你也可以将该命令与 --release-folder 结合使用，来指定输出文件的位置。

    1. 版本策略

    当 Rush 内仓库数量逐渐增加时，就需要考虑如何通知项来进行不同类型的版本变更，此时，引入了版本策略这个新概念。举例来看，rush 和 rush-lib 应该是用相同的版本进行发布，这两个版本应该同时被增加；另一个例子是当开发者创建不同的分支来给不同的主版本服务，再次分支上，开发者不应该修改其主版本。版本策略解决了这种问题，它强制 rush 和 rush-lib you 相同的版本，而其他分支的主版本不可以被修改。

    版本策略是什么​

    版本策略是一系列定义版本如何被变更的规则，它被定义在 common/config/rush/version-policies.json 内，可以参考示例 here. 一个公开的仓库可以通过在 rush.json 中指定 versionPolicyName 来指定版本策略，示例可以参考示例 rush 和 rush-lib 的工程配置。如果多个仓库遵循相同的规则，则可以使用一个版本策略。当你个库被指定版本策略后，它就是变成公开仓库，并可以被 "rush publish" 发布。

    version-policies.json 的范式定义在 here.

    版本策略的两种类型​

    版本策略支持两种类型：lockStepVersion 和 individualVersion. 使用 lockStepVersion 的项目都有一致的版本；使用 individualVersion 的项目会根据变更文件和版本限制来自增版本。

    [
      {
        "policyName": "myPublic",
        "definitionName": "lockStepVersion",
        "version": "1.0.0-dev.6",
        "nextBump": "prerelease"
      },
      {
        "policyName": "myInternal",
        "definitionName": "individualVersion",
        "lockedMajor": 3
      }
    ]

    当使用版本策略时的发布过程​

    当使用版本策略时发布新版本需要两步：第一步是增加包的版本，第二部是将其发布。这两步骤分开是因为很多时候你需要在版本变更后、发包之前进行测试。

    增加版本的命令​

    rush version --bump

    执行 rush version --bump 将会基于其版本策略来增版本号。

    发布包的命令​

    rush publish --include-all

    执行 rush publish --include-all 将会发布所有已经增加版本的公开包。

    4. 总结​

    总而言之，仓库内的整个发布流程都可以通过 Rush 实现自动化。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/recommended_settings/index.html b/zh-cn/pages/maintainer/recommended_settings/index.html index 688c53ee..8a81cc1d 100644 --- a/zh-cn/pages/maintainer/recommended_settings/index.html +++ b/zh-cn/pages/maintainer/recommended_settings/index.html @@ -6,13 +6,13 @@ 推荐设定 | Rush - +
    Rush StackShopBlogEvents

    推荐设定

    当你的仓库构建并运行后，rush.json 中还有一些建议开启的配置项，这些严格的设定可以提高仓库的健康程度和减少维护成本。由于这些配置项要求你修改代码，因此默认是关闭的，同时，这些配置并不适用于所有场景。

    repository.url​

    如果仓库使用 rush change 来记录更新日志，那么强烈建议在 rush.json 中设定 repository.url, 它可以确保 rush change 找到准确的基础分支，尤其是当仓库被其他人 "fork" 的情况下。

    rush.json 示例如下：

      "repository": {
        // 将下面的 URL 为你的仓库的 "git clone" 时使用的 URL
        "url": "https://github.com/microsoft/rush-example"
      }

    ensureConsistentVersions​

    我们推荐将 rush.json 内的 ensureConsistentVersions 设定为 true，它会使得 Rush 在执行以下指令时前执行 rush check:

    • rush update
    • rush link
    • rush version
    • rush publish

    该指令会去检查每个项目的 package.json 文件并保证所有的依赖都是同一个版本，该配置可以避免版本不一致导致的问题，因此推荐你打开。

    在某些特殊情况下不同版本可能更适用些，例如，你可能希望逐步更新项目内的 TypeScript 版本，而不是一次性的，在此期间，你需要使用两个不同的 typescript 版本。对于该情况，你可以在 common-versions.json 中添加一个 allowedAlternativeVersions 字段。

    NOTE: 注意：在早期的 Rush 版本中，CI 脚本示例将 rush check 视为一个单独的构建步骤；如果开启 ensureConsistentVersions，那么你可以将 rush check 从 CI 构建步骤中删除。

    strictPeerDependencies​

    如果你使用 PNPM 包管理器，那么强烈建议你将 rush.json 中的 strictPeerDependencies 设定为 true，它会使得 Rush 在安装时开启 PNPM 的 --strict-peer-dependencies 配置项。开启后，如果出现不兼容的依赖版本时候，即不满足 peerDependencies 时，rush install 将会执行失败（出于历史原因，JavaScript 的包管理器通常不会将其视为一个错误）。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/setup_new_repo/index.html b/zh-cn/pages/maintainer/setup_new_repo/index.html index cb8fab9d..f1aff62b 100644 --- a/zh-cn/pages/maintainer/setup_new_repo/index.html +++ b/zh-cn/pages/maintainer/setup_new_repo/index.html @@ -6,13 +6,13 @@ 创建一个新的仓库 | Rush - +
    Rush StackShopBlogEvents

    创建一个新的仓库

    创建一个新的仓库该教程讲述了将几个项目合并成一个新的 Rush monorepo 的过程（如果你想看最终结果，可以在 GitHub 上查看 rush 示例）。

    假设我们有三个项目目录：

    • my-app: 一个页面应用。

    • my-controls: 页面应用使用的控件库。

    • my-toolchain: NodeJS 实现的用于编译其他项目的工具。

    起初每个项目在自身的目录下，它们都是通过这样的繁琐的方式来构建的：

    ~$ cd my-toolchain
    ~/my-toolchain$ npm run build
    ~/my-toolchain$ npm link
    ~/my-toolchain$ cd ../my-controls
    ~/my-controls$ npm link my-toolchain
    ~/my-controls$ npm run build
    ~/my-controls$ npm link
    ~/my-app$ cd ../my-app
    ~/my-app$ npm link my-toolchain
    ~/my-app$ npm link my-controls
    ~/my-app$ npm run build

    现在让我们将其打造为 Rush 项目

    步骤 1: 检查你的 Rush 版本​

    开始之前，首先确定全局安装了最新的 Rush 版本：

    ~$ npm install -g @microsoft/rush

    注意：如果由于缺少权限而导致访问 NPM 全局目录失败，可以查阅 修复 NPM 配置。

    步骤 2: 使用 "rush init" 初始化你的仓库​

    假定你已经创建了一个空的 GitHub 仓库，该仓库用于拷贝上述项目。先将仓库克隆到本地，然后运行 rush init 来生成 Rush 的配置文件：

    ~$ git clone https://github.com/my-team/my-repo
    ~$ cd my-repo
    ~/my-repo$ rush init

    它将会生成以下文件：（更多信息可查阅 配置文件参考）

    文件用途
    rush.jsonRush 内主要的配置文件
    .gitattributes(如果你不用 Git 可以删除)
    告诉 Git 不要对哪些 shrinkwrap 文件进行合并，因为该操作并不安全
    .gitignore(如果你不用 Git 可以删除)
    告知 Git 不要跟踪哪些文件
    .travis.yml(如果你不用 Travis 可以删除)
    配置 Travis CI 服务来在 PR 中使用 Rush
    common/config/rush/.npmrcRush 用该文件配置源，无论是 PNPM, NPM 或者 Yarn
    common/config/rush/command-line.json用于自定义 Rush 的命令行命令或参数
    common/config/rush/common-versions.json用于指定 NPM 包的版本，它影响 Rush 仓库下所有项目
    common/config/rush/pnpmfile.js(如果不使用 PNPM 可以删除)
    用于解决 package.json 文件下错误的依赖关系
    common/config/rush/version-policies.json用于定义发布配置

    注意：如果你的分支中已经存在这些文件，rush init 将会发出警告并且不会覆盖已有的文件。

    接着，将生成的文件添加到 Git 仓库并且提交到你的分支：

    ~/my-repo$ git add .
    ~/my-repo$ git commit -m "Initialize Rush repo"

    步骤 3: 自定义配置​

    这些模版文件有大量的文档和注释的示例。我们建议你仔细查看它们，以便于你能够理解基本的选项和功能。

    你可以随时修改你的选项，但是 rush.json 中有一些配置项需要一些了解：

    • 选择包管理器: 模版默认使用 PNPM，但是你也可以使用 NPM 或者 Yarn. 可以参考 NPM vs PNPM vs Yarn.

    • 检查你的 Rush 版本：确保 rushVersion 是最新版本，版本列表可查看 NPM 源.

    • 检查其他的版本属性: 同样需要检查下其他的版本字段，例如 pnpmVersion, npmVersion, yarnVersion, nodeSupportedVersionRange

    • 是否使用“类别目录”模型：参考 rush.json 中的 projectFolderMinDepth 和 projectFolderMaxDepth 的注释，并计划好 monorepo 内的项目目录如何组织。

    • 配置源的访问权限：初始的 .npmrc 被配置为使用公开的 NPM 源。如果你将要使用私有源，你应该更新 common/config/rush/.npmrc 文件。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/setup_policies/index.html b/zh-cn/pages/maintainer/setup_policies/index.html index e806d74f..b63b6cae 100644 --- a/zh-cn/pages/maintainer/setup_policies/index.html +++ b/zh-cn/pages/maintainer/setup_policies/index.html @@ -6,7 +6,7 @@ 启用一些策略 | Rush - + @@ -14,7 +14,7 @@
    Rush StackShopBlogEvents

    启用一些策略

    rush-schema.json 是可以给 rush.json 中定义了一些额外配置项的 JSON 文件。

    projectFolderMinDepth: 控制文件夹大小​

    Rush 仓库可能变得非常大，当你有很多项目时（可能有几个仓库），projectFolderMinDepth 非常利于你指定一个标准的目录结构，以便于你可以瞬间看到哪些文件夹包含可构建的项目，我们建议约定如下：

    • 仓库的顶层文件夹是 "类别文件夹"（例如："~/demo/libraries"）
    • 项目目录永远被签到在类别文件夹下（例如："~/demo/libraries/lib1"）
    • 项目文件夹永远处于第二级（例如：禁止嵌套成 "~/demo/libraries/lib1/lib2"）
    • 交叉项目文件都永远被存储在公共文件夹中（例如："~/demo/common/docs", "~demo/common/scripts" 等）
    • 没有其他例外

    如果你想在 demo 项目尝试此政策，我们可以将项目移动到类别文件夹，比如：

    ~/demo/apps/application
    ~/demo/libraries/lib1
    ~/demo/libraries/lib2

    之后，在 ~/demo/rush.json 中强制项目必须是第二级，比如：

      // 项目文件夹的最小深度
      //（默认值为 1, 即要求路径名中不能有斜杠）
      "projectFolderMinDepth": 2,
      // 项目文件夹的最大深度
      //（默认值为 2, 即要求路径名中只能有一个斜杠）
      "projectFolderMaxDepth": 2,

    allowedEmailRegExps: 避免私人邮件地址​

    Git 要求每一个 commit 必须有姓名和邮件地址，然而，Git 并没有办法校验这些字段，它们的默认从 PC 上全局进行获取，这很容易被忽略。当使用 Git 工作时，人们有时会使用不符合预期的邮箱来进行 commit. 如果仓库由 Github 托管，那么邮箱地址会立即可被 GitHub REST API 可查询的，这样做很容易受到垃圾邮件的侵扰。（GitHub 账户的隐私设置不会影响 "git commit"）

    Rush 可以帮你解决问题，在 rush.json 的 "gitPolicy" 字段中允许你指定一系列邮箱匹配规则，这些规则是正则表达式。（由于它们是 JSON 字符串字面量，所以注意反斜杠的书写）

      "gitPolicy": {
        // Git commit 的允许的可用邮箱的匹配符
        // 它们是不区分大小写的 JavaScript 正则表达式
        // Example: ".*@example\\.com"
        "allowedEmailRegExps": [
          // Require GitHub scrubbed e-mails
          "[^@]+@users\\.noreply\\.github\\.com"
        ],

        // 满足 allowedEmailRegExps 的示例，以 "Mr. Example" 来讲，其有效邮箱为 "mr-example@contoso.com"
        "sampleEmail": "mrexample@users.noreply.github.com"
      },

    当开发者执行 rush install 时，Rush 会检查邮箱地址是否符合匹配规则，如果不符合，会显示如下警告：

    $ rush install
    Rush Multi-Package Build Tool

    Checking Git policy for this repository.

    Hey there!  To keep things tidy, this repo asks you to submit your Git commmits
    using an e-mail like this pattern:

        [^@]+@users\.noreply\.github\.com

    ...but yours is configured like this:

        Bob <bobbles@somewhere.sketchy.int>

    To fix it, you can use commands like this:

        git config --local user.name "Mr. Example"
        git config --local user.email "mrexample@users.noreply.github.com"

    Aborting, so you can go fix your settings.  (Or use --bypass-policy to skip.)

    approvedPackagesPolicy: 检查新的 NPM 包​

    你的团队中的是否存在一些人会经常发现一些振奋人心的库，并尝试将它添加到 package.json 中？但是当需要对外部代码进行法律和安全审查时，这种行为可能会马上不可控。approvedPackagesPolicy 功能可以在新的 NPM 包被引入时进行检查。

    由于需要不同程度的安全审查（例如对外发布的产品与内部项目、内部库不同），Rush 区分了“审查类别”。这使得我们可以依据项目类别来批准一个包，然而当该包被应用在其他地方时仍然被提醒。

    以创建一个新仓库为基础，下面来看如何在 rush.json 中定义一些审查类别，用于“发布”项目与“内部项目”：

    {
      "rushVersion": "4.0.0",
      "npmVersion": "5.5.1",
      "nodeSupportedVersionRange": ">=8.9.0 <9.0.0",

      "approvedPackagesPolicy": {
        "reviewCategories": [ "published", "internal" ],
        // 我们不需要审查 @types 包，因为我们可以假定非类型的库已经被批准
        "ignoredNpmScopes": [ "@types" ]
      },

      "projects": [
        {
          "packageName": "application",
          "projectFolder": "application",
          "reviewCategory": "internal"
        },
        {
          "packageName": "lib1",
          "projectFolder": "lib1",
          "reviewCategory": "internal"
        },
        {
          "packageName": "lib2",
          "projectFolder": "lib2",
          "reviewCategory": "published"
        }
      ]
    }

    当你执行 rush install 时，会生成两个文件来报告你的依赖。这些文件应该添加到 Git 中，并且可以配置为需要审批后才能被修改：

    • ~/demo/common/config/rush/browser-approved-packages.json: 该包被批准用在浏览器内使用，这通常比较严格，所以所有新包将被默认添加到这里。对于这些依赖而言，关注点在：压缩后的体积有多大？ 许可协议是什么？ 是否存在安全性问题？
    • ~/demo/common/config/rush/nonbrowser-approved-packages.json: 该包被批准用在除了浏览器的任何地方，这些包的关注点在于： 它是否会给扰乱 node_modules 目录？ 是否有其他功能类似的包？ 它是另一个包的包装还是其中有有效的代码？

    当执行完 rush install 后，browser-approved-packages.json 文件将会像这样：

    {
      "packages": [
        {
          "name": "@microsoft/gulp-core-build",
          "allowedCategories": [ "internal" ]
        },
        {
          "name": "@microsoft/node-library-build",
          "allowedCategories": [ "internal", "published" ]
        },
        {
          "name": "gulp",
          "allowedCategories": [ "internal", "published" ]
        }
      ]
    }

    对于这个示例而言，上述文件展示了外部依赖 @microsoft/gulp-core-build 在 一个内部项目的 package.json 文件中找到了（假设是 ~/demo/lib1），但是没有在任何一个 "public" 项目中找到（例如 ~/demo/application）。

    Rush 没有办法判断一个 NPM 是否用于浏览器，因此对于那些不用于浏览器的文件，你必须手动将它们移动到 browser-approved-packages.json 内。

    审批的工作方式​

    rush install 执行时，文件的内容将来匹配当前 package.json 的内容，这个文件应该被提交到 Git 中。当开发者创建了一个 PR 时，PR diff 可以被用于触发一个特殊的审批。

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/maintainer/using_rush_plugins/index.html b/zh-cn/pages/maintainer/using_rush_plugins/index.html index f885d900..e80f9b3b 100644 --- a/zh-cn/pages/maintainer/using_rush_plugins/index.html +++ b/zh-cn/pages/maintainer/using_rush_plugins/index.html @@ -6,7 +6,7 @@ Using Rush plugins (experimental) | Rush - + @@ -24,7 +24,7 @@ packages are currently built-in to Rush and enabled automatically. For now, you should NOT register them in rush-plugins.json.

    This is a temporary accommodation while the plugin framework is still experimental. In the next major release of Rush, the build cache packages will need to be configured in standard way.

    Third-party plugins​

    Here's a gallery of some community contributed plugins.

    NPM PackageDescription
    rush-archive-project-pluginArchive Rush projects that are no longer maintained
    rush-init-project-pluginInitialize new Rush projects
    rush-lint-staged-pluginIntegrate lint-staged with a Rush monorepo
    rush-print-log-if-error-pluginPrint a project's entire log file when an error occurs
    rush-sort-package-jsonSort the package.json file entries for Rush projects
    rush-upgrade-self-pluginA helper for upgrading to the latest release of Rush

    If you created an interesting plugin for Rush, let us know in a GitHub issue. Thanks!

    See also​

    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/pages/news/index.html b/zh-cn/pages/news/index.html index 716d87a0..3d053487 100644 --- a/zh-cn/pages/news/index.html +++ b/zh-cn/pages/news/index.html @@ -6,13 +6,13 @@ 最新动态 | Rush - +
    Rush StackShopBlogEvents
    © 2022 Microsoft
    - + \ No newline at end of file diff --git a/zh-cn/search/index.html b/zh-cn/search/index.html index d6d0e4e4..24429382 100644 --- a/zh-cn/search/index.html +++ b/zh-cn/search/index.html @@ -6,13 +6,13 @@ Search the documentation | Rush - +
    Rush StackShopBlogEvents

    Search the documentation

    © 2022 Microsoft
    - + \ No newline at end of file