@icebreakers/monorepo-templates 1.2.1 → 1.3.1

package/templates/vitepress/zh/tasks/release.md

@@ -0,0 +1,31 @@
+# 发布包
+
+当改动准备好更新版本并发布时，使用这个任务页。任何写入 registry 的操作都应该先经过可审查的发布计划。
+
+## 前置条件
+
+- `repo doctor` 报告包管理器和发布配置有效。
+- 工作区除本次改动外保持干净。
+- 每个可发布改动都有 changeset 或仓库约定的 intent 文件。
+
+## 最小命令
+
+```bash
+repo release --dry-run
+```
+
+检查包组、版本、变更日志和发布命令。计划确认后，再去掉 `--dry-run` 执行发布。
+
+## 预期结果
+
+发布报告会列出将要变化的包、版本决策和每个子进程。发布成功后，还会执行配置好的 post-publish hooks。
+
+## 常见分支
+
+- 缺少 intent：添加 changeset 后重新生成计划。
+- 固定版本组不一致：先检查包之间的关系，再修改版本。
+- registry 认证失败：刷新本地 token 后重试，不要提交凭据。
+
+## 下一步
+
+阅读[发包与变更日志](/zh/learn/monorepo/publish)，再查看[报告与输出](/zh/tasks/reports)了解 CI 产物。

package/templates/vitepress/zh/{repoctl → tasks}/reports.md

@@ -4,6 +4,31 @@ description: 说明 repoctl 的 JSON、Markdown、out、redact、env info、env
 
 # 报告与自动化输出
 
+## 适用场景
+
+当成员、CI 或支持请求需要一份可保存的诊断或计划记录时，使用这个任务。
+
+## 前置条件
+
+- 选择一个被忽略或会作为 CI artifact 上传的 `reports/` 目录。
+- 分享环境信息前使用 `--redact`。
+
+## 最小命令
+
+```bash
+repo env support --markdown --redact --out reports/support.md
+```
+
+## 预期输出
+
+输出文件包含稳定的标题和命令结果，可以附在 pull request 或 issue 中。
+
+## 常见分支
+
+- 其他工具需要读取结果：使用带 `--json` 的 JSON 输出。
+- 只想查看计划：把 `--dry-run` 和目标格式一起使用。
+- 报告中出现本地路径或 token：加上 `--redact` 重新生成。
+
 repoctl 的报告能力用于把本地上下文变成可保存、可脱敏、可给脚本读取的文件。它适合 CI artifact、issue 模板、编辑器集成和跨机器排障。
 
 ## 1. 通用输出参数

package/templates/vitepress/zh/{repoctl → tasks}/troubleshooting.md

@@ -1,4 +1,30 @@
-# 排障与报告
+# 排障
+
+## 适用场景
+
+初始化、校验、模板或自动化出现意外结果时，使用这个任务。
+
+## 前置条件
+
+- 在仓库根目录执行命令。
+- 保留原始错误和仓库 revision。
+- 分享命令输出前移除敏感值。
+
+## 最小命令
+
+```bash
+repo doctor --markdown --redact --out reports/doctor.md
+```
+
+## 预期输出
+
+报告会指出仓库根目录、包管理器、workspace 配置、工具链和第一个失败的检查。
+
+## 常见分支
+
+- 命令从子目录执行：切换到 workspace 根目录。
+- 配置文件和受管资产冲突：先查看计划，再决定是否覆盖。
+- 模板键不存在：使用 `repo templates` 列出模板。
 
 repoctl 的排障重点不是让你猜错在哪里，而是尽量输出可以复现、可以保存、可以发给同事的报告。
 
@@ -51,13 +77,13 @@ repo env paths --markdown --redact --out reports/paths.md
 
 ## 先判断问题类型
 
