From befa677c3c2bed38085a62da161366784d971906 Mon Sep 17 00:00:00 2001 From: Alexander Vyzhanov Date: Wed, 8 Dec 2021 05:03:32 +0300 Subject: [PATCH] feat(config-rush-scopes): add config for rush monorepo (#2878) * feat(config-rush-scopes): add config for rush monorepo * fix(config-rush-scopes): support older NodeJS --- @commitlint/config-rush-scopes/CHANGELOG.md | 0 .../fixtures/basic/packages/a/package.json | 4 + .../fixtures/basic/packages/b/package.json | 4 + .../fixtures/basic/rush.json | 441 ++++++++++++++++++ .../fixtures/empty/rush.json | 433 +++++++++++++++++ .../fixtures/scoped/@packages/a/package.json | 4 + .../fixtures/scoped/@packages/b/package.json | 4 + .../fixtures/scoped/rush.json | 441 ++++++++++++++++++ @commitlint/config-rush-scopes/index.js | 33 ++ @commitlint/config-rush-scopes/index.test.js | 69 +++ @commitlint/config-rush-scopes/license.md | 21 + @commitlint/config-rush-scopes/package.json | 42 ++ @commitlint/config-rush-scopes/readme.md | 44 ++ yarn.lock | 17 + 14 files changed, 1557 insertions(+) create mode 100644 @commitlint/config-rush-scopes/CHANGELOG.md create mode 100644 @commitlint/config-rush-scopes/fixtures/basic/packages/a/package.json create mode 100644 @commitlint/config-rush-scopes/fixtures/basic/packages/b/package.json create mode 100644 @commitlint/config-rush-scopes/fixtures/basic/rush.json create mode 100644 @commitlint/config-rush-scopes/fixtures/empty/rush.json create mode 100644 @commitlint/config-rush-scopes/fixtures/scoped/@packages/a/package.json create mode 100644 @commitlint/config-rush-scopes/fixtures/scoped/@packages/b/package.json create mode 100644 @commitlint/config-rush-scopes/fixtures/scoped/rush.json create mode 100644 @commitlint/config-rush-scopes/index.js create mode 100644 @commitlint/config-rush-scopes/index.test.js create mode 100644 @commitlint/config-rush-scopes/license.md create mode 100644 @commitlint/config-rush-scopes/package.json create mode 100644 @commitlint/config-rush-scopes/readme.md diff --git a/@commitlint/config-rush-scopes/CHANGELOG.md b/@commitlint/config-rush-scopes/CHANGELOG.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/@commitlint/config-rush-scopes/fixtures/basic/packages/a/package.json b/@commitlint/config-rush-scopes/fixtures/basic/packages/a/package.json new file mode 100644 index 0000000000..9113c2528e --- /dev/null +++ b/@commitlint/config-rush-scopes/fixtures/basic/packages/a/package.json @@ -0,0 +1,4 @@ +{ + "name": "a", + "version": "1.0.0" +} diff --git a/@commitlint/config-rush-scopes/fixtures/basic/packages/b/package.json b/@commitlint/config-rush-scopes/fixtures/basic/packages/b/package.json new file mode 100644 index 0000000000..c2d84cc127 --- /dev/null +++ b/@commitlint/config-rush-scopes/fixtures/basic/packages/b/package.json @@ -0,0 +1,4 @@ +{ + "name": "b", + "version": "1.0.0" +} diff --git a/@commitlint/config-rush-scopes/fixtures/basic/rush.json b/@commitlint/config-rush-scopes/fixtures/basic/rush.json new file mode 100644 index 0000000000..a858a46ccc --- /dev/null +++ b/@commitlint/config-rush-scopes/fixtures/basic/rush.json @@ -0,0 +1,441 @@ +/** + * 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.56.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": "6.20.3", + // "npmVersion": "6.14.15", + // "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 perform 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. + * + * LTS schedule: https://nodejs.org/en/about/releases/ + * LTS versions: https://nodejs.org/en/download/releases/ + */ + "nodeSupportedVersionRange": ">=16.9.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", + // "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": "chore: 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": "docs: update changelogs [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. + */ + /** TODO: CHANGE THIS **/ + "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" + }, + /** + * 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/ + * + * 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 ". + * + * 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": [ + { + "packageName": "a", + "projectFolder": "packages/a" + }, + { + "packageName": "b", + "projectFolder": "packages/b" + } + // { + // /** + // * 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, + // + // /** + // * 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": "" + // }, + // + // { + // "packageName": "my-controls", + // "projectFolder": "libraries/my-controls", + // "reviewCategory": "production" + // }, + // + // { + // "packageName": "my-toolchain", + // "projectFolder": "tools/my-toolchain", + // "reviewCategory": "tools" + // } + ] +} diff --git a/@commitlint/config-rush-scopes/fixtures/empty/rush.json b/@commitlint/config-rush-scopes/fixtures/empty/rush.json new file mode 100644 index 0000000000..af249b513b --- /dev/null +++ b/@commitlint/config-rush-scopes/fixtures/empty/rush.json @@ -0,0 +1,433 @@ +/** + * 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.56.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": "6.20.3", + // "npmVersion": "6.14.15", + // "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 perform 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. + * + * LTS schedule: https://nodejs.org/en/about/releases/ + * LTS versions: https://nodejs.org/en/download/releases/ + */ + "nodeSupportedVersionRange": ">=16.9.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", + // "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": "chore: 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": "docs: update changelogs [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. + */ + /** TODO: CHANGE THIS **/ + "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" + }, + /** + * 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/ + * + * 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 ". + * + * 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, + // + // /** + // * 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": "" + // }, + // + // { + // "packageName": "my-controls", + // "projectFolder": "libraries/my-controls", + // "reviewCategory": "production" + // }, + // + // { + // "packageName": "my-toolchain", + // "projectFolder": "tools/my-toolchain", + // "reviewCategory": "tools" + // } + ] +} diff --git a/@commitlint/config-rush-scopes/fixtures/scoped/@packages/a/package.json b/@commitlint/config-rush-scopes/fixtures/scoped/@packages/a/package.json new file mode 100644 index 0000000000..7ba283037e --- /dev/null +++ b/@commitlint/config-rush-scopes/fixtures/scoped/@packages/a/package.json @@ -0,0 +1,4 @@ +{ + "name": "@packages/a", + "version": "1.0.0" +} diff --git a/@commitlint/config-rush-scopes/fixtures/scoped/@packages/b/package.json b/@commitlint/config-rush-scopes/fixtures/scoped/@packages/b/package.json new file mode 100644 index 0000000000..3fd2cf7616 --- /dev/null +++ b/@commitlint/config-rush-scopes/fixtures/scoped/@packages/b/package.json @@ -0,0 +1,4 @@ +{ + "name": "@packages/b", + "version": "1.0.0" +} diff --git a/@commitlint/config-rush-scopes/fixtures/scoped/rush.json b/@commitlint/config-rush-scopes/fixtures/scoped/rush.json new file mode 100644 index 0000000000..fd49ec1d07 --- /dev/null +++ b/@commitlint/config-rush-scopes/fixtures/scoped/rush.json @@ -0,0 +1,441 @@ +/** + * 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.56.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": "6.20.3", + // "npmVersion": "6.14.15", + // "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 perform 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. + * + * LTS schedule: https://nodejs.org/en/about/releases/ + * LTS versions: https://nodejs.org/en/download/releases/ + */ + "nodeSupportedVersionRange": ">=16.9.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", + // "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": "chore: 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": "docs: update changelogs [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. + */ + /** TODO: CHANGE THIS **/ + "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" + }, + /** + * 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/ + * + * 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 ". + * + * 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": [ + { + "packageName": "@packages/a", + "projectFolder": "@packages/a" + }, + { + "packageName": "@packages/b", + "projectFolder": "@packages/b" + } + // { + // /** + // * 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, + // + // /** + // * 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": "" + // }, + // + // { + // "packageName": "my-controls", + // "projectFolder": "libraries/my-controls", + // "reviewCategory": "production" + // }, + // + // { + // "packageName": "my-toolchain", + // "projectFolder": "tools/my-toolchain", + // "reviewCategory": "tools" + // } + ] +} diff --git a/@commitlint/config-rush-scopes/index.js b/@commitlint/config-rush-scopes/index.js new file mode 100644 index 0000000000..2c941d2861 --- /dev/null +++ b/@commitlint/config-rush-scopes/index.js @@ -0,0 +1,33 @@ +const Path = require('path'); +const util = require('util'); +const fs = require('fs'); +const jsonc = require('jsonc'); + +const readFilePromisifed = util.promisify(fs.readFile); + +module.exports = { + utils: {getPackages}, + rules: { + 'scope-enum': (ctx) => + getPackages(ctx).then((packages) => [2, 'always', packages]), + }, +}; + +function getPackages(context) { + return Promise.resolve() + .then(() => { + const ctx = context || {}; + const cwd = ctx.cwd || process.cwd(); + + return readFilePromisifed(Path.join(cwd, 'rush.json'), {encoding: 'utf8'}) + .then((content) => jsonc.parse(content)) + .then(({projects}) => projects) + .catch(() => []); + }) + .then((packages) => { + return packages + .map((pkg) => pkg.packageName) + .filter(Boolean) + .map((name) => (name.charAt(0) === '@' ? name.split('/')[1] : name)); + }); +} diff --git a/@commitlint/config-rush-scopes/index.test.js b/@commitlint/config-rush-scopes/index.test.js new file mode 100644 index 0000000000..3d712b695a --- /dev/null +++ b/@commitlint/config-rush-scopes/index.test.js @@ -0,0 +1,69 @@ +import {npm} from '@commitlint/test'; +import config from '.'; + +test('exports rules key', () => { + expect(config).toHaveProperty('rules'); +}); + +test('rules hold object', () => { + expect(config).toMatchObject({ + rules: expect.any(Object), + }); +}); + +test('rules contain scope-enum', () => { + expect(config).toMatchObject({ + rules: { + 'scope-enum': expect.anything(), + }, + }); +}); + +test('scope-enum is function', () => { + expect(config).toMatchObject({ + rules: { + 'scope-enum': expect.any(Function), + }, + }); +}); + +test('scope-enum does not throw for missing context', async () => { + const {'scope-enum': fn} = config.rules; + await expect(fn()).resolves.toBeTruthy(); +}); + +test('scope-enum has expected severity', async () => { + const {'scope-enum': fn} = config.rules; + const [severity] = await fn(); + expect(severity).toBe(2); +}); + +test('scope-enum has expected modifier', async () => { + const {'scope-enum': fn} = config.rules; + const [, modifier] = await fn(); + expect(modifier).toBe('always'); +}); + +test('returns empty value for empty rush repository', async () => { + const {'scope-enum': fn} = config.rules; + const cwd = await npm.bootstrap('fixtures/empty', __dirname); + const [, , value] = await fn({cwd}); + expect(value).toEqual([]); +}); + +test('returns expected value for basic rush repository', async () => { + const {'scope-enum': fn} = config.rules; + const cwd = await npm.bootstrap('fixtures/basic', __dirname); + + const [, , value] = await fn({cwd}); + expect(value).toEqual(['a', 'b']); +}); + +test('returns expected value for scoped lerna repository', async () => { + const {'scope-enum': fn} = config.rules; + const cwd = await npm.bootstrap('fixtures/scoped', __dirname); + + const [, , value] = await fn({cwd}); + + expect(value).toEqual(['a', 'b']); +}); diff --git a/@commitlint/config-rush-scopes/license.md b/@commitlint/config-rush-scopes/license.md new file mode 100644 index 0000000000..9f7de65293 --- /dev/null +++ b/@commitlint/config-rush-scopes/license.md @@ -0,0 +1,21 @@ +The MIT License (MIT) + +Copyright (c) 2016 - present Mario Nebl + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/@commitlint/config-rush-scopes/package.json b/@commitlint/config-rush-scopes/package.json new file mode 100644 index 0000000000..d83ab9c781 --- /dev/null +++ b/@commitlint/config-rush-scopes/package.json @@ -0,0 +1,42 @@ +{ + "name": "@commitlint/config-rush-scopes", + "version": "15.0.0", + "description": "Shareable commitlint config enforcing rush package and workspace names as scopes", + "files": [ + "index.js" + ], + "scripts": { + "deps": "dep-check", + "pkg": "pkg-check" + }, + "repository": { + "type": "git", + "url": "https://github.com/conventional-changelog/commitlint.git", + "directory": "@commitlint/config-rush-scopes" + }, + "keywords": [ + "conventional-changelog", + "commitlint", + "commitlint-config", + "rush" + ], + "author": { + "name": "Alexander Vyzhanov", + "email": "lembdev@gmail.com" + }, + "license": "MIT", + "bugs": { + "url": "https://github.com/conventional-changelog/commitlint/issues" + }, + "homepage": "https://commitlint.js.org/", + "engines": { + "node": ">=v12" + }, + "dependencies": { + "jsonc": "^2.0.0" + }, + "devDependencies": { + "@commitlint/test": "^15.0.0", + "@commitlint/utils": "^15.0.0" + } +} diff --git a/@commitlint/config-rush-scopes/readme.md b/@commitlint/config-rush-scopes/readme.md new file mode 100644 index 0000000000..c6199783ce --- /dev/null +++ b/@commitlint/config-rush-scopes/readme.md @@ -0,0 +1,44 @@ +> Lint your rush project commits + +# @commitlint/config-rush-scopes + +Shareable `commitlint` config enforcing rush package and workspace names as scopes. +Use with [@commitlint/cli](../cli) and [@commitlint/prompt-cli](../prompt-cli). + +## Getting started + +``` +npm install --save-dev @commitlint/config-rush-scopes @commitlint/cli +echo "module.exports = {extends: ['@commitlint/config-rush-scopes']};" > commitlint.config.js +``` + +## Examples + +``` +❯ cat commitlint.config.js +{ + extends: ['@commitlint/config-rush-scopes'] +} + +❯ tree packages + +packages +├── api +├── app +└── web + +❯ echo "build(api): change something in api's build" | commitlint +⧗ input: build(api): change something in api's build +✔ found 0 problems, 0 warnings + +❯ echo "test(foo): this won't pass" | commitlint +⧗ input: test(foo): this won't pass +✖ scope must be one of [api, app, web] [scope-enum] +✖ found 1 problems, 0 warnings + +❯ echo "ci: do some general maintenance" | commitlint +⧗ input: ci: do some general maintenance +✔ found 0 problems, 0 warnings +``` + +Consult [docs/rules](https://conventional-changelog.github.io/commitlint/#/reference-rules) for a list of available rules. diff --git a/yarn.lock b/yarn.lock index 5184bb23b2..97c0a0bcef 100644 --- a/yarn.lock +++ b/yarn.lock @@ -4325,6 +4325,11 @@ fast-levenshtein@^2.0.6, fast-levenshtein@~2.0.6: resolved "https://registry.npmjs.org/fast-levenshtein/-/fast-levenshtein-2.0.6.tgz#3d8a5c66883a16a30ca8643e851f19baa7797917" integrity sha1-PYpcZog6FqMMqGQ+hR8Zuqd5eRc= +fast-safe-stringify@^2.0.6: + version "2.1.1" + resolved "https://registry.npmjs.org/fast-safe-stringify/-/fast-safe-stringify-2.1.1.tgz#c406a83b6e70d9e35ce3b30a81141df30aeba884" + integrity sha512-W+KJc2dmILlPplD/H4K9l9LcAHAfPtP6BY84uVLXQ6Evcz9Lcg33Y2z1IVblT6xdY54PXYVHEv+0Wpq8Io6zkA== + fastq@^1.6.0: version "1.13.0" resolved "https://registry.npmjs.org/fastq/-/fastq-1.13.0.tgz#616760f88a7526bdfc596b7cab8c18938c36b98c" @@ -6063,6 +6068,18 @@ json5@^1.0.1: dependencies: minimist "^1.2.0" +jsonc@^2.0.0: + version "2.0.0" + resolved "https://registry.npmjs.org/jsonc/-/jsonc-2.0.0.tgz#9e2a25100d164a9bb864c57517563717fa882551" + integrity sha512-B281bLCT2TRMQa+AQUQY5AGcqSOXBOKaYGP4wDzoA/+QswUfN8sODektbPEs9Baq7LGKun5jQbNFpzwGuVYKhw== + dependencies: + fast-safe-stringify "^2.0.6" + graceful-fs "^4.1.15" + mkdirp "^0.5.1" + parse-json "^4.0.0" + strip-bom "^4.0.0" + strip-json-comments "^3.0.1" + jsonfile@^4.0.0: version "4.0.0" resolved "https://registry.npmjs.org/jsonfile/-/jsonfile-4.0.0.tgz#8771aae0799b64076b76640fca058f9c10e33ecb"