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",
  // "$schema": "https://raw.githubusercontent.com/microsoft/rushstack/main/libraries/rush-lib/src/schemas/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.
   *
   * The latest version can found here: https://github.com/microsoft/rushstack/blob/main/apps/rush/CHANGELOG.md
   */
  "rushVersion": "5.140.1",
  /**
   * 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.
   *
   * The latest version can found here: https://github.com/pnpm/pnpm/releases
   */
  "pnpmVersion": "9.12.1",
  /**
   * 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://github.com/nodejs/release#release-schedule
   * LTS versions: https://nodejs.org/en/blog/release
   */
  "nodeSupportedVersionRange": ">=18.12.0 <19.0.0 || >=20.9.0 <21.0.0",
  /**
   * If the version check above fails, Rush will display a message showing the current
   * node version and the supported version range. You can use this setting to provide
   * additional instructions that will display below the warning, if there's a specific
   * tool or script you'd like the user to use to get in line with the expected version.
   */
  "nodeSupportedVersionInstructions": "asdf install",
  /**
   * 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": [
      "libraries", // external shipping packages
      "configs", // configuration packages
      "types", // internal typescripts type packages
      "tools", // reusable development tools
      "internals", // internal packages for local development
      "examples" // example libraries/applications for start new packages easier
    ],
    /**
     * 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": "example@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(core): release new version [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": "chore(core): update changelogs [skip ci]",
    /**
     * The commit message to use when commiting changefiles during 'rush change --commit'
     *
     * If no commit message is set it will default to 'Rush change'
     */
    "changefilesCommitMessage": "chore(core): update changefiles"
  },
  "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 main 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 "main" 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 main branch.
     */
    "url": "https://github.com/kc-workspace/kcws-js",
    /**
     * The default branch name. This tells "rush change" which remote branch to compare against.
     * The default value is "main"
     */
    "defaultBranch": "release",
    /**
     * 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,
  /**
   * This is an optional, but recommended, list of allowed tags that can be applied to Rush projects
   * using the "tags" setting in this file.  This list is useful for preventing mistakes such as misspelling,
   * and it also provides a centralized place to document your tags.  If "allowedProjectTags" list is
   * not specified, then any valid tag is allowed.  A tag name must be one or more words
   * separated by hyphens or slashes, where a word may contain lowercase ASCII letters, digits,
   * ".", and "@" characters.
   */
  // "allowedProjectTags": [],
  /**
   * (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": [
    /* @kcws packages */
    {
      "packageName": "@kcws/color",
      "projectFolder": "packages/color",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/dtcheck",
      "projectFolder": "packages/dtcheck",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/equals",
      "projectFolder": "packages/equals",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/error",
      "projectFolder": "packages/error",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/mixin",
      "projectFolder": "packages/mixin",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/random",
      "projectFolder": "packages/random",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/reset.css",
      "projectFolder": "packages/reset.css",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/github-actions",
      "projectFolder": "packages/github-actions",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/astro-decap-cms",
      "projectFolder": "packages/astro-decap-cms",
      "reviewCategory": "libraries",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/heft-node-rig",
      "projectFolder": "packages/heft-node-rig",
      "reviewCategory": "tools",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/heft-web-rig",
      "projectFolder": "packages/heft-web-rig",
      "reviewCategory": "tools",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/eslint-config",
      "projectFolder": "packages-config/eslint-config",
      "reviewCategory": "configs",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/lintstaged-config",
      "projectFolder": "packages-config/lintstaged-config",
      "reviewCategory": "configs",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/prettier-config",
      "projectFolder": "packages-config/prettier-config",
      "reviewCategory": "configs",
      "shouldPublish": true
    },
    {
      "packageName": "@kcws/rspack-config",
      "projectFolder": "packages-config/rspack-config",
      "reviewCategory": "configs",
      "shouldPublish": true
    },
    /* @kctypes packages */
    {
      "packageName": "@kctypes/package_json",
      "projectFolder": "packages-type/package_json",
      "reviewCategory": "types",
      "shouldPublish": true
    },
    {
      "packageName": "@kctypes/generic",
      "projectFolder": "packages-type/generic",
      "reviewCategory": "types",
      "shouldPublish": true
    },
    /* @kcinternals packages */
    {
      "packageName": "@kcinternals/heft-node-rig",
      "projectFolder": "packages-internal/heft-node-rig",
      "reviewCategory": "internals",
      "shouldPublish": true
    },
    {
      "packageName": "@kcinternals/heft-web-rig",
      "projectFolder": "packages-internal/heft-web-rig",
      "reviewCategory": "internals",
      "shouldPublish": true
    },
    {
      "packageName": "@kcinternals/heft-types-rig",
      "projectFolder": "packages-internal/heft-types-rig",
      "reviewCategory": "internals",
      "shouldPublish": true
    },
    {
      "packageName": "@kcinternals/heft-esbuild-plugin",
      "projectFolder": "packages-internal/heft-esbuild-plugin",
      "reviewCategory": "internals",
      "shouldPublish": true
    },
    // {
    //   "packageName": "@kcinternals/heft-stryker-plugin",
    //   "projectFolder": "packages-internal/heft-stryker-plugin",
    //   "reviewCategory": "internals",
    //   "shouldPublish": false
    // },
    /* @kcexamples packages */
    {
      "packageName": "@kcexamples/heft-example-plugin",
      "projectFolder": "packages-example/heft-example-plugin",
      "reviewCategory": "examples",
      "shouldPublish": false
    },
    {
      "packageName": "@kcexamples/local-web-lib",
      "projectFolder": "packages-example/local-web-lib",
      "reviewCategory": "examples",
      "shouldPublish": false
    },
    {
      "packageName": "@kcexamples/local-node-lib",
      "projectFolder": "packages-example/local-node-lib",
      "reviewCategory": "examples",
      "shouldPublish": false
    },
    {
      "packageName": "@kcexamples/github-action",
      "projectFolder": "packages-example/github-action",
      "reviewCategory": "examples",
      "shouldPublish": false
    },
    {
      "packageName": "@kcexamples/node-lib",
      "projectFolder": "packages-example/node-lib",
      "reviewCategory": "examples",
      "shouldPublish": false
    },
    {
      "packageName": "@kcexamples/node-app",
      "projectFolder": "packages-example/node-app",
      "reviewCategory": "examples",
      "shouldPublish": false
    },
    {
      "packageName": "@kcexamples/web-lib",
      "projectFolder": "packages-example/web-lib",
      "reviewCategory": "examples",
      "shouldPublish": false
    },
    {
      "packageName": "@kcexamples/web-app",
      "projectFolder": "packages-example/web-app",
      "reviewCategory": "examples",
      "shouldPublish": false
    }
  ]
}