-| 现象                           | 优先命令                                  | 继续阅读                             |
-| ------------------------------ | ----------------------------------------- | ------------------------------------ |
-| 不确定当前目录是不是仓库根目录 | `repo doctor`                             | [doctor 诊断](./doctor.md)           |
-| 不知道 `repo check` 会跑什么   | `repo check --dry-run`                    | [校验链路](./checks.md)              |
-| CI 失败但日志不完整            | `repo env support --markdown --redact`    | [报告与自动化输出](./reports.md)     |
-| 模板创建结果不符合预期         | `repo new <name> --template <key> --json` | [模板资产治理](./template-assets.md) |
-| 模板列表或元数据异常           | `repo templates --check`                  | [模板资产治理](./template-assets.md) |
+| 现象                           | 优先命令                                  | 继续阅读                                      |
+| ------------------------------ | ----------------------------------------- | --------------------------------------------- |
+| 不确定当前目录是不是仓库根目录 | `repo doctor`                             | [doctor 诊断](/zh/start/diagnose)             |
+| 不知道 `repo check` 会跑什么   | `repo check --dry-run`                    | [运行校验](/zh/tasks/checks)                  |
+| CI 失败但日志不完整            | `repo env support --markdown --redact`    | [报告与自动化输出](/zh/tasks/reports)         |
+| 模板创建结果不符合预期         | `repo new <name> --template <key> --json` | [模板资产治理](/zh/reference/template-assets) |
+| 模板列表或元数据异常           | `repo templates --check`                  | [模板资产治理](/zh/reference/template-assets) |
 
 ## 常见问题
 
@@ -103,8 +129,8 @@ repo check --json --out reports/check-plan.json
 
 ## 继续阅读
 
-- [工作流与 CI](./workflows.md)
-- [命令速查](./commands.md)
-- [doctor 诊断](./doctor.md)
-- [报告与自动化输出](./reports.md)
-- [命令别名](./aliases.md)
+- [把校验加入 CI](/zh/tasks/ci)
+- [命令速查](/zh/reference/commands)
+- [doctor 诊断](/zh/start/diagnose)
+- [报告与自动化输出](/zh/tasks/reports)
+- [命令别名](/zh/reference/aliases)

package/templates/vue-lib/package.json

@@ -6,7 +6,7 @@
   "description": "Internal Vue library template shipped with repoctl",
   "author": "ice breaker <hi@sonofmagic.top>",
   "license": "ISC",
-  "homepage": "https://repo.icebreaker.top",
+  "homepage": "https://repoctl.icebreaker.top",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/sonofmagic/repoctl.git",
@@ -60,9 +60,9 @@
     "@vue/test-utils": "^2.4.11",
     "@vue/tsconfig": "^0.9.1",
     "jsdom": "^30.0.1",
-    "vite": "^8.2.1",
+    "vite": "^8.2.2",
     "vite-plugin-dts": "^5.0.3",
     "vue": "^3.5.41",
-    "vue-tsc": "^3.3.10"
+    "vue-tsc": "^3.3.11"
   }
 }

package/assets/netlify.toml

@@ -1,14 +0,0 @@
-[build]
-publish = "dist"
-command = "pnpm run build"
-
-[build.environment]
-NODE_VERSION = "22"
-
-[[redirects]]
-from = "/*"
-to = "/index.html"
-status = 200
-
-[context.deploy-preview]
-ignore = "exit 0"

package/templates/vitepress/getting-started.md

@@ -1,11 +0,0 @@
-# Getting Started
-
-The current setup guide is [repoctl Getting Started](./repoctl/getting-started.md).
-
-```bash
-pnpm add -D repoctl
-pnpm exec repo init
-pnpm exec repo doctor
-```
-
-Use [Adopt Existing Repositories](./repoctl/adopt-existing.md) when introducing repoctl to an established workspace.

package/templates/vitepress/knowledge/index.md

@@ -1,26 +0,0 @@
----
-outline: deep
----
-
-# Knowledge Base
-
-This section explains the engineering decisions behind repoctl rather than only listing commands.
-
-## Monorepo Topics
-
-- [Why Monorepo](../monorepo/index.md)
-- [Managing A Monorepo](../monorepo/manage.md)
-- [Publishing and Changelogs](../monorepo/publish.md)
-- [Command Reference](../monorepo/commands.md)
-- [Template Systems](../monorepo/templates.md)
-- [Troubleshooting](../monorepo/troubleshooting.md)
-
-## Modern Package Topics
-
-- [Reusing JavaScript Code](../why/how-to-reuse-js-code.md)
-- [JavaScript Module Extensions](../why/js-cjs-mjs.md)
-- [What Is An npm Package?](../why/what-is-npm-package.md)
-- [Publishing An npm Package](../why/publish-basic-npm-package.md)
-- [Modern Package Guide](../why/modern/index.md)
-
-Start with the repoctl guide when you need an action. Use this knowledge base when you need to understand the tradeoffs behind that action.

