本文档将介绍项目技术信息和开发中的一些约定和规范。
前端使用 Nuxt 开发，使用 tauri 打包为独立应用程序。
工具链版本要求见 package.json。
ex-caller
├── .nuxt // 开发模式 Nuxt 自动生成的文件
├── .output // Nuxt 构建产物
├── app // Nuxt 前端根目录
├── dist -> .output/public // Nuxt 构建产物
├── public // 复制到 dist 的文件
├── src-tauri // tauri 相关文件
└── static // 其他用途的静态文件，不包含在 app 中
开始开发之前，需要运行 pnpm install 安装依赖。
- 启动 tauri 和 Nuxt 的开发服务器：
pnpm dev - 仅启动 Nuxt 开发服务器：
pnpm dev:web - 检查代码格式：
pnpm lint - 构建：
pnpm build - 运行类型测试：
pnpm test:types - 运行单元测试：
pnpm test:unit
遵循 ESLint 配置 即可。
如果你使用 VS Code，建议安装 .vscode/extensions.json 中的推荐插件，并在 .vscode/settings.json 中写入 antfu 的推荐设置。
自由心证。
使用 Git 管理版本。
一个 commit 做一件事，非 CI 的提交必须添加 GPG 签名，无需添加 Signoff。Commit message 遵循约定式提交 1.0.0。
每个 tag 代表一个版本，以 v 开头，加上版本号，无需 GPG 签名。
有 2~3 个常驻分支，除此之外都是用于 PR 的临时分支：
main(default)：最新的代码，可以推送，可以 commitlatest：最新的已发布稳定版的代码，禁止除 CI 以外的推送- 如果有活跃的先行版的，代码放在
insider分支，禁止除 CI 以外的推送。
常驻分支必须拥有线性历史记录。
版本号格式遵循 SemVer 2.0.0，但是 semver 针对的是 dependencies，所以大部分情况仍然自由心证。
在一个版本发布前，可以在 Canary 环境查看 main 分支上的代码效果。
发版的一般流程如下：
- 更新
CHANGELOG.md - 更新版本号
package.json>versionsrc-tauri/tauri.conf.json>versionsrc-tauri/Cargo.toml>package>versionsrc-tauri/Cargo.lock> 依赖项ex-caller>package>version
- commit，格式如：
release: v1.0.0 - tag，格式如：
v1.0.0 - push 到 GitHub
- 在 GitHub 创建 release，标题如
ExCaller v1.0.0，内容为 (1) 中增加的部分 - 发布 release 后，构建流程自动启动，等待完成后查看 release assets
如果版本构建失败，则可以继续 commit 以修复问题，并把 tag 更新到最终成功发版的 commit。