Skip to content

check-i18n-coverage:example 自身依赖未构建时仍抛裸异常 + node 栈(诊断准确,但不是结论) #6033

Description

@hotlong

观察类发现(finding,不入 pm:queue)。实现 #5862(PR #6032)时按 Prime Directive #10 只记录、不顺手修 —— 它与 #5862 的成因不同,落点也不在该 PR 的申报文件面之外那半步。

现象

#5862 修的是「CLI 未构建」这一个前置。清掉它之后(pnpm exec turbo run build --filter=@objectstack/cli),在一棵其余部分仍未构建的树上跑 node scripts/check-i18n-coverage.mjs,第二堵墙立刻出现:

file:///…/scripts/check-i18n-coverage.mjs:185
    if (report.error) throw new Error(`os lint failed for ${configPath}: ${report.error}`);
                            ^

Error: os lint failed for examples/app-showcase/objectstack.config.ts:
  Cannot find module '/…/examples/app-showcase/node_modules/@objectstack/connector-mcp/dist/index.mjs'
    at countI18nIssues (…/check-i18n-coverage.mjs:185:29)
Node.js v22.22.2

退出码 1。本轮实测,在 f192981 的 worktree 上复现。

#5862 的区别:这次诊断没有说谎

这是为什么它是观察类而不是缺陷。#5862 的那句话把成因指向一个完全无辜的示例配置;这一句点的是真的缺失模块路径 —— 读者拿到的是可行动的一手读数。坏的只是形状:一段 node 栈,而不是一条「前置未满足 + 修法」的结论,并且同样是「第一个撞上的 config 顶罪」式呈现(app-showcase 只是恰好排在前面;每个 example 都会以各自的缺失模块再来一次,如果循环没在第一个就崩)。

家族里已有的几条:#5217(check-i18n-bundles,已落地)、#5862(本条的直接前身,PR #6032 在飞)、#5795(根 dev 入口)、#5794(datasource fail-fast 不认识该成因)。

为什么不在 PR #6032 里顺手修

建议方向(实现者自选)

若要修,最省的形状可能不是再加一个前置探测,而是把 report.error 这条路径从 throw 改成收集式:整轮跑完后一次性报告「哪些 config 没能 lint 成功 + 各自的原因 + 一句 pnpm build」,而不是让第一个失败的 config 中止全程 —— 与 #5217 「一个原因不要报成 N 个结果」的取向一致,方向相反(这里是 N 个不同原因不应被第一个吃掉)。

影响面

纯内部工具链 DX。CI 永远命中不到(lint.ymlBuild workspace packages 在这一步之前),今天没有人因此拿到错误结果;坏的是本地/worktree 复现 i18n CI 时的呈现形状。故按观察类归档,交由 PM 定级。

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions