使用 vite 的 base 命令行参数来解决项目部署在 github page 的路径问题
github page 要求 vite 项目必须配置 base 参数
如果我们想把 vite 或 vitepress 项目部署到 github page ，那么根据 vite 和 vitepress 的文档要求，我们必须在 vite 的 base 配置内配置好仓库路径。
比如我的 github 仓库是 stars-list ，那么我的 base 配置就必须写成 stars-list 。这是写死的。
build 构建流程和 deploy 部署流程应该是解耦的
这看起来没什么问题，确实项目的泛用性降低了。如果我在 base 配置内写死了部署地址，那么项目要部署到其他平台的时候，该怎么办呢？总不可能提供好几个 vite 配置文件吧？
build 打包项目，就是很单纯的打包。不应该去考虑自己被部署到哪里的。现在 github page 这个部署平台，竟然反过来要求构建的时候要做出让步，要多配置东西来兼容他。这就导致 deploy 流程反过来耦合了 build 流程。
我不希望在 vite 配置内写死 base 参数，这降低了可部署平台的泛用性。
尝试解决问题
在 vite 配置文件内，很不好去做动态判断。
不能去判断部署目标是谁
为了解决这个问题，我们很容易的会想到用某种方式实现动态判断，通过判断部署目标是不是 github page，从而决定自己的 base 配置。
这个方案行不行呢？答案是不行。这个思路是离谱的，因为没有手段去向构建行为传递参数，并告诉 build 命令现在部署目标是 github page。
不能去判断工作流种类
那可不可以通过判断当前的工作流是谁，从而决定 base 配置呢？
这个方案行不行呢？答案是不行。
我们可能会这样思考问题：
- 当前
build运行环境是不是cloudflare worker？ 是，那base配置留空。 - 当前
build运行环境是不是vercel？ 是，那base配置留空。 - 当前
build运行环境是不是github workflow？ 是，那base配置就特殊化处理。
这样看起来实现了对部署平台的通用性，但是 github workflow 泛用性更强，难道 github workflow 就一定会绑定 github page 么？
比如以下这几种场景：
- 用
github workflow运行build命令，并借助 wrangler 包的 cli 参数，直接上传工件到cloudflare，实现cloudflare平台的部署。 - 用
github workflow运行build命令，并借助 vercel 包的 cli 参数，并直接上传工件到vercel，实现vercel平台的部署。 - 用
github workflow运行build命令，并借助actions/configure-pages、actions/upload-pages-artifact和actions/deploy-pages这三个工作流，实现github page平台的部署。
考虑到 github workflow 的泛用性，那我们就不能通过判断 github workflow 进而来判断部署平台到底是谁了。
综上所述，在 vite 配置文件内，不好去做这样的判断。
关键是，我们要有某种手段，可以向构建行为本身，提供参数，并更改构建行为。
用 base 命令行参数，配置单独的 build 命令专供于 github page 部署场景
按照这样的思考，我们很容易的就可以想到，在使用 vite 或 vitepress 构建项目时，能不能传递 base 参数呢？这样就可以在 vite 配置文件内不考虑 base 配置了，增强了灵活性。
幸运的是，vite 和 vitepress 的 build 命令，均提供 base 参数，允许我们在构建前，看情况提供参数，进而满足 github page 的部署要求。
那么我们就可以这样写打包命令了：
{
"scripts": {
"docs:build": "vitepress build docs",
"docs:build-in-github-page": "vitepress build docs --base=/stars-list/",
"build": "pnpm docs:build-in-github-page"
}
}在明确部署平台是 github page 时，就用专门专供的命令来打包。就用 docs:build-in-github-page 命令。否则部署到其他平台时，就用单纯的 docs:build 命令即可。
至此就解决了 base 参数在 build 和 deploy 流程的耦合问题。
参考资料
贡献者
ruan-cat