rush.json

/**
 * 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.62.4",
  "pnpmVersion": "6.32.2",

  /**
   * Options that are only used when the PNPM package manager is selected
   */
  "pnpmOptions": {
    /**
     * If true, then Rush will add the "--strict-peer-dependencies" option when invoking PNPM.
     * This causes "rush install" to fail if there are unsatisfied peer dependencies, which is
     * an invalid state that can cause build failures or incompatible dependency versions.
     * (For historical reasons, JavaScript package managers generally do not treat this invalid
     * state as an error.)
     *
     * The default value is false to avoid legacy compatibility issues.
     * It is strongly recommended to set strictPeerDependencies=true.
     */
    "strictPeerDependencies": true,

    /**
     * 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
  },

  "nodeSupportedVersionRange": ">=14.15.0",

  /**
   * 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,

  "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": "main"

    /**
     * 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": []
  },

  /**
   * 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": "@azure-tools/cadl-ts-client",
      "projectFolder": "packages/client",
      "shouldPublish": true
    },
    {
      "packageName": "@azure-tools/cadl-ts-emitter",
      "projectFolder": "packages/emitter",
      "shouldPublish": true
    },
    {
      "packageName": "@azure-tools/cadl-ts",
      "projectFolder": "packages/lib",
      "shouldPublish": true
    },
    {
      "packageName": "@azure-tools/cadl-ts-sample",
      "projectFolder": "packages/sample",
      "shouldPublish": false
    },
    {
      "packageName": "@azure-tools/cadl-ts-sample-client",
      "projectFolder": "packages/sample-client",
      "shouldPublish": false
    },
    {
      "packageName": "@azure-tools/cadl-ts-sample-consumer",
      "projectFolder": "packages/sample-consumer",
      "shouldPublish": false
    },
    {
      "packageName": "@azure-tools/eslint-config-cadl-ts",
      "projectFolder": "packages/eslint-config",
      "shouldPublish": false
    }
  ]
}