dshseek
English

seek://news/dshmarket-1-73-17

dshmarket 1.73.17：三项修复与一项市场提速，全部出自首次贡献者（11 月 9 日）

2026年11月9日release#release #dsh-market #plugins← 全部资讯

TL;DR

据 npm registry（取于 2026-11-09），dshmarket 于 2026-11-09 17:08 UTC 发布 1.73.17。四项变更全部出自首次贡献者：位于 .asar 归档内的 CLI 入口继承启动器 cwd，启动重放不再停用 carrier 的 gate，市场不再在每次渲染时重扫整个目录，origin fence 像宿主 fence 那样信任监听的绑定主机。

连续第三个单版夜：据 npm registry（取于 2026-11-09），1.73.17 于 11 月 9 日 17:08:25 UTC 上架并接走 dist-tag latest——dshmarket 1.73.16：compatibility、verify 与 profile 的三项修复（11 月 8 日）覆盖了前一晚。GitHub 发布页时间戳 17:03:20 UTC，由仓库的 github-actions 机器人署名，并附有 v1.73.16…v1.73.17 的对比区间。

四项变更，四位首次贡献者

据发布说明，What’s Changed 恰列四项——三项 fix 与一项 perf；New Contributors 一节点名全部四位作者，各自完成首次贡献。前一晚则是三位作者中只有一位新面孔：据 1.73.16 的发布说明，那一节只点名了 @Eapp1e。

  • PR #1152（fix(dsh-cli)）——位于 .asar 归档内的 CLI 入口继承启动器 cwd，社区桌面壳上市场发起的写入由此恢复工作。据 issue #1146（hairyf 提交），桌面端 0.31.0 起每一次市场发起的安装、更新、卸载都失败，报错是一条指向实际存在之可执行文件的 spawn ENOENT；PR 正文举的例子是 hairyf/deepseek-harness-desktop 这样把 DSH CLI 打包进 asar 的桌面壳。机制在两份工件里各说一半：dshArgv() 只对官方 desktop carrier 免设工作目录，通用的 bin.js 条目便把 cwd 落在 asar 内部——那条路径 Electron 的 fs shim 能解析、Windows 的 CreateProcess 却拒绝切进去——失败最终落在 process.execPath 上，一个与真正问题无关的文件。据 PR 正文，子进程 8–19 ms 内死去（exit 127）、pnpm 从未启动，而手动 pnpm 完全正常；修复检测入口路径中的 .asar 段并给以 carrier 同等待遇——cwd: undefined，继承启动器的真实目录。正文的本机现场验证：连续九个包更新各自 exit 0 且 drain succeeded，随后 restart scheduled。

  • PR #1158（fix(routes)）——启动重放保住 carrier 的 gate。据其 PR 正文，关闭一个包会记录进 .dsh-market/state.json#disabled 并在启动时重放该列表；重放把与包名匹配的每一个 loader 条目都停用，连名字形如 <pkg>/<row>、服务被注入外部 preset 的独立 gate 条目也没能幸免。gate 一停，那些外部行就永远等不来一个已不存在的服务，官方 preset 全部停在 pending，启动以 Unknown agent preset: cordis / entries did not activate 失败。正文把这一缺口归为既有的同一类问题：实时的开关路由与 Recovery 早已经由 carrierRowIds（#224、#938）把整个 bundle 移出 dsh.profile.bundles，而启动重放路径与自愈守卫没有跟上。修复新增 carrier 安全的 replayDisabledPackage：当包是 carrier、声明了 bundle 且仍在 profile 栈中时，把整个 bundle 从下一轮组合移出而非停用其条目；普通包维持既有的尽力而为停用，自愈守卫则豁免 carrier，让重启完成切换。据正文，全量套件 3281 通过——仅有的 2 个失败是干净 main 上同样失败的 Windows symlink 权限用例——carrier 契约不变：和解仍等待一次重启。

  • PR #1160（perf(market)）——市场停止在每次渲染时重扫目录。据其 PR 正文，两趟全目录扫描跑在渲染路径上，合计构成 issue #1097 背后的主线程成本：installedBlocked 经由三个未做记忆化的更新提醒列表在每次渲染时重走全目录、无论开着哪个标签页；宿主过滤又坐在生成 pluginsAll 的同一查询里，hostCompatibility 每批到达都重建列表并重跑全目录扫描。前者改为按渲染输入做一次记忆化的批量处理；后者移到该趟之后运行，hostHiddenCount 在过滤前的候选池上含义不变。正文给出的实测——Windows x64、DSH Desktop（Electron 44.7.0 / Chrome 152）、dshmarket 1.73.16、9.7k 条目目录、28 个已安装包：滚动中的长任务（227 / 233 / 433 ms）之后读作无，sameSourceConflict 从滚动剖析的 62.9% 跌出前十二名，打开市场到首份列表从 1324 ms 变为 884 ms，开头 3.4 秒内的长任务从 3128 ms 降到约 2255 ms。正文对剩余部分写得明白：pluginsUnblocked 在输入变化时仍要重走全目录——该规模下约 700 ms——打开市场的长任务仍有约 2.2 s。无新增测试：据正文，这是纯函数的记忆化加两个纯过滤器的次序调整。

  • PR #1155（fix(http)）——origin fence 像宿主 fence 那样信任监听的绑定主机。据 issue #1154，以非回环绑定启动的宿主——报告中的复现是 dsh web --host 100.126.218.120 --no-open——浏览正常，但每一条变更类路由、从安装到卸载，都以 403 {"error":"untrusted origin"} 回应，直到进程结束，而同一页面的 GET 路由与 /api 传输都通行无阻。据 PR 正文，市场的变更类路由是 webServer 上的 exact 注册、从不经过宿主的 fence，sameOrigin 便是唯一守卫——而它只读 connection.trustedHosts，宿主有意不把绑定 IP 放进该列表，因为宿主 fence 以 carrier.host 的名义单独接收它。修复把绑定主机以无端口条目喂给 useTrustedHosts，归一化与宿主自己的 isBindAddressAuthority 一致——%zone 仍是接口选择符，裸 IPv6 字面量加上方括号。据正文，DNS rebinding 依旧被挡住：rebinding 页面的 Host 头写的是它自己的域名而非 IP，匹配不到任何条目；没有 webServer 的宿主（内嵌 Desktop）维持现状；作者还实测了从 dsh web --host 100.126.218.120 所提供服务页面发出的安装 POST 通过 fence。套件据正文：trusted-hosts 5/5、http 9/9、host-gate 6/6、flows+restart 473/473，全量 3272 通过。

说明在四项之外未列出任何内容——没有功能，也没有其他修复。

节奏

据同一次 2026-11-09 的 registry 取证：10-22 至 11-09 的十九个晚上有十八个晚上至少发布一个 dshmarket 版本，安静的 10-25 仍是唯一空档；截至取证，11-09 恰有一个版本（17:08:25 UTC），是连续第三个单版夜。DSH 插件市场保持着夜间节奏，发布页依旧由仓库的 github-actions 机器人署名，而非人工账户。

本系列更多

官方参考