npx 启动不成功程序直接退出 @deepseek-ai/dsh (published package) silently exits with code 0 on Node < 24.2.0 — the consumer-side counterpart of #5082

[ambiguous-pointer]

@deepseek-ai/dsh (published package) silently exits with code 0 on Node < 24.2.0 — the consumer-side counterpart of #5082

关联与区别（重要，请勿当作 #5082 的重复）

本问题与 #5082 是同一个根因（import.meta.main 在 Node < 24.2.0 上为 undefined），
但发生在完全不同的表面上，且 #5082 建议的修复无法覆盖本问题：

	#5082	本 issue
触发面	源码仓库的构建脚本（scripts/*.ts，经 tsx 执行）	已发布包 @deepseek-ai/dsh 的 lib/bin.js
受影响者	自行 git clone + pnpm run build 的开发者	任何 npx / npm i 的终端用户（无需构建）
症状	打印 $ tsx scripts/build.ts 后 exit 0，无产物 → 服务能起但 / 返回 404	完全零输出、exit 0、连服务都不会启动
engines 现状	根 package.json 有声明，但范围写错（含 24.0.x/24.1.0）	apps/cli/package.json 完全没有 engines 字段
报告版本	0.1.2-alpha.1（2026-08-30）	0.1.5-rc.1（2026-09-10，仍复现）

关键点：#5082 建议「把根 package.json 的 engines 收紧为 ^22.19.0 || >=24.2.0」——
该修复只作用于源码仓库，而用户实际安装的发布包 @deepseek-ai/dsh 根本没有 engines 字段，
npm 因此不会给出任何警告，失败也完全静默。两者需要分别修复。

已核对（master 分支，版本均为 0.1.5-rc.1）：

@deepseek-ai/dsh-root   engines: { node: "^22.19.0 || >=24.0.0" }   ← 有，但范围含 24.0.x/24.1.0
@deepseek-ai/dsh        engines: (无)                                ← 发布包完全没有

---

环境

项	值
dsh 版本	0.1.5-rc.1（0.1.3-alpha.2、0.1.5-alpha.1、0.1.5-alpha.2 同样受影响）
Node	v24.0.0
npm	11.3.0
OS	Ubuntu (Linux 5.15.0) x86_64

问题描述

在 Node 版本低于 24.2.0 的环境中，通过 npm 安装的 dsh 执行任何命令都
没有任何输出、没有报错、以退出码 0 正常退出，无法从任何信号判断问题所在。

复现步骤

node -v                             # v24.0.0
npx -y @deepseek-ai/dsh --version   # 无输出
npx -y @deepseek-ai/dsh web         # 无输出（连服务都不会启动）
echo $?                             # 0

实际行为

• stdout：0 字节
• stderr：0 字节
• 退出码：0
• 立即返回（0 秒）

在伪终端下（script -qec "dsh --help" /dev/null）表现完全一致，排除 TTY 依赖。

注意：连 commander 的 --help 都不输出，说明代码根本没有执行到参数解析阶段。

预期行为

应当正常启动；若 Node 版本不满足要求，应以非零退出码退出并打印可读的版本错误信息。

根因

源码位置：apps/cli/src/bin.ts 末尾

if (import.meta.main) {
  await runCli()
}

发布产物：node_modules/@deepseek-ai/dsh/lib/bin.js 末尾（编译后）

if (import.meta.main) await runCli();
//#endregion
export { runCli };

import.meta.main 自 Node.js v24.2.0 起可用（v22 线另有回填版本，与 #5082 所述一致）。
在 Node v24.0.0 上该属性求值为 undefined，导致 if 恒假 → runCli() 从未被调用
→ 进程什么都不做，直接以 0 退出。

独立验证

$ node --input-type=module -e "console.log(import.meta.main)"
undefined

与 dsh 无关的最小复现：

$ printf 'if (import.meta.main) console.log("RAN");\n' > t.mjs
$ node t.mjs
（无任何输出）
$ echo $?
0

绕过该守卫、显式调用入口函数后，dsh 功能完全正常（证明包本身无问题）：

$ node -e "const m = await import('.../@deepseek-ai/dsh/lib/bin.js'); await m.runCli();"
0.1.5-rc.1

$ # 同上方式运行 web
dsh web: http://127.0.0.1:36955/?token=...

升级到 Node v24.21.0 后，原命令无需任何改动即恢复正常：

$ npx -y @deepseek-ai/dsh web --no-open --port 0
dsh web: http://127.0.0.1:36849/?token=...

影响

这个故障模式极具误导性：用户会优先怀疑 npm 源、镜像、代理或网络问题，
因为没有任何信号指向 Node 版本。

在本次排查中已实测排除（均为正常）：

• 官方源：npm view @deepseek-ai/dsh 正常返回 0.1.5-rc.1，-ddd 日志显示 npm http fetch GET 200
• npmmirror 镜像：现象完全一致
• 包已完整下载并落盘到 npx 缓存（_npx/*/node_modules/.bin/dsh 存在）

