发现于 #5382(doctor 的 posture 报告,PR 见下)实施过程中的顺带核验;本单只记录,不在该 PR 里改(那单的文件面被限定为 packages/cli/src/commands/doctor.ts 的 posture 读取,而本单的修法会改变 doctor 每一项 env 派生检查所看到的输入,属于另一个决定)。
事实
serve / dev / start 三条命令都在 run() 早期用 dotenv-flow 载入 .env*:
packages/cli/src/commands/serve.ts:516 — dotenvFlow.config({ node_env: mode, silent: true })packages/cli/src/commands/dev.ts:132 — dotenvFlow.config({ node_env: 'development', silent: true })packages/cli/src/commands/start.ts:121 — dotenvFlow.config({ node_env: mode, silent: true })
doctor.ts 没有任何 dotenv 载入(grep -n dotenv packages/cli/src/commands/doctor.ts 无匹配),只看 process.env。
后果
诊断面读到的环境,和被诊断的那条命令实际运行时的环境,不是同一份。具体到 #5382 修完之后的那项检查:
# .env(提交进仓库,团队共享)
OS_TENANCY_POSTURE=isolatd
$ os doctor # 看不到 .env,posture 解析成 single,报绿,exit 0
$ os serve # 载入 .env,读到 isolatd,FATAL 拒绝启动(PR #5381 的闸门)
也就是说 #5382 修好的那条「doctor 与 serve 不一致」,在 .env 这条来源上仍然成立 —— 只是从「归因错误」缩小成了「完全看不见」。PR 里的文案已经如实写明这一点(「os doctor does not load .env* files, so a value set in one is not visible here」),不冒充检查过,但残留本身值得单独记一笔。
.env 恰恰是这个变量最常见的来源:PR #5381 把 serve 的闸门刻意放在 dotenv 载入之后,理由正是「该变量常常来自提交进仓库的 .env* 而不是 shell」。
为什么现在才成为问题
在 #5382 之前,doctor.ts 里 process.env 的直接读取是 0 处 —— 它此前根本没有 env 派生的检查,所以「不加载 .env」不产生可观察差异。#5382 给它加了第一项(posture),这条不一致才有了落点。任何后续想在 doctor 里检查 OS_* 配置的工作都会撞上同一堵墙。
需要决定的地方(所以没有顺手改)
在 doctor 里加一行 dotenvFlow.config() 表面上是一行,但它:
- 改变 doctor 每一项(现在的和将来的)env 派生检查的输入;
- 需要选一个
node_env —— serve 从 --dev / NODE_ENV 推导,start 用 mode,doctor 没有对应的旗标,选错会读到另一套 .env.<mode>;
- 会把
.env 里的值写进当前进程的 process.env,doctor 之后若还要报告「你的 shell 里设了什么」就分不清来源了 —— 可能需要把「从哪读到的」也报出来,而不是静默合并。
倾向:doctor 应当模拟 serve 的读取顺序并在报告里注明每个值的来源(shell / 哪个 .env 文件),而不是静默 merge —— 但这是诊断输出的契约变化,交维护者裁定。
现状证据
packages/cli 下没有任何测试钉 doctor 与 .env 的关系。
Context: #5382 / #5359 / PR #5381。与 #4801、cloud#1020 同属「诊断面与运行时不一致」家族。
发现于 #5382(doctor 的 posture 报告,PR 见下)实施过程中的顺带核验;本单只记录,不在该 PR 里改(那单的文件面被限定为
packages/cli/src/commands/doctor.ts的 posture 读取,而本单的修法会改变 doctor 每一项 env 派生检查所看到的输入,属于另一个决定)。事实
serve/dev/start三条命令都在run()早期用 dotenv-flow 载入.env*:packages/cli/src/commands/serve.ts:516—dotenvFlow.config({ node_env: mode, silent: true })packages/cli/src/commands/dev.ts:132—dotenvFlow.config({ node_env: 'development', silent: true })packages/cli/src/commands/start.ts:121—dotenvFlow.config({ node_env: mode, silent: true })doctor.ts没有任何 dotenv 载入(grep -n dotenv packages/cli/src/commands/doctor.ts无匹配),只看process.env。后果
诊断面读到的环境,和被诊断的那条命令实际运行时的环境,不是同一份。具体到 #5382 修完之后的那项检查:
也就是说 #5382 修好的那条「doctor 与 serve 不一致」,在
.env这条来源上仍然成立 —— 只是从「归因错误」缩小成了「完全看不见」。PR 里的文案已经如实写明这一点(「os doctordoes not load.env*files, so a value set in one is not visible here」),不冒充检查过,但残留本身值得单独记一笔。.env恰恰是这个变量最常见的来源:PR #5381 把 serve 的闸门刻意放在 dotenv 载入之后,理由正是「该变量常常来自提交进仓库的.env*而不是 shell」。为什么现在才成为问题
在 #5382 之前,
doctor.ts里process.env的直接读取是 0 处 —— 它此前根本没有 env 派生的检查,所以「不加载 .env」不产生可观察差异。#5382 给它加了第一项(posture),这条不一致才有了落点。任何后续想在 doctor 里检查OS_*配置的工作都会撞上同一堵墙。需要决定的地方(所以没有顺手改)
在 doctor 里加一行
dotenvFlow.config()表面上是一行,但它:node_env—— serve 从--dev/NODE_ENV推导,start用 mode,doctor 没有对应的旗标,选错会读到另一套.env.<mode>;.env里的值写进当前进程的process.env,doctor 之后若还要报告「你的 shell 里设了什么」就分不清来源了 —— 可能需要把「从哪读到的」也报出来,而不是静默合并。倾向:doctor 应当模拟 serve 的读取顺序并在报告里注明每个值的来源(shell / 哪个
.env文件),而不是静默 merge —— 但这是诊断输出的契约变化,交维护者裁定。现状证据
packages/cli下没有任何测试钉 doctor 与.env的关系。Context: #5382 / #5359 / PR #5381。与 #4801、cloud#1020 同属「诊断面与运行时不一致」家族。