Azure
/
openapi-tools-common
зеркало из https://github.com/Azure/openapi-tools-common.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность

initialize repo

This commit is contained in:
FAREAST\renhel 2020-10-09 15:54:17 +08:00
Родитель 796f372d00
Коммит 338a4ffa92
11 изменённых файлов: 1032 добавлений и 0 удалений
Показать статистику Скачать Patch файл Скачать Diff файл Показать все файлы Свернуть все файлы

14
.gitattributes поставляемый Normal file
Просмотреть файл

@ -0,0 +1,14 @@
# Don't allow people to merge changes to these generated files, because the result
# may be invalid. You need to run "rush update" again.
pnpm-lock.yaml merge=binary
shrinkwrap.yaml merge=binary
npm-shrinkwrap.json merge=binary
yarn.lock merge=binary
# Rush's JSON config files use JavaScript-style code comments. The rule below prevents pedantic
# syntax highlighters such as GitHub's from highlighting these comments as errors. Your text editor
# may also require a special configuration to allow comments in JSON.
#
# For more information, see this issue: https://github.com/microsoft/rushstack/issues/1088
#
*.json linguist-language=JSON-with-Comments

18
.travis.yml Normal file
Просмотреть файл

@ -0,0 +1,18 @@
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 master:refs/remotes/origin/master -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'

22
common/config/rush/.npmrc Normal file
Просмотреть файл

@ -0,0 +1,22 @@
# Rush uses this file to configure the NPM package registry during installation. It is applicable
# to PNPM, NPM, and Yarn package managers. It is used by operations such as "rush install",
# "rush update", and the "install-run.js" scripts.
#
# NOTE: The "rush publish" command uses .npmrc-publish instead.
#
# Before invoking the package manager, Rush will copy this file to the folder where installation
# is performed. 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}
#
registry=https://registry.npmjs.org/
always-auth=false

20
common/config/rush/.npmrc-publish Normal file
Просмотреть файл

@ -0,0 +1,20 @@
# 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}
#

276
common/config/rush/command-line.json Normal file
Просмотреть файл

@ -0,0 +1,276 @@
/**
* This configuration file defines custom commands for the "rush" command-line.
* For full documentation, please see 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. Rush will look in
// * each project's package.json file for a "scripts" entry whose name matches the
// * command name. 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.
// * 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,
//
// /**
// * (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 master 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
// },
//
// {
// /**
// * (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 value is a simple text string.
// */
// "parameterKind": "string",
// "longName": "--my-string",
// "description": "A custom string parameter for the \"my-global-command\" custom command",
//
// "associatedCommands": ["my-global-command"],
//
// /**
// * The name of the argument, which will be shown in the command-line help.
// *
// * For example, if the parameter name is '--count" and the argument name is "NUMBER",
// * then the command-line help would display "--count NUMBER". The argument name must
// * be comprised of upper-case letters, numbers, and underscores. It should be kept short.
// */
// "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.
// */
// "parameterKind": "choice",
// "longName": "--my-choice",
// "description": "A custom choice parameter for the \"my-global-command\" custom command",
//
// "associatedCommands": ["my-global-command"],
//
// /**
// * If true, this parameter must be included with the command. The default is false.
// */
// "required": false,
//
// /**
// * Normally if a parameter is omitted from the command line, it will not be passed
// * to the shell command. this value will be inserted by default. Whereas if a "defaultValue"
// * is defined, the parameter will always be passed to the shell command, and will use the
// * default value if unspecified. 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 (the default)"
// },
//
// {
// "name": "chocolate",
// "description": "Use the chocolate flavor"
// },
//
// {
// "name": "strawberry",
// "description": "Use the strawberry flavor"
// }
// ]
// }
]
}

62
common/config/rush/common-versions.json Normal file
Просмотреть файл