即：包下载正常、依赖安装正常，只是从未被执行。

且 #5082 报告于 2026-08-30，本问题在 2026-09-10 的 0.1.5-rc.1 上依然复现 ——
根因存续已逾 10 天，并已扩散到面向终端用户的发布产物。

建议修复

1. 给发布包补 engines 声明（最关键，覆盖本 issue）

apps/cli/package.json 目前没有 engines 字段：

"engines": { "node": ">=24.2.0" }

2. 同时修正根 package.json 的 engines（覆盖 #5082）

当前 ^22.19.0 || >=24.0.0 中的 >=24.0.0 包含了 24.0.x / 24.1.0，应收紧为
^22.19.0 || >=24.2.0（与 #5082 建议一致）。

3. 让失败可见（治本）

在 apps/cli/src/bin.ts 入口增加自检，避免静默退出：

if (typeof import.meta.main === 'undefined') {
  console.error(
    `dsh requires Node >= 24.2.0 (import.meta.main is unavailable).\n` +
    `Current: ${process.version}`
  )
  process.exit(1)
}

if (import.meta.main) {
  await runCli()
}

或按 #5082 的建议，改用不依赖 import.meta.main 的入口判断
（如 process.argv[1] 与 import.meta.url 对比），使声明范围内的 Node 行为一致。

4. 文档标注最低版本

在 README / 安装说明中明确写出 Node 最低版本要求。

附：临时绕过方式

无法升级 Node 时，可用包装器显式调用入口函数：

// dsh-run.mjs
const m = await import('file:///path/to/@deepseek-ai/dsh/lib/bin.js');
await m.runCli();

node dsh-run.mjs web

[CaffeineOddity]

锁定一下node版本吧，特么没事就给你们升级node

[alexzhu0]

I independently reproduced this with the published @deepseek-ai/dsh@0.1.5-rc.1 on macOS arm64, using real Node binaries and both --version and --help:

Node	Published package	Reference fix, packed and installed
22.19.0	Expected output, exit 0	Expected output, exit 0
24.0.0	Empty stdout/stderr, exit 0	Actionable stderr, exit 1
24.1.0	Empty stdout/stderr, exit 0	Actionable stderr, exit 1
24.2.0	Expected output, exit 0	Expected output, exit 0

One boundary clarification: import.meta.main also exists on Node 22 from 22.18, so the existing 22.19+ support can be preserved. The Node ESM reference documents both introduction versions.

I prepared a small fork-only reference implementation, based on upstream aa8262ec091698bae9a6b04773a6b5b06ad4aef2:

• Match the root and published CLI engine ranges at ^22.19.0 || >=24.2.0.
• Check the runtime before the import.meta.main guard and before importing the argument parser or application dependencies.
• Emit, for example, dsh: Node.js v24.0.0 is unsupported. Use Node.js 22.19+ (22.x) or 24.2+. with exit status 1.
• Pin the existing compatibility CI leg to 24.2 and align the bilingual documentation and owning Agent Note.

Verification: 13 owner-local expected tests, 14 adjacent tests, and 27 existing built-CLI acceptance tests passed, along with the full build, lint, documentation, and package-hygiene checks. The expected tests distinguish simulated version-policy cases from the actual runtime matrix above; they also check import-only behavior and rejection when no CLI dependencies are available. Linux/Windows CI has not been run for this reference branch.

Sharing this as supplemental evidence and a reference patch under the current CONTRIBUTING policy; no external PR opened.

[Oosl]

同样遇到该问题，升级node解决