forked from microsoft/rush-example
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
155 additions
and
4 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,37 +1,188 @@ | ||
| // 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. | ||
| "rushVersion": "5.1.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": "2.15.1", | ||
| "nodeSupportedVersionRange": ">=6.9.0 <7.0.0 || >=8.9.4 <9.0.0", | ||
|
|
||
| "projectFolderMinDepth": 2, | ||
| /*** "npmVersion": "4.5.0", */ | ||
| /*** "yarnVersion": "1.9.4", */ | ||
|
|
||
| // Options that are only used when the PNPM pacakge manager is selected | ||
| "pnpmOptions": { | ||
| // If true, then Rush will add the "--strict-peer-dependencies" option when invoking PNPM. | ||
| // This causes "rush install" 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.) | ||
| // | ||
| // The default value is false to avoid legacy compatibility issues. | ||
| // It is strongly recommended to set strictPeerDependencies=true. | ||
| /*** "strictPeerDependencies": true */ | ||
| }, | ||
|
|
||
| // Older releases of the NodeJS 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 NodeJS version that is appropriate | ||
| // for your repo. | ||
| "nodeSupportedVersionRange": ">=8.9.4 <9.0.0", | ||
|
|
||
| // 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", "libaries", | ||
| // "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 NodeJS module resolution). | ||
| // | ||
| // The defaults are projectFolderMinDepth=2 and projectFolderMaxDepth=2. | ||
| // | ||
| // To remove these restrictions, you could set projectFolderMinDepth=1 | ||
| // and set projectFolderMaxDepth to a large number. | ||
| /*** "projectFolderMinDepth": 2, */ | ||
| /*** "projectFolderMaxDepth": 2, */ | ||
|
|
||
| // 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." | ||
| // | ||
| // Using the "reviewCategory" field in the "projects" section below, each project can | ||
| // associated with a review category. The approval is recorded in the files | ||
| // "browser-approved-packages.json" and "nonbrowser-approved-packages.json". | ||
| "reviewCategories": [ "main", "tools", "prototypes" ], | ||
|
|
||
| // 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": { | ||
| // Require GitHub scrubbed e-mails | ||
| // Work at a big company? Tired of finding Git commits at work with unprofessional Git | ||
| // emails such as "[email protected]"? 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" | ||
| "allowedEmailRegExps": [ | ||
| "[^@]+@users\\.noreply\\.github\\.com", | ||
| "travis@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": "[email protected]" | ||
| }, | ||
|
|
||
| "repository": { | ||
| // This setting is sometimes needed when using "rush change" with multiple Git remotes. | ||
| // It specifies the remote url for the official Git repository. If this URL is provided, | ||
| // "rush change" will use it to find the right remote to compare against. | ||
| /*** "url": "https://github.com/Microsoft/rush-example" */ | ||
| }, | ||
|
|
||
| // Event hooks are customized script actions that Rush executes when specific events occur | ||
| "eventHooks": { | ||
| // The list of scripts to run before the Rush installation starts | ||
| "preRushInstall": [], | ||
| // The list of scripts to run after the Rush installation finishes | ||
| "postRushInstall": [], | ||
|
|
||
| // The list of scripts to run before the Rush build command starts | ||
| "preRushBuild": [], | ||
|
|
||
| // The list of scripts to run after the Rush build command finishes | ||
| "postRushBuild": [], | ||
| }, | ||
|
|
||
| // 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. | ||
| /*** "hotfixChangeEnabled": false, */ | ||
|
|
||
| // (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", | ||
| "reviewCategory": "main" | ||
|
|
||
| // 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": "main", | ||
|
|
||
| // A list of local projects that appear as devDependencies for this project, but cannot be | ||
| // locally linked because it would create a cyclic dependency; instead, the last published | ||
| // version will be installed in the Common folder. | ||
| /*** "cyclicDependencyProjects": [ ], */ | ||
|
|
||
| // 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, */ | ||
|
|
||
| // 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": "" */ | ||
| }, | ||
|
|
||
| { | ||
| "packageName": "my-controls", | ||
| "projectFolder": "libraries/my-controls", | ||
| "reviewCategory": "main" | ||
| }, | ||
|
|
||
| { | ||
| "packageName": "my-toolchain", | ||
| "projectFolder": "tools/my-toolchain", | ||
|
|
||