[Bug] dsh 在 Node 24 上静默退出(import.meta.main 已被移除)

[suonian]

环境

• @deepseek-ai/dsh@0.1.5-rc.1
• Node v24.0.0(macOS arm64)
• package.json 没有 engines 字段

现象

dsh web、dsh --profile web、dsh --version 全部静默退出(exit 0、零 stdout、零 stderr)。
3080 端口从未 listen,~/.dsh 也不会创建,看起来"什么也没发生"。

根因

lib/bin.js 末行用 if (import.meta.main) await runCli(); 判定是否入口。
import.meta.main 在 Node 24 上是 undefined(该 API 在 22.x 一直 experimental,24 已移除),
条件恒为 falsy,runCli() 永不执行。

实测:在 lib/bin.js 顶部加 console.error("main=" + import.meta.main),然后以该文件为入口:

Node	import.meta.main
v24.0.0	undefined ✗
v25.9.0	true ✓

(本机 Node 22 因 libsimdjson.30.dylib 缺失跑不起来,未直接验证 v22;但官方 v22 文档里有该 API。)

临时修法:把 bin.js 顶部 shebang 改成绝对路径指向能用的 Node(Node 25)。改完后
dsh --version 正常输出 0.1.5-rc.1,dsh web 起来,3080 监听正常。

复现

npm i -g @deepseek-ai/dsh
node --version                    # v24.x
dsh web --no-open
echo "exit=$?"                    # 0
lsof -nP -iTCP:3080              # 空
ls ~/.dsh 2>/dev/null             # 不存在

期望

非 0 退出码 + 一行明确错误,例如:

Error: dsh requires Node 22 or earlier (or any version where import.meta.main exists);
detected Node v24.0.0.

哪怕只是一行 Error: failed to start; open an issue at ... 也比现在的静默退出强。

建议

1. package.json 加 engines("node": ">=20 <24" 或迁到可移植判断)
2. if (import.meta.main) 失败时给用户明确诊断(至少 console.error 一下)
3. CI 在 Node 24 上跑一次,避免静默回归

可移植替代(供参考)

import { pathToFileURL } from "node:url";
const isMain = import.meta.url === pathToFileURL(process.argv[1]).href;
if (isMain) await runCli();

[moonquake2004]

这条与我们此前记录的 #6341 是同一根因，你的实测正好补上了那个窗口的中间一段——也说明报错里"Node 24"这个标签容易读得过宽。

API 的可用窗口是 ≥22.18.0 与 ≥24.2.0（这是 #6341 当时的结论）。对照你的测量：

Node	import.meta.main	结果
v22.0–22.17 / v20 / v23	undefined	全部命令静默、退出码 0
v24.0.0–24.1.x	undefined	← 你这一条，落在两个下界之间的缺口里
v22.18+ / v24.2+ / v25	true	正常

我在本机 Node 24.20.0 上复核过：import.meta.main = true，dsh --version → 0.1.5-rc.1。所以准确说法不是"Node 24 上静默退出"，而是"24.0/24.1 两个版本上静默退出"——24.2 以后是好的。这很重要，否则读者会把整个 24 线排除掉。

顺着这一点，有一个比你我表述都更尖锐的问题：声明范围自己包含了不可用的版本。 仓库根 package.json（@deepseek-ai/dsh-root，private）写的是：

"engines": { "node": "^22.19.0 || >=24.0.0" }

>=24.0.0 包含 24.0.0 与 24.1.x —— 正是 CLI 连 --version 都不执行的两个版本。也就是说"官方声明的支持范围"与"这份代码实际能跑的范围"不一致；按 API 窗口写应当是 ^22.19.0 || >=24.2.0。（另外这个范围只写在私有 workspace 上，没有任何发布物继承它，所以 npm 既不校验也不警告——见 #6651。）

工具侧我已经把这条签名做成了检查（dsh-doctor@0.4.30 的 E13）：dsh 在 PATH 中就真跑一次 --version；退出码 0 且输出为空即判失败，并点明 import.meta.main 门控、API 窗口与"声明范围包含不可用版本"这一点。你贴的判据（连 --version 都静默）正是关键——缺原生模块、端口占用、patch 问题都会打印东西，只有入口没执行才会连版本号都没有。这样下一个人遇到"装完什么都没发生"时不必再从头查一遍。

关于临时修法：改 shebang 指向 Node 25 是有效的，但它是逐次安装的——npm i -g 更新会覆盖 lib/bin.js，修法就没了。用版本管理器（fnm/nvm/volta）把该目录切到 ≥22.18 或 ≥24.2 更耐久，也让 engines 那条（如果将来真加上）能生效。