package/templates/vitepress/thinking.md

@@ -1,7 +0,0 @@
-# Project Evolution
-
-This repository began as a reusable monorepo template. It has since evolved into repoctl: a task-first CLI for initializing, diagnosing, creating, validating, upgrading, and releasing pnpm and Turborepo monorepos.
-
-Templates remain an important capability, but they are now private source workspaces packaged through `@icebreakers/monorepo-templates`, not the product identity or independent release units.
-
-See the [repoctl overview](./repoctl/index.md) for the current architecture and public entrypoints.

package/templates/vitepress/tools/changeset.md

@@ -1,25 +0,0 @@
-# pnpm Versioning
-
-This repository uses pnpm change intents and workspace versioning for releases.
-
-## Daily Development
-
-```bash
-pnpm change
-pnpm change status
-```
-
-Choose every publishable package whose public behavior changed and record the correct patch, minor, or major level. Private template workspaces are not release units.
-
-## Release
-
-```bash
-repo release stable prepare
-repo release stable publish
-```
-
-repoctl coordinates the release workflow, validates configuration, and publishes metadata. pnpm owns the versioning state and repository changelog storage.
-
-## Prerelease Lanes
-
-Use `repo release pre enter <tag>`, `repo release pre publish`, and `repo release pre exit` for alpha, beta, rc, or next lanes.

package/templates/vitepress/tools/husky.md

@@ -1,12 +0,0 @@
-# Husky
-
-Husky connects repository scripts to Git hooks. repoctl-managed workspaces use it as a thin entrypoint, keeping verification logic in versioned commands.
-
-```sh
-# .husky/pre-commit
-pnpm exec repo verify pre-commit
-```
-
-Use `commit-msg` for commitlint and `pre-push` for broader build and test verification. Hooks should remain fast enough for local work and should not contain duplicated task logic.
-
-`repo doctor` reports when Husky and lint-staged are only partially configured. `repo upgrade` can synchronize the managed defaults.

package/templates/vitepress/tools/lint-staged.md

@@ -1,12 +0,0 @@
-# lint-staged
-
-lint-staged runs checks only for files included in the next commit.
-
-The repository policy routes JavaScript, TypeScript, and Vue files through ESLint, style files through Stylelint, and TypeScript or Vue files to the owning workspace's typecheck script.
-
-```bash
-pnpm exec repo verify pre-commit
-pnpm exec repo verify staged-typecheck <files...>
-```
-
-Vue workspaces should use `vue-tsc`; plain TypeScript workspaces should use `tsc`. Keep the routing in `lint-staged.config.js` so local hooks and CI can share the same contract.

package/templates/vitepress/tools/pnpm.md

@@ -1,15 +0,0 @@
-# pnpm
-
-pnpm owns workspace discovery, dependency installation, script execution, and versioning configuration.
-
-```bash
-pnpm install
-pnpm --filter <package> build
-pnpm -r test
-pnpm change
-pnpm change status
-```
-
-`pnpm-workspace.yaml` is the source of truth for package patterns and release groups. repoctl can diagnose missing patterns and synchronize recommended defaults, but pnpm remains the package manager.
-
-Prefer exact workspace filters in automation and keep `packageManager` plus `engines.node` declared at the repository root.

package/templates/vitepress/tools/renovate.md

@@ -1,7 +0,0 @@
-# Renovate
-
-Renovate opens dependency update pull requests according to repository policy.
-
-Group related tooling updates, respect pnpm workspace constraints, and let the normal build, lint, typecheck, tsd, and test matrix validate each update. Avoid combining unrelated runtime and tooling upgrades when separate review makes regressions easier to isolate.
-
-repoctl does not replace Renovate. It provides the diagnostic and verification commands that Renovate pull requests can run consistently.

package/templates/vitepress/tools/turborepo.md

@@ -1,14 +0,0 @@
-# Turborepo
-
-Turborepo runs the monorepo task graph and caches repeatable work.
-
-```bash
-pnpm build
-pnpm lint
-pnpm typecheck
-pnpm test
-```
-
-Root scripts delegate to `turbo run`. Package scripts define the actual build, lint, typecheck, and test commands; `turbo.json` defines dependencies, inputs, outputs, and cache behavior.
-
-Mark generated artifacts as task outputs and declare upstream dependencies such as `build` before tests that consume built packages.

