|
3 | 3 | * Rush features. More documentation is available on the Rush website: https://rushjs.io |
4 | 4 | */ |
5 | 5 | { |
6 | | - "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/experiments.schema.json", |
| 6 | + "$schema": "https://developer.microsoft.com/json-schemas/rush/v5/experiments.schema.json" |
7 | 7 |
|
8 | 8 | /** |
9 | 9 | * By default, 'rush install' passes --no-prefer-frozen-lockfile to 'pnpm install'. |
|
17 | 17 | */ |
18 | 18 | // "usePnpmPreferFrozenLockfileForRushUpdate": true, |
19 | 19 |
|
| 20 | + /** |
| 21 | + * By default, 'rush update' runs as a single operation. |
| 22 | + * Set this option to true to instead update the lockfile with `--lockfile-only`, then perform a `--frozen-lockfile` install. |
| 23 | + * Necessary when using the `afterAllResolved` hook in .pnpmfile.cjs. |
| 24 | + */ |
| 25 | + // "usePnpmLockfileOnlyThenFrozenLockfileForRushUpdate": true, |
| 26 | + |
20 | 27 | /** |
21 | 28 | * If using the 'preventManualShrinkwrapChanges' option, restricts the hash to only include the layout of external dependencies. |
22 | 29 | * Used to allow links between workspace projects or the addition/removal of references to existing dependency versions to not |
|
34 | 41 | * If true, build caching will respect the allowWarningsInSuccessfulBuild flag and cache builds with warnings. |
35 | 42 | * This will not replay warnings from the cached build. |
36 | 43 | */ |
37 | | - "buildCacheWithAllowWarningsInSuccessfulBuild": true, |
| 44 | + // "buildCacheWithAllowWarningsInSuccessfulBuild": true, |
| 45 | + |
| 46 | + /** |
| 47 | + * If true, build skipping will respect the allowWarningsInSuccessfulBuild flag and skip builds with warnings. |
| 48 | + * This will not replay warnings from the skipped build. |
| 49 | + */ |
| 50 | + // "buildSkipWithAllowWarningsInSuccessfulBuild": true, |
38 | 51 |
|
39 | 52 | /** |
40 | 53 | * If true, perform a clean install after when running `rush install` or `rush update` if the |
|
50 | 63 | /** |
51 | 64 | * If true, Rush will not allow node_modules in the repo folder or in parent folders. |
52 | 65 | */ |
53 | | - // "forbidPhantomResolvableNodeModulesFolders": true |
| 66 | + // "forbidPhantomResolvableNodeModulesFolders": true, |
| 67 | + |
| 68 | + /** |
| 69 | + * (UNDER DEVELOPMENT) For certain installation problems involving peer dependencies, PNPM cannot |
| 70 | + * correctly satisfy versioning requirements without installing duplicate copies of a package inside the |
| 71 | + * node_modules folder. This poses a problem for "workspace:*" dependencies, as they are normally |
| 72 | + * installed by making a symlink to the local project source folder. PNPM's "injected dependencies" |
| 73 | + * feature provides a model for copying the local project folder into node_modules, however copying |
| 74 | + * must occur AFTER the dependency project is built and BEFORE the consuming project starts to build. |
| 75 | + * The "pnpm-sync" tool manages this operation; see its documentation for details. |
| 76 | + * Enable this experiment if you want "rush" and "rushx" commands to resync injected dependencies |
| 77 | + * by invoking "pnpm-sync" during the build. |
| 78 | + */ |
| 79 | + // "usePnpmSyncForInjectedDependencies": true, |
| 80 | + |
| 81 | + /** |
| 82 | + * If set to true, Rush will generate a `project-impact-graph.yaml` file in the repository root during `rush update`. |
| 83 | + */ |
| 84 | + // "generateProjectImpactGraphDuringRushUpdate": true, |
| 85 | + |
| 86 | + /** |
| 87 | + * If true, when running in watch mode, Rush will check for phase scripts named `_phase:<name>:ipc` and run them instead |
| 88 | + * of `_phase:<name>` if they exist. The created child process will be provided with an IPC channel and expected to persist |
| 89 | + * across invocations. |
| 90 | + */ |
| 91 | + // "useIPCScriptsInWatchMode": true, |
| 92 | + |
| 93 | + /** |
| 94 | + * (UNDER DEVELOPMENT) The Rush alerts feature provides a way to send announcements to engineers |
| 95 | + * working in the monorepo, by printing directly in the user's shell window when they invoke Rush commands. |
| 96 | + * This ensures that important notices will be seen by anyone doing active development, since people often |
| 97 | + * ignore normal discussion group messages or don't know to subscribe. |
| 98 | + */ |
| 99 | + // "rushAlerts": true, |
| 100 | + |
| 101 | + /** |
| 102 | + * When using cobuilds, this experiment allows uncacheable operations to benefit from cobuild orchestration without using the build cache. |
| 103 | + */ |
| 104 | + // "allowCobuildWithoutCache": true, |
| 105 | + |
| 106 | + /** |
| 107 | + * By default, rush perform a full scan of the entire repository. For example, Rush runs `git status` to check for local file changes. |
| 108 | + * When this toggle is enabled, Rush will only scan specific paths, significantly speeding up Git operations. |
| 109 | + */ |
| 110 | + // "enableSubpathScan": true, |
| 111 | + |
| 112 | + /** |
| 113 | + * Rush has a policy that normally requires Rush projects to specify `workspace:*` in package.json when depending |
| 114 | + * on other projects in the workspace, unless they are explicitly declared as `decoupledLocalDependencies` |
| 115 | + * in rush.json. Enabling this experiment will remove that requirement for dependencies belonging to a different |
| 116 | + * subspace. This is useful for large product groups who work in separate subspaces and generally prefer to consume |
| 117 | + * each other's packages via the NPM registry. |
| 118 | + */ |
| 119 | + // "exemptDecoupledDependenciesBetweenSubspaces": false |
54 | 120 | } |
0 commit comments