@ -0,0 +1,62 @@
/**
* This configuration file specifies NPM dependency version selections that affect all projects
* in a Rush repo. For full documentation, please see 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"
// ]
}
}

28
common/config/rush/experiments.json Normal file
Просмотреть файл

@ -0,0 +1,28 @@
/**
* This configuration file allows repo maintainers to enable and disable experimental
* Rush features. For full documentation, please see https://rushjs.io
*/
{
"$schema": "https://developer.microsoft.com/json-schemas/rush/v5/experiments.schema.json",
/**
* Rush 5.14.0 improved incremental builds to ignore spurious changes in the pnpm-lock.json file.
* This optimization is enabled by default. If you encounter a problem where "rush build" is neglecting
* to build some projects, please open a GitHub issue. As a workaround you can uncomment this line
* to temporarily restore the old behavior where everything must be rebuilt whenever pnpm-lock.json
* is modified.
*/
// "legacyIncrementalBuildDependencyDetection": true,
/**
* By default, rush passes --no-prefer-frozen-lockfile to 'pnpm install'.
* Set this option to true to pass '--frozen-lockfile' instead.
*/
// "usePnpmFrozenLockfileForRushInstall": 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
}

38
common/config/rush/pnpmfile.js Normal file
Просмотреть файл

@ -0,0 +1,38 @@
'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;
}

90
common/config/rush/version-policies.json Normal file
Просмотреть файл

@ -0,0 +1,90 @@
/**
* This is configuration file is used for advanced publishing configurations with Rush.
* For full documentation, please see 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"
// },
//
// {
// /**
// * (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
// }
]

25
common/git-hooks/commit-msg.sample Normal file
Просмотреть файл

@ -0,0 +1,25 @@
#!/bin/sh
#
# This is an example Git hook for use with Rush. To enable this hook, rename this file
# to "commit-msg" and then run "rush install", which will copy it from common/git-hooks
# to the .git/hooks folder.
#
# TO LEARN MORE ABOUT GIT HOOKS
#
# The Git documentation is here: https://git-scm.com/docs/githooks
# Some helpful resources: https://githooks.com
#
# ABOUT THIS EXAMPLE
#
# The commit-msg hook is called by "git commit" with one argument, the name of the file
# that has the commit message. The hook should exit with non-zero status after issuing
# an appropriate message if it wants to stop the commit. The hook is allowed to edit
# the commit message file.
# This example enforces that commit message should contain a minimum amount of
# description text.
if [ `cat $1 | wc -w` -lt 3 ]; then
echo ""
echo "Invalid commit message: The message must contain at least 3 words."
exit 1
fi

439
rush.json Normal file
Просмотреть файл

@ -0,0 +1,439 @@
/**
* 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.34.2",
/**
* 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": "4.14.4",
// "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,
/**
* If true, then `rush install` will use the PNPM workspaces feature to perform the
* install.
*
* This feature uses PNPM to peform the entire monorepo install. When using workspaces, Rush will
* generate a "pnpm-workspace.yaml" file referencing all local projects to install. Rush will
* also generate a "pnpmfile.js" which is used to provide preferred versions support. When install
* is run, this pnpmfile will be used to replace dependency version ranges with a smaller subset
* of the original range. If the preferred version is not fully a subset of the original version
* range, it will be left as-is. After this, the pnpmfile.js provided in the repository (if one
* exists) will be called to further modify package dependencies.
*
* This option is experimental. The default value is false.
*/
// "useWorkspaces": 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.13.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": "https://github.com/microsoft/rush-example",
/**
* 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"
"url": "https://github.com/Azure/openapi-tools-common",
"defaultBranch": "master"
},
/**
* 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": ""
// },
//
// {
// "packageName": "my-controls",
// "projectFolder": "libraries/my-controls",
// "reviewCategory": "production"
// },
//
// {
// "packageName": "my-toolchain",
// "projectFolder": "tools/my-toolchain",
// "reviewCategory": "tools"
// }
{
"packageName": "@openapi-tools-common/json-parser",
"projectFolder": "json-parser",
"shouldPublish": true
}
]
}