|
/** |
|
* 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.23.6-pr1898.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": "5.0.2", |
|
|
|
// "npmVersion": "4.5.0", |
|
// "yarnVersion": "1.9.4", |
|
|
|
/** |
|
* Options that are only used when the PNPM package manager is selected |
|
*/ |
|
"pnpmOptions": { |
|
/** |
|
* 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 |
|
* (e.g. bugs or incompatibilities when two repos use different releases of PNPM) |
|
* |
|
* RUSH_PNPM_STORE_PATH will override the directory that will be used as the store |
|
* |
|
* In all cases, the store path will be overridden by the environment variable RUSH_PNPM_STORE_PATH. |
|
* |
|
* The default value is "local". |
|
*/ |
|
"pnpmStore": "local", |
|
|
|
/** |
|
* 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, |
|
|
|
|
|
/** |
|
* Configures the strategy used to select versions during installation. |
|
* |
|
* This feature requires PNPM version 3.1 or newer. It corresponds to the "--resolution-strategy" command-line |
|
* option for PNPM. Possible values are "fast" and "fewer-dependencies". PNPM's default is "fast", but this may |
|
* be incompatible with certain packages, for example the "@types" packages from DefinitelyTyped. Rush's default |
|
* is "fewer-dependencies", which causes PNPM to avoid installing a newer version if an already installed version |
|
* can be reused; this is more similar to NPM's algorithm. |
|
* |
|
* After modifying this field, it's recommended to run "rush update --full" so that the package manager |
|
* will recalculate all version selections. |
|
*/ |
|
// "resolutionStrategy": "fast", |
|
|
|
/** |
|
* 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 |
|
}, |
|
|
|
/** |
|
* 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. |
|
*/ |
|
"nodeSupportedVersionRange": ">=12.17.0 <13.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", "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 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 backspashes, and ordinary periods should be "\\.". |
|
*/ |
|
// "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": "mrexample@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": "Applying package updates. [skip-ci]" |
|
}, |
|
|
|
"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 master 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 "master" 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 master branch. |
|
*/ |
|
"url": "git://bitbucket.org/arikon/smart-oil-monorepo.git", |
|
|
|
/** |
|
* The default branch name. This tells "rush change" which remote branch to compare against. |
|
* The default value is "master" |
|
*/ |
|
// "defaultBranch": "master", |
|
|
|
/** |
|
* 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 compability 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, |
|
|
|
/** |
|
* (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 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": [ |
|
// // "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, |
|
// |
|
// /** |
|
// * 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": "" |
|
// }, |
|
|
|
// packages |
|
{ |
|
"packageName": "@smart-oil/fueling-data", |
|
"projectFolder": "packages/fueling-data" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/ofd-ru-client", |
|
"projectFolder": "packages/ofd-ru-client" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/sync-allianz-fueling", |
|
"projectFolder": "packages/sync-allianz-fueling" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/sync-ofd-ru-recipes", |
|
"projectFolder": "packages/sync-ofd-ru-recipes" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/yandex-cloud-clickhouse", |
|
"projectFolder": "packages/yandex-cloud-clickhouse" |
|
}, |
|
|
|
// toolchain |
|
{ |
|
"packageName": "@smart-oil/eslint-config", |
|
"projectFolder": "toolchain/eslint-config" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/jest-config", |
|
"projectFolder": "toolchain/jest-config" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/jest-environment", |
|
"projectFolder": "toolchain/jest-environment" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/prettier-config", |
|
"projectFolder": "toolchain/prettier-config" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/tsconfig", |
|
"projectFolder": "toolchain/tsconfig" |
|
}, |
|
{ |
|
"packageName": "@smart-oil/yc-function-deploy", |
|
"projectFolder": "toolchain/yc-function-deploy" |
|
} |
|
] |
|
} |