package/templates/vitepress/why/examples/2.npm-basic-package/README.md

@@ -1 +0,0 @@
-https://repo.icebreaker.top/

package/templates/vitepress/why/examples/3.npm-basic-package/README.md

@@ -1 +0,0 @@
-https://repo.icebreaker.top/

package/templates/vitepress/why/how-to-reuse-js-code.md

@@ -1,9 +0,0 @@
-# Reusing JavaScript Code
-
-JavaScript code can be shared through source modules, workspace packages, or published npm packages. The right boundary depends on ownership and consumers.
-
-- Use a local module for code owned by one package.
-- Use a workspace package when multiple projects in the same repository share versioned behavior.
-- Publish an npm package when external repositories need a stable public API.
-
-In a pnpm workspace, declare internal dependencies with the `workspace:` protocol and let the package build produce explicit runtime and type entrypoints.

package/templates/vitepress/why/js-cjs-mjs.md

@@ -1,12 +0,0 @@
-# JavaScript Module Extensions
-
-Node.js uses file extensions and the nearest `package.json` `type` field to determine module format.
-
-| Extension       | Meaning                                       |
-| --------------- | --------------------------------------------- |
-| `.mjs`          | Always ES module                              |
-| `.cjs`          | Always CommonJS                               |
-| `.js`           | Depends on `package.json` `type`              |
-| `.mts` / `.cts` | TypeScript source with explicit module intent |
-
-For published libraries, make the package `exports` map explicit and test both import and require paths when both formats are supported.

package/templates/vitepress/why/js-keywords.md

@@ -1,7 +0,0 @@
-# ESM and CommonJS Runtime Globals
-
-CommonJS provides `require`, `module`, `exports`, `__filename`, and `__dirname`. ES modules use `import`, `export`, `import.meta.url`, and `createRequire` when interoperability is required.
-
-Avoid assuming CommonJS globals exist inside ESM. Resolve file paths with `fileURLToPath(import.meta.url)` and prefer static imports so bundlers and type checkers can understand dependencies.
-
-See [ESM vs CommonJS](./modern/esm-vs-cjs.md) for package-level guidance.

package/templates/vitepress/why/modern/bundlers.md

@@ -1,5 +0,0 @@
-# Bundlers
-
-Library bundlers turn source modules into publishable runtime and declaration artifacts. The repository's TypeScript library asset uses [tsdown](https://github.com/sonofmagic/repoctl/tree/main/templates/tsdown), while the Vue library asset adds Vue-specific build and type checking.
-
-Configure entrypoints, external dependencies, output formats, source maps, and declarations according to the package contract. Applications and libraries have different goals: application builds optimize deployment; library builds preserve reusable public boundaries.

package/templates/vitepress/why/modern/dts.md

@@ -1,7 +0,0 @@
-# Type Declarations
-
-Type declarations are part of a TypeScript package's public API.
-
-Generate `.d.ts` files from the same source revision as runtime output, point `types` and export conditions at files included in the tarball, and use `tsd` tests for important inference and error behavior.
-
-Declaration bundling can simplify public output, but it must preserve module augmentation, generics, and referenced types. Always inspect the packed artifact rather than testing source imports alone.

package/templates/vitepress/why/modern/esm-vs-cjs.md

@@ -1,7 +0,0 @@
-# ESM vs CommonJS
-
-ES modules are the preferred format for new packages. CommonJS remains relevant when consumers or toolchains still require `require()`.
-
-Choose ESM-only when your supported runtime matrix allows it. Publish dual formats only when the compatibility benefit justifies duplicate builds and interop testing.
-
-For dual packages, map `import`, `require`, and `types` conditions explicitly and test each consumer path. Avoid exporting different logical module instances from the two formats.

package/templates/vitepress/why/modern/index.md

@@ -1,14 +0,0 @@
-# Modern Package Guide
-
-Modern packages should expose a small, explicit API and generate artifacts that match their declared contract.
-
-## Checklist
-
-- Choose ESM-only or intentional dual-package support.
-- Declare every public subpath in `exports`.
-- Emit and test type declarations.
-- Keep development-only files out of the package tarball.
-- Validate the supported Node and bundler matrix.
-- Record public changes through repository versioning.
-
-Start with [ESM vs CommonJS](./esm-vs-cjs.md), then review [entry points](./package-entry-points.md) and [declarations](./dts.md).

