@icebreakers/monorepo-templates 0.1.16 → 1.0.0

package/templates/vitepress/monorepo/publish.md

@@ -1,42 +1,71 @@
 # monorepo 发包与变更日志
 
-本模板推荐使用 [`changesets`](https://github.com/changesets/changesets) 管理版本、生成 `CHANGELOG` 并发布 npm 包。它针对 monorepo 场景设计，维护活跃，易于与 CI/CD 集成。
+这套模板默认推荐用 `changesets` 管理版本和 changelog。原因不是“它很流行”，而是它对 monorepo 的工作方式最顺手：
 
-## 为什么选 changesets？
+- 变更是按包记录的
+- 版本升级能自动联动内部依赖
+- changelog 可以稳定产出
+- 很容易接到 CI 里
 
-| 场景         | changesets 能力                                               |
-| ------------ | ------------------------------------------------------------- |
-| 精确记录改动 | 每次变更生成独立的 changeset 文件，说明影响的包与语义版本类型 |
-| 自动生成日志 | 基于 changeset 内容生成结构化的 `CHANGELOG.md`                |
-| 语义化版本   | 支持 `major` / `minor` / `patch`，并处理依赖联动升级          |
-| 自动化发布   | 可在 CI 中自动创建版本 PR 或直接发布到 npm                    |
+## 一条务实的发布流程
 
-## 推荐流程
+先把顺序记住：
 
-> 以下命令默认在仓库根目录执行。
+1. 写代码
+2. 跑校验
+3. 生成 changeset
+4. 合并后 version / publish
 
-### 1. 初始化
+对应到命令，一般是：
 
 ```bash
-pnpm add -D @changesets/cli
-pnpm changeset init
+pnpm build
+pnpm lint
+pnpm typecheck
+pnpm tsd
+pnpm test
+pnpm changeset
+```
+
+如果你改的是公开类型或类库 API，`tsd` 不要省。
+
+## 为什么推荐 `changesets`
+
+| 需求           | `changesets` 的做法                       |
+| -------------- | ----------------------------------------- |
+| 记录哪些包变了 | 每次变更生成单独的 `.changeset/*.md` 文件 |
+| 控制版本类型   | 明确选择 `patch` / `minor` / `major`      |
+| 自动生成日志   | `changeset version` 统一产出 changelog    |
+| 联动内部包版本 | 自动改内部依赖引用                        |
+| CI 自动发布    | 可接 `changesets/action`                  |
+
+## 日常开发阶段怎么做
+
+### 1. 本地先把质量门过掉
+
+```bash
+pnpm build
+pnpm lint
+pnpm typecheck
+pnpm tsd
+pnpm test
 ```
 
-生成 `.changeset/` 目录，用于存放配置与变更记录。
+这一点和仓库的提交要求是一致的。
 
-### 2. 记录变更
+### 2. 记录 changeset
 
 ```bash
 pnpm changeset
 ```
 
-按照提示：
+按提示选择：
 
-1. 选择受影响的包。
-2. 指定版本类型（`patch` / `minor` / `major`）。
-3. 填写 changelog 描述。
+1. 哪些包受影响
+2. 这些包分别是 `patch` / `minor` / `major`
+3. 这次改动怎么写进 changelog
 
-示例输出：
+示例：
 
 ```md
 ---
@@ -44,33 +73,38 @@ pnpm changeset
 "@my/ui": patch
 ---
 
-- feat(utils): 新增时间处理工具
-- fix(ui): 修复按钮颜色
+- feat(utils): 新增时间格式化工具
+- fix(ui): 修复按钮禁用态样式
 ```
 
-### 3. 升级版本并生成 changelog
+### 3. 合并前看一眼影响面
 
-```bash
-pnpm changeset version
-```
+changeset 文件本身就是最便宜的“发布预告”。代码评审时顺手看一下，通常就能避免：
 
-命令会自动：
+- 漏记某个包
+- 版本类型选错
+- changelog 写得太含糊
 
-- 更新受影响包的 `package.json` 版本。
-- 调整内部依赖引用。
-- 为每个包写入或追加 `CHANGELOG.md`。
+## 发布阶段怎么做
 
-### 4. 发布到 npm
+### 手动流程
 
 ```bash
-pnpm changeset publish
+pnpm changeset version
+pnpm publish-packages
 ```
 
-changesets 会只发布有改动的包，并按照依赖顺序执行。
+`changeset version` 会做这些事：
+
+- 更新受影响包的版本号
+- 调整内部依赖版本
+- 生成或更新每个包的 `CHANGELOG.md`
+
+### CI 自动流程
 
-### 5. GitHub Actions 自动化（可选）
+模板推荐结合 `changesets/action`。
 
-结合 `changesets/action` 实现自动创建发布 PR 或直接发布：
+一个常见的工作流结构如下：
 
 ```yaml
 name: Release
@@ -98,8 +132,6 @@ jobs:
       - uses: pnpm/action-setup@v4
       - uses: actions/setup-node@v4
         with:
-          # 这是为了使用新版本的 npm, 只有 npm@11.5.x 以上版本才支持 OIDC
-          # 否则你就必须使用 npm i -g npm@latest 来升级 npm 版本
           node-version: 24
           cache: pnpm
           registry-url: https://registry.npmjs.org
@@ -110,33 +142,72 @@ jobs:
           publish: pnpm publish-packages
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          # npm/action-oidc-auth 会设置 NODE_AUTH_TOKEN 供 publish 使用
 ```
 
-`pnpm publish-packages` 为模板内脚本，可替换为自定义构建+发布流程。
+## 关于 npm 鉴权
+
+现在更推荐在 CI 里使用 OIDC，而不是长期保存一个会过期的 `NPM_TOKEN`。
+
+原因很现实：
+
+- token 会过期
+- token 泄漏风险更高
+- OIDC 更适合自动化发布
+
+所以工作流里建议保留：
+
+```yaml
+permissions:
+  id-token: write
+```
+
+## 常见发布约束
+
+### 私有包不会被发布
+
+如果一个包是：
+
+```json
+{
+  "private": true
+}
+```
+
+那么它通常不会进入 npm 发布流程。
+
+### 没有 changeset 就不会有版本 PR
+
+如果你改了公开包，却没有提交 `.changeset/*.md`，那么后续版本流转通常会断掉。
+
+### 先 build 再发
+
+这个仓库的约定很明确：先 build，再 lint / typecheck / tsd / test，再谈发布。不要跳步。
+
+## 常见问题
+
+### 为什么没有生成 changelog？
+
+通常是下面几种原因：
+
+- 没有执行 `pnpm changeset version`
+- `.changeset/*.md` 没有提交
+- 受影响包实际没有进入版本计算
 
-> 说明：npm 现行 token 默认 90 天过期，推荐在 CI 中使用 OIDC（如上）动态获取 `NODE_AUTH_TOKEN`，无需手动传入 `NPM_TOKEN`。若使用自托管或其他 CI，需要确保工作流具备 `id-token: write` 权限。
+### 如何跳过某个包的发布？
 
-## 与其他方案对比
+- 在 changeset 里不要勾选它
+- 或者把它标记为 `private: true`
 
-| 能力 / 工具    | changesets | lerna 经典模式 | 手写脚本 |
-| -------------- | ---------- | -------------- | -------- |
-| 支持多包       | ✅         | ✅             | ❌       |
-| 自动 changelog | ✅         | 部分支持       | ❌       |
-| 逐条记录变更   | ✅         | ❌             | ❌       |
-| 维护活跃度     | 高         | 低             | 需自养   |
-| CI/CD 集成     | 简单       | 相对繁琐       | 完全手工 |
+### 为什么要在 PR 阶段就看 changeset？
 
-## 常见问题 FAQ
+因为它本质上是在回答一个非常具体的问题：
 
-- **是否可与 `monorepo.config.ts` 联动？** 配置文件主要用于 CLI 行为定制，发布流程仍由 changesets 主导，两者互不冲突。
-- **为何 `CHANGELOG` 没生成？** 确认是否执行了 `pnpm changeset version` 并提交了 `.changeset` 文件。
-- **如何避免发布某些包？** 在创建 changeset 时不勾选即可，或将包标记为 `private: true`。
+“这次改动准备怎么影响发布面？”
 
-## 相关资源
+这个问题越早看，越不容易在合并后补救。
 
-- [changesets 官方文档](https://github.com/changesets/changesets)
-- [模板中的发布工作流示例](https://github.com/sonofmagic/monorepo-template/blob/main/.github/workflows/release.yml)
-- [管理指南：pnpm + Turborepo + monorepo.config](./manage.md)
+## 继续阅读
 
-> 小提示：在 PR 合并前先执行 `pnpm changeset version` 并提交结果，可以在代码审查阶段提前暴露发布影响，避免遗漏。
+- [如何管理 monorepo](./manage.md)
+- [命令速查](./commands.md)
+- [排障指南](./troubleshooting.md)

package/templates/vitepress/monorepo/templates.md

@@ -0,0 +1,67 @@
+# 模板速查
+
+内置模板由 `@icebreakers/monorepo-templates` 维护，CLI、脚手架和文档都复用同一份模板元数据。
+
+## 模板列表
+
+| Key           | Category | Source                | Default target     | Description                         |
+| ------------- | -------- | --------------------- | ------------------ | ----------------------------------- |
+| `tsdown`      | library  | `templates/tsdown`    | `packages/tsdown`  | 使用 tsdown 构建的 TypeScript 库包  |
+| `vue-lib`     | library  | `templates/vue-lib`   | `packages/vue-lib` | Vue 3 组件库模板，适合沉淀可复用 UI |
+| `vue-hono`    | app      | `templates/client`    | `apps/client`      | Vue 3 + Hono 的前后端一体应用模板   |
+| `hono-server` | service  | `templates/server`    | `apps/server`      | Hono API 服务模板                   |
+| `vitepress`   | docs     | `templates/vitepress` | `apps/website`     | VitePress 文档站模板                |
+| `cli`         | tool     | `templates/cli`       | `apps/cli`         | TypeScript 命令行工具模板           |
+
+## 查看模板
+
+```bash
+repo templates
+repo templates tsdown
+repo templates --category library
+```
+
+需要给脚本读取时：
+
+```bash
+repo templates --json
+repo templates tsdown --json
+```
+
+需要同步文档片段时：
+
+```bash
+repo templates --markdown
+repo templates tsdown --markdown
+repo templates --markdown --out docs/templates.md
+```
+
+## 创建前预览
+
+```bash
+repo new sdk --template tsdown --dry-run
+repo new website --template vitepress --dry-run
+repo new website --template vitepress --json
+repo new website --template vitepress --json --out plans/website.json
+```
+
+`--dry-run` 不写入磁盘，只展示模板、源目录、目标目录、package name 和输出的 package json 文件。
+`--json` 输出同一份创建计划的结构化数据，隐含 `--dry-run`，适合 CI、编辑器和自动化脚本。
+`--out <file>` 可以把文本或 JSON 预览写入文件，也隐含 `--dry-run`。
+
+显式传入的 `--template` 会先校验。模板 key 拼错时，命令会失败并提示相近 key，而不是静默回退到默认模板。
+
+## 健康检查
+
+```bash
+repo templates --check
+repo templates --check --json
+```
+
+模板健康检查会确认：
+
+- 模板 source / target 没有重复。
+- 每个模板 source 目录都存在。
+- 每个模板根目录都有 `package.json`。
+- 每个模板都有 category 和 description。
+- 模板源目录里没有会被脚手架过滤掉的临时或生成文件。

package/templates/vitepress/monorepo/troubleshooting.md

@@ -0,0 +1,207 @@
+# 排障指南
+
+这一页不讲原理，直接讲最常见的问题和对应动作。
+
+## 第一反应：先跑 `repo doctor`
+
+如果你不确定问题在哪，先执行：
+
+```bash
+pnpm doctor
+```
+
+需要把诊断结果交给 CI、编辑器或机器人时：
+
+```bash
+pnpm exec repo doctor --json --out reports/doctor.json
+pnpm exec repo doctor --markdown --redact --out reports/doctor.md
+```
+
+需要让 CI 对 warning 也失败时：
+
+```bash
+pnpm exec repo doctor --strict --json --out reports/doctor.json
+pnpm exec repo doctor --strict --markdown --redact --out reports/doctor.md
+```
+
+需要把运行环境一起发给同事、CI 或机器人时：
+
+```bash
+pnpm exec repo env paths --json --out reports/paths.json
+pnpm exec repo env paths --markdown --redact --out reports/paths.md
+pnpm exec repo config inspect --json --out reports/config.json
+pnpm exec repo config inspect --markdown --redact --out reports/config.md
+pnpm exec repo env info --json --out reports/env.json
+pnpm exec repo env info --markdown --redact --out reports/env.md
+pnpm exec repo env snapshot --json --out reports/snapshot.json
+pnpm exec repo env snapshot --markdown --redact --out reports/snapshot.md
+pnpm exec repo env snapshot --markdown --redact --strict --out reports/snapshot.md
+pnpm exec repo env support --json --out reports/support.json
+pnpm exec repo env support --markdown --redact --out reports/support.md
+pnpm exec repo env support --markdown --redact --strict --out reports/support.md
+```
+
+`env paths` 会列出 repoctl / monorepo 配置文件的全部候选扩展名，不只检查 `.ts` 文件。
+如果要把环境报告发给外部协作者，优先加 `--redact` 脱敏本机绝对路径；如果是贴到 issue 或 PR 评论里，用 `--markdown` 生成摘要。
+在 CI 中可以再加 `--strict`，这样会先写出排障包，再在 `doctor` 有 fail 或 warn 时返回失败码。
+
+它会优先帮你排这些低成本但高频的问题：
+
+- 当前目录不是仓库根目录
+- 缺少 `pnpm-workspace.yaml`
+- Node 版本不满足要求
+- 根 `package.json` 没装 `repoctl` / `@icebreakers/monorepo`
+- 根快捷脚本没同步齐
+- `repoctl.config.ts` 与 `monorepo.config.ts` 同时存在
+- `.husky/pre-commit` 和 `lint-staged.config.js` 只配了一半
+
+## 常见问题
+
+### 1. 提示当前目录不像 monorepo 根目录
+
+通常是因为你在子包目录里执行了命令，或者根目录缺少这些文件：
+
+```txt
+package.json
+pnpm-workspace.yaml
+```
+
+先回到根目录再执行。
+
+如果要确认 CLI 实际识别到了哪些 workspace 包，可以输出一份列表：
+
+```bash
+pnpm exec repo ws ls --json --out reports/workspaces.json
+pnpm exec repo ws ls --markdown --redact --out reports/workspaces.md
+```
+
+### 2. Node 版本不满足要求
+
+看根 `package.json`：
+
+```json
+{
+  "engines": {
+    "node": ">=20.0.0"
+  }
+}
+```
+
+切到满足要求的 Node 版本后，再跑：
+
+```bash
+pnpm install
+pnpm doctor
+```
+
+### 3. `repoctl.config.ts` 和 `monorepo.config.ts` 同时存在
+
+这是明确的冲突状态，不是“都能读”。
+
+处理方式：
+
+- 保留 `repoctl.config.ts`
+- 删除 `monorepo.config.ts`
+
+除非你在迁移历史仓库，否则没有必要双持。
+
+### 4. 根脚本没有 `setup` / `new` / `check` / `doctor`
+
+先同步一次标准资产：
+
+```bash
+pnpm exec repo upgrade
+```
+
+### 5. `repo new --template` 提示未知模板
+
+先运行：
+
+```bash
+pnpm exec repo templates
+```
+
+确认模板 key。`--template` 是严格校验的，拼写错误会直接失败；如果能判断出相近 key，CLI 会额外提示 `did you mean ...`。
+
+如果你只是不想等，也可以手动把这些脚本加回根 `package.json`。
+
+### 5. 提交前校验没有正常工作
+
+先检查这两个文件是不是同时存在：
+
+```txt
+.husky/pre-commit
+lint-staged.config.js
+```
+
+只存在一个，通常就是半残状态。
+
+可选动作：
+
+```bash
+pnpm exec repo upgrade
+pnpm check
+```
+
+### 6. `repo` 命令不可用
+
+通常是依赖还没安装，或者当前仓库没把 CLI 包放进根依赖。
+
+先执行：
+
+```bash
+pnpm install
+pnpm doctor
+```
+
+如果根本没有安装 CLI 依赖，补一个即可：
+
+```bash
+pnpm add -D repoctl
+```
+
+## `doctor` 和 `check` 的区别
+
+很多人遇到问题会这两个命令来回试，其实职责不同：
+
+| 命令     | 更像什么   |
+| -------- | ---------- |
+| `doctor` | 仓库体检   |
+| `check`  | 提交前校验 |
+
+如果你怀疑是“仓库架子不完整”，先用 `doctor`。
+如果你怀疑是“这次改动过不了 lint / typecheck / test”，先用 `check`。
+
+## 什么时候需要 `upgrade`
+
+下面这些情况，优先考虑 `repo upgrade`：
+
+- 文档里的根脚本在你仓库里没有
+- 默认的 Husky / lint-staged / config 资产缺失
+- 模板最近更新过，而你的仓库还是旧结构
+- 你希望重新同步推荐默认值
+
+## 一个实用排查顺序
+
+大多数问题按这个顺序处理最省时间：
+
+```bash
+pnpm install
+pnpm doctor
+pnpm exec repo upgrade
+pnpm doctor
+pnpm check
+pnpm build
+```
+
+思路是：
+
+1. 先把依赖装齐
+2. 先修仓库架子问题
+3. 再看当前改动的校验问题
+
+## 还有问题时看哪里
+
+- 日常命令边界不清楚：[命令速查](./commands.md)
+- 不确定仓库怎么管理：[如何管理 monorepo](./manage.md)
+- 发包问题：[发包与变更日志](./publish.md)

package/templates/vitepress/package.json

@@ -23,17 +23,17 @@
     "typecheck": "tsc -p tsconfig.json"
   },
   "dependencies": {
-    "vue": "^3.5.30"
+    "vue": "^3.5.33"
   },
   "devDependencies": {
     "@braintree/sanitize-url": "^7.1.2",
-    "@tailwindcss/vite": "^4.2.1",
-    "cytoscape": "^3.33.1",
+    "@tailwindcss/vite": "^4.2.4",
+    "cytoscape": "^3.33.3",
     "cytoscape-cose-bilkent": "^4.1.0",
     "dayjs": "^1.11.20",
     "debug": "^4.4.3",
-    "mermaid": "^11.13.0",
-    "tailwindcss": "^4.2.1",
+    "mermaid": "^11.14.0",
+    "tailwindcss": "^4.2.4",
     "vitepress": "^1.6.4",
     "vitepress-plugin-mermaid": "^2.0.17"
   }

package/templates/vitepress/thinking.md

@@ -31,7 +31,7 @@
 
 ### 语言与打包
 
-我选择使用纯 `TypeScript` 来编写所有类库项目，并使用 `tsup` / `unbuild` 进行打包，默认输出格式为 `cjs` 和 `esm`，并利用 `package.json` 中的 `exports` 字段进行分发。
+我选择使用纯 `TypeScript` 来编写所有类库项目，并统一使用 `tsdown` 进行打包，默认输出格式为 `cjs` 和 `esm`，并利用 `package.json` 中的 `exports` 字段进行分发。
 
 ### 直接调试
 

package/templates/vitepress/tools/husky.md

@@ -15,8 +15,8 @@
    在提交前运行 `prettier --write .`，确保代码风格一致。
 2. **Lint 检查**
    在 `pre-commit` 时执行 `eslint`，防止有 lint 错误的代码被提交。
-3. **运行测试**
-   在 `pre-push` 时执行 `npm test`，防止未通过测试的代码被推送。
+3. **推送前执行整仓校验**
+   在 `pre-push` 时执行整仓 `lint`、`typecheck`，并按需补跑 `build`、`test`、`tsd`，防止未通过校验的代码被推送。
 4. **Commit 信息校验**
    在 `commit-msg` hook 中使用 [commitlint](https://github.com/conventional-changelog/commitlint) 强制提交信息符合规范（如 Conventional Commits）。
 
@@ -101,6 +101,11 @@ npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"
 npx lint-staged
 ```
 
+在本仓库默认实现里，`pre-commit` 和 `pre-push` 的职责拆分是：
+
+- `pre-commit`：只针对 staged 文件执行 `eslint`、`stylelint` 和 workspace `typecheck`
+- `pre-push`：强制执行整仓 `pnpm lint`、`pnpm typecheck`，并根据改动范围补跑 `build`、`test`、`tsd`
+
 ## 总结
 
 - **Husky** 是一个 Git hooks 工具，用来在 commit、push 等阶段运行脚本。

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

@@ -9,6 +9,7 @@
 
 - Husky 负责触发 Git hooks（比如 `pre-commit`）。
 - lint-staged 负责只对 **本次提交涉及的文件** 进行检查和修复。
+- 在本仓库默认配置里，`ts` / `tsx` / `mts` / `cts` / `vue` 文件还会继续触发对应 workspace 的 `typecheck`。
 
 这样就避免了对整个项目运行 lint/format，节省时间。
 
@@ -19,7 +20,7 @@
 - **常见场景**：
   - 运行 ESLint 自动修复：`eslint --fix`
   - 运行 Prettier 格式化：`prettier --write`
-  - 运行 TypeScript 编译检查：`tsc --noEmit`
+  - 运行 workspace 级类型检查：Vue 项目通常是 `vue-tsc -b`，TS 项目通常是 `tsc -p tsconfig.json`
   - 优化图片、转换 Markdown 等自定义脚本
 
 ## 3. 如何使用 lint-staged？
@@ -56,6 +57,18 @@ npx lint-staged
 
 这样在提交时，lint-staged 会自动处理已暂存的文件。
 
+本仓库默认生成的规则更接近下面这种形式：
+
+```js
+export default {
+  '*.{js,jsx,mjs,ts,tsx,mts,cts}': ['eslint --fix'],
+  '*.vue': ['eslint --fix', 'stylelint --fix --allow-empty-input'],
+  '*.{ts,tsx,mts,cts,vue}': files => `pnpm exec repoctl verify staged-typecheck ${files.join(' ')}`,
+  '*.{json,md,mdx,html,yml,yaml}': ['eslint --fix'],
+  '*.{css,scss,sass,less}': ['stylelint --fix --allow-empty-input'],
+}
+```
+
 ## 4. 示例工作流
 
 假设你改了两个文件：
@@ -77,3 +90,4 @@ npx lint-staged
 - **lint-staged = 只在 staged 文件上运行 lint/脚本的工具**。
 - 优点：快、精准，避免全量检查。
 - 常和 **Husky** 搭配，用于 `pre-commit`。
+- 在 monorepo 里很适合把 ESLint、Stylelint 和 workspace `typecheck` 串起来。

package/templates/vitepress/why/examples/usage-cjs/index.js

@@ -1,12 +1,8 @@
 /* eslint-disable no-console */
-// import c from 'chalk'
-// const c = require('chalk')
 const { sayHello } = require('icebreaker-npm-basic-package')
 const { sayHello: sayHelloCjs } = require('icebreaker-npm-basic-package-multiple-exports')
+const pc = require('picocolors')
 
 sayHello()
 sayHelloCjs()
-
-import('chalk').then(({ default: c }) => {
-  console.log(c.green('Hello World!'))
-})
+console.log(pc.green('Hello World!'))

package/templates/vitepress/why/examples/usage-cjs/package-lock.json

@@ -9,22 +9,16 @@
       "version": "1.0.0",
       "license": "ISC",
       "dependencies": {
-        "chalk": "^5.6.2",
         "icebreaker-npm-basic-package": "^1.0.5",
-        "icebreaker-npm-basic-package-multiple-exports": "^0.0.0"
+        "icebreaker-npm-basic-package-multiple-exports": "^0.0.0",
+        "picocolors": "^1.1.1"
       }
     },
-    "node_modules/chalk": {
-      "version": "5.6.2",
-      "resolved": "https://registry.npmjs.org/chalk/-/chalk-5.6.2.tgz",
-      "integrity": "sha512-7NzBL0rN6fMUW+f7A6Io4h40qQlG+xGmtMxfbnH/K7TAtt8JQWVQK+6g0UXKMeVJoyV5EkkNsErQ8pVD3bLHbA==",
-      "license": "MIT",
-      "engines": {
-        "node": "^12.17.0 || ^14.13 || >=16.0.0"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/chalk?sponsor=1"
-      }
+    "node_modules/picocolors": {
+      "version": "1.1.1",
+      "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.1.1.tgz",
+      "integrity": "sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==",
+      "license": "ISC"
     },
     "node_modules/icebreaker-npm-basic-package": {
       "version": "1.0.5",

package/templates/vitepress/why/examples/usage-cjs/package.json

@@ -13,8 +13,8 @@
     "cjs": "node cjs.cjs"
   },
   "dependencies": {
-    "chalk": "^5.6.2",
     "icebreaker-npm-basic-package": "^1.0.5",
-    "icebreaker-npm-basic-package-multiple-exports": "^0.0.0"
+    "icebreaker-npm-basic-package-multiple-exports": "^0.0.0",
+    "picocolors": "^1.1.1"
   }
 }

package/templates/vitepress/why/examples/usage-esm/index.js

@@ -1,8 +1,8 @@
 /* eslint-disable no-console */
-import c from 'chalk'
 import { sayHello } from 'icebreaker-npm-basic-package'
 import { sayHello as sayHello2 } from 'icebreaker-npm-basic-package-multiple-exports'
+import pc from 'picocolors'
 
 sayHello()
 sayHello2()
-console.log(c.green('Hello World!'))
+console.log(pc.green('Hello World!'))