fix(boot): CatalogModule 漏 import ScenesModule 导致产物起不来 + /health 版本号错
两个都是**只有真正启动服务才会暴露**的缺陷,v0.7.0 / v0.7.1 的产物受影响。 1. 【致命】CatalogModule 漏 import ScenesModule CatalogService 因为 catalog/export 要下发 scenes[] 而注入 ScenesService,但 CatalogModule 的 imports 只列了 SongsModule / MotionsModule / ModelsModule。 Nest 的 DI 按模块解析,于是 node dist/main.js 在 bootstrap 阶段直接抛 UnknownDependenciesException: Nest can't resolve dependencies of the CatalogService (... ? ...) —— 服务完全起不来(装得上、起不来)。 为什么三层检查全绿:nest build/tsc 看不出运行时 DI;258 项单元测试直接 new 服务或测纯函数,从不编译 AppModule;打包脚本只校验文件清单与压缩包完整性。 修复:CatalogModule.imports 补上 ScenesModule。 2. /health 的 version 在原生部署下永远是 0.1.0 原实现 process.env.npm_package_version ?? '0.1.0',而该变量只在 npm 脚本下 存在;正式部署是原生服务(ExecStart=node dist/main.js),npm 不参与 -> 恒为 undefined -> 回退到硬编码 0.1.0,与管理端左下角展示的 vX.Y.Z 冲突, 违反文档 11.2 第 4 条「可核对:Web 端至少与 GET /health 的 version 一致」。 修复:新增 src/config/app-version.ts 作为运行时唯一解析点 (APP_VERSION -> 运行入口旁/工作目录的 package.json(带包名校验) -> npm_package_version -> 显式 0.0.0),/health 改用 resolveAppVersion(), main.ts 启动首行也打印版本号。新增 12 项测试,其中一项显式模拟无 npm 环境变量的原生部署。 防线(都挂进了 verify 与打包脚本) - scripts/check-bootstrap.mjs:以正式部署方式(node dist/main.js、无 npm 环境 变量、不需要数据库)拉起真实产物,断言①无依赖解析类错误②启动日志的应用版本 等于 package.json ③已推进到数据库连接阶段。已做反向验证:删掉 ScenesModule 后该检查立刻失败。 - scripts/check-version.mjs(并入 contracts:check):校验 web-server/package.json = admin/package.json = project.yaml,正则禁止 health.controller.ts 再出现硬编码版本回退,管理端已构建时断言产物 JS 含 vX.Y.Z。 - npm run verify 现在包含 bootstrap:check;package-release.sh 在构建后、打包前 各跑一次(构建管理端后再跑 version:check,因为此时才需要校验产物内版本)。 文档:README.md / README.txt 增加 v0.7.2 修订说明; tasks/011-version-display.md 与 tasks/015-scene-management.md 补「缺陷修复记录」 (含为什么当时没被发现的三层检查对照表)。 验证:npm run verify 通过(契约六项一致、35 条路由、258 项测试、nest build、 启动冒烟);产物 opendance-web-v0.7.2.tar.gz sha256 f04ecc85d17517ec00754238616eb1237cdb2fe17440af6dce731827c0922b26。
This commit is contained in:
@@ -46,3 +46,30 @@
|
||||
| 非法参数不会入库 | ✅ 前后端同规则收敛;`test/scene-config.spec.ts` 9 项边界用例 |
|
||||
| 客户端能拿到场景 | ✅ `catalog/export.scenes[]`;目录指纹纳入场景变更 |
|
||||
| 路由与契约一致 | ✅ `check-routes` 共 **35** 条 |
|
||||
|
||||
## 缺陷修复记录(v0.7.2)
|
||||
|
||||
**缺陷**:`CatalogModule` 的 `imports` 里漏了 `ScenesModule`。
|
||||
|
||||
`CatalogService` 因为 `catalog/export` 要下发 `scenes[]` 而注入了 `ScenesService`,
|
||||
但 Nest 的 DI 是**按模块**解析的 —— 不在同一个模块的 `imports` 里,就解析不到。
|
||||
后果是 `node dist/main.js` 在 bootstrap 阶段直接抛
|
||||
`UnknownDependenciesException: Nest can't resolve dependencies of the CatalogService (... ? ...)`,
|
||||
**服务完全起不来**(v0.7.0 / v0.7.1 的产物都是这样)。
|
||||
|
||||
**为什么当时没被发现**:三层检查全都"绿"——
|
||||
|
||||
| 检查 | 为什么没抓到 |
|
||||
|--|--|
|
||||
| `nest build` / `tsc --noEmit` | 模块 import 缺失是**运行时** DI 问题,类型系统看不出来 |
|
||||
| 258 项单元测试 | 它们直接 new 服务或测纯函数,**从不编译 `AppModule`** |
|
||||
| 打包脚本的产物完整性校验 | 只校验文件清单、压缩包结构与 PE/魔数,不启动服务 |
|
||||
|
||||
**修复**:在 `CatalogModule.imports` 中补上 `ScenesModule`。
|
||||
|
||||
**防线**:新增 `scripts/check-bootstrap.mjs`,以正式部署方式
|
||||
(`ExecStart=node dist/main.js`、**不带任何 npm 环境变量**、**不需要数据库**)
|
||||
拉起真实产物,断言①无依赖解析类错误②启动日志里的应用版本等于 `package.json`
|
||||
③启动确实推进到数据库连接阶段。已挂进 `npm run verify` 与
|
||||
`scripts/package-release.sh`(构建后、打包前),并做过**反向验证**:
|
||||
把 `ScenesModule` 删除后该检查立刻失败。
|
||||
|
||||
Reference in New Issue
Block a user