package/templates/vitepress/why/modern/package-entry-points.md

@@ -1,17 +0,0 @@
-# Package Entry Points
-
-Use the `exports` field to define the package's supported public paths.
-
-```json
-{
-  "exports": {
-    ".": {
-      "types": "./dist/index.d.ts",
-      "import": "./dist/index.js"
-    },
-    "./package.json": "./package.json"
-  }
-}
-```
-
-Do not rely on consumers reaching into undeclared internal files. Every exported path should have runtime output, types where applicable, and a compatibility test.

package/templates/vitepress/why/modern/typescript.md

@@ -1,7 +0,0 @@
-# TypeScript Packages
-
-Use TypeScript to validate source and to publish a precise consumer contract.
-
-Keep the source typecheck separate from artifact generation, enable strict settings appropriate for libraries, and avoid path aliases that cannot be resolved by consumers. Vue packages should run `vue-tsc`; non-Vue TypeScript packages should run `tsc`.
-
-Public type behavior belongs in `tsd` tests. Runtime tests should import built output so module resolution matches delivery.

package/templates/vitepress/why/publish-basic-npm-package.md

@@ -1,19 +0,0 @@
-# Publishing An npm Package
-
-1. Define explicit runtime and type entrypoints.
-2. Build the package and run tests against built artifacts.
-3. Inspect `pnpm pack` output.
-4. Record a change intent and verify the version plan.
-5. Publish with provenance and the intended access level.
-
-```bash
-pnpm build
-pnpm lint
-pnpm typecheck
-pnpm tsd
-pnpm test
-pnpm pack
-pnpm change
-```
-
-Never publish template source workspaces that are intentionally marked `private: true`.

package/templates/vitepress/why/what-is-npm-package.md

@@ -1,7 +0,0 @@
-# What Is An npm Package?
-
-An npm package is a directory described by `package.json`. It can expose runtime code, types, command-line bins, assets, or configuration.
-
-The public contract includes the package name, version, `exports`, `types`, `bin`, supported runtimes, files included in the tarball, and semantic versioning behavior. Treat these fields as API design, not publishing metadata afterthoughts.
-
-Use `pnpm pack` to inspect the exact artifact before publishing.

package/templates/vitepress/zh/getting-started.md

@@ -1,40 +0,0 @@
-# 新手使用指南
-
-这篇旧入口已经收敛到 repoctl 主线。新读者建议直接阅读：
-
-- [repoctl 快速开始](./repoctl/getting-started.md)
-- [repoctl 命令速查](./repoctl/commands.md)
-- [repoctl 配置文件](./repoctl/config.md)
-
-## 先这样用
-
-```bash
-pnpm add -D repoctl
-pnpm exec repo init
-pnpm exec repo doctor
-pnpm exec repo new
-pnpm exec repo check
-```
-
-模板生成仓库里可以使用更短的根脚本：
-
-```bash
-pnpm run repo:init
-pnpm doctor
-pnpm new
-pnpm check
-```
-
-## 知识点保留
-
-理解工具前，先理解这几个边界：
-
-| 命令           | 解决的问题                                            |
-| -------------- | ----------------------------------------------------- |
-| `repo init`    | 补齐仓库默认脚本、workspace patterns 和基础工具链入口 |
-| `repo doctor`  | 判断仓库当前是否可用，并输出可保存的诊断报告          |
-| `repo new`     | 从内置模板创建包、应用、服务、文档站或 CLI            |
-| `repo check`   | 预览或执行提交前推荐校验                              |
-| `repo upgrade` | 同步模板最新标准资产                                  |
-
-如果你是在学习 monorepo 的基础概念，可以继续看 [为什么往 monorepo 方向演进](./monorepo/index.md)。

package/templates/vitepress/zh/knowledge/index.md

@@ -1,50 +0,0 @@
----
-description: repoctl 文档站的知识库入口，汇总 monorepo 管理、现代 npm 包和 JavaScript 模块化基础。
----
-
-# 知识库
-
-知识库用于解释 repoctl 背后的工程背景。这里不放命令速查，而是回答为什么要这样组织仓库、包、构建和发布流程。
-
-## 1. monorepo 主题
-
-| 页面                                               | 适合解决的问题                     |
-| -------------------------------------------------- | ---------------------------------- |
-| [为什么往 monorepo 方向演进](../monorepo/index.md) | 判断多包仓库是否值得合并管理       |
-| [如何管理 monorepo](../monorepo/manage.md)         | 理解 workspace、任务编排和依赖边界 |
-| [发包与变更日志](../monorepo/publish.md)           | 设计 pnpm intent、版本和发布链路   |
-| [monorepo 命令参考](../monorepo/commands.md)       | 查看通用 monorepo 操作命令         |
-| [monorepo 模板体系](../monorepo/templates.md)      | 理解模板如何减少重复初始化         |
-| [monorepo 排障](../monorepo/troubleshooting.md)    | 排查依赖、构建、类型和发布问题     |
-
-## 2. 现代 npm 包主题
-
-| 页面                                                   | 适合解决的问题                     |
-| ------------------------------------------------------ | ---------------------------------- |
-| [如何复用 js 代码](../why/how-to-reuse-js-code.md)     | 从复制文件演进到发布包             |
-| [什么是 npm 包](../why/what-is-npm-package.md)         | 理解 package.json、入口和安装方式  |
-| [如何发布 npm 包](../why/publish-basic-npm-package.md) | 走通最小 npm 发布流程              |
-| [改进并发布现代 npm 包](../why/index.md)               | 把普通包升级成更规范的现代包       |
-| [现代包指南](../why/modern/index.md)                   | 汇总类型、入口、模块格式和构建工具 |
-
-## 3. 阅读顺序
-
-如果你第一次接触 monorepo，建议按下面顺序阅读：
-
-```txt
-为什么 monorepo
-  -> 如何管理 monorepo
-  -> 什么是 npm 包
-  -> 现代包指南
-  -> 发包与变更日志
-```
-
-如果你已经在维护仓库，可以直接从具体问题进入：
-
-| 你遇到的问题                  | 建议入口                                        |
-| ----------------------------- | ----------------------------------------------- |
-| workspace 包互相引用不清楚    | [如何管理 monorepo](../monorepo/manage.md)      |
-| 不确定 CJS、ESM、types 怎么配 | [现代包指南](../why/modern/index.md)            |
-| 发布后使用方拿不到类型        | [类型声明](../why/modern/dts.md)                |
-| 包入口太多、导入路径混乱      | [包入口](../why/modern/package-entry-points.md) |
-| CI 和发版流程容易漂移         | [发包与变更日志](../monorepo/publish.md)        |

package/templates/vitepress/zh/thinking.md

@@ -1,88 +0,0 @@
-# 我对 monorepo 的一些思考
-
-## 前言
-
-最近在自己的新项目中，我创建并使用了 [monorepo-template](https://github.com/sonofmagic/monorepo-template) 模板，并不断地做了不少改进。
-
-在此，我想借此机会分享一下这个模板的演变过程，以及我对 `monorepo` 的一些思考。
-
-## 它的由来
-
-为了应对越来越多的发包场景，我创建了 [npm-lib-template](https://github.com/sonofmagic/npm-lib-template) 模板
-
-这是一个 `git` 单仓单 `npm` 包模板，使用 `rollup` 进行打包，然后再发布到 `npm` 和 `github`
-
-然而，在后续开发中，我发现单仓库的模式在某些场景下难以应对。
-
-例如，当需要引用其他自己的包，进行单元测试并再次发包时，这时候往往要在多个项目之间进行来回的切换更改，管理复杂度会迅速上升。
-
-`git submodule` 也是另外一条路子，但是我对每次都要同步 `hash` 感到深恶痛绝，遂放弃 (不过某些极其特殊场景的实现，还是只能利用这个功能)。
-
-因此，我决定要创建一个 [monorepo 项目模板](https://github.com/sonofmagic/monorepo-template) ，以应对这些需求。
-
-## 技术选型
-
-### 管理工具
-
-在 `monorepo` 的管理上，我选择了 `pnpm` 和 `turborepo` 这对组合，原因很简单：它们都非常快。
-
-- `pnpm` 又可以节省磁盘空间，又能够链接自特定的内容寻址存储库，是为快也
-- `turborepo` 有构建缓存，是为快也 `too`.
-
-### 语言与打包
-
-我选择使用纯 `TypeScript` 来编写所有类库项目，并统一使用 `tsdown` 进行打包，默认输出格式为 `cjs` 和 `esm`，并利用 `package.json` 中的 `exports` 字段进行分发。
-
-### 直接调试
-
-在直接调试时，我抛弃了 `dist` + `sourcemap` 的调试方式，使用了 `tsx`，它非常适合调试 `TypeScript` 编写的 `CLI` 项目。
-
-### 测试框架
-
-测试方面，我选择了 `vitest`。
-
-它不仅速度快，还很好地支持 `cjs`、`esm` 和 `TypeScript`，同时也适合 `monorepo` 项目。你可以利用 `turbo` 来执行单个的 `vitest` 任务，也可以利用 `vitest.workspace` 来进行多任务测试。
-
-最初我使用的是 `jest` + `ts-jest`，但它对多格式的混合模块的支持不够理想，最终我选择了 `vitest`。
-
-### 代码规范与质量控制
-
-为了保持代码质量，我使用了 `eslint` 和 `stylelint`，并基于自己的配置包 `@icebreakers/eslint-config` 和 `@icebreakers/stylelint-config` 来进行代码格式化和规范化。
-
-我还为 `.vscode` 配置了一些推荐插件和编辑器选项。
-
-此外，通过 `husky` 添加了 `git hook`，配合 `lint-staged` 对提交的代码进行校验。与 `commitlint` 结合使用，以确保 `git` 提交信息符合规范。
-
-### 本地引用与发包替换
-
-利用 `publishConfig` 会在发包的时候替换 `package.json` 字段的方式，在本地包相互引用的时候，都使用 `Typescript` 源文件的方式导出，在 `publishConfig` 里定义的导出为，真正在不同环境中，指向 `dist` 中不同格式的产物地址。
-
-通过这种方式，可以大大加速整个 `monorepo` 的开发测试速度，避免反复通过 `watch` 来构建 `dist` 和 `sourcemap`，也避免一构建出产物，对应的 `Typescript` 文件，就报错的问题。
-
-### 发包流程
-
-现在使用 pnpm 原生 versioning：用 `pnpm change` 记录意图，用 `pnpm version -r` 生成版本和 changelog，再用 `pnpm publish -r` 发布。版本计划保留在 `.changeset/ledger.yaml`，预发布则由 pnpm lanes 管理。
-
-### Github 相关配置
-
-在 `.github` 目录下，我提供了默认的 `CI/CD` 流程配置，以及用户提交 `issue` 时的模板。经过少量配置后，就可以实现自动发布 `npm` 包、创建 `git tag` 以及生成 `GitHub release`。
-
-此外，模板里还有许多为 `GitHub` 显示优化的 `md` 文档。
-
-## 部署
-
-文档网站通过 `netlify.toml` 配置部署在 `Netlify` 上。最初我使用的是 `Vercel`，但由于**国内**访问速度的原因，最终迁移到了 `Netlify`。
-
-而且由于我是开源项目贡献者的原因，`Netlify` 为我 `免费` 提供了 `Pro` 版本的计划 (通常这需要 `$19/per member/month`)
-
-感谢 `Netlify`! 爱你❤️😍。
-
-如果看到这里的哥们，你也有一定影响力的开源项目，也可以通过下方的链接申请。
-
-https://www.netlify.com/legal/open-source-policy/
-
-## 总结
-
-从单仓到 `monorepo` 的转变不仅仅是对工具的选择，更是对项目管理模式的优化。通过采用合适的工具链，能够更高效地管理多包项目的同时，利用 `CI/CD` 确保代码的质量和发布的顺畅。
-
-希望这些思考对你有所帮助，也欢迎大家提出各种建议和意见。

package/templates/vitepress/zh/why/examples/2.npm-basic-package/README.md

@@ -1 +0,0 @@
-https://repo.icebreaker.top/

package/templates/vitepress/zh/why/examples/3.npm-basic-package/README.md

@@ -1 +0,0 @@
-https://repo.icebreaker.top/

package/templates/vitepress/zh/why/index.md

@@ -1 +0,0 @@
-# 从 0 到 1 构建 monorepo