dshseek
English

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

dshmarket 1.73.18：空档一晚后的九项变更，三位首次贡献者（11 月 11 日）

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

TL;DR

据 npm registry（取于 2026-11-11），dshmarket 在空档一晚之后，于 2026-11-11 16:49 UTC 发布 1.73.18。据发布说明，它包含九项变更——八项 fix 与一项 feat——并点名三位首次贡献者。修复包括：启用 carrier bundle 不再让宿主进程退出，重装成功后「取消更新后被移除了」的过期提示会被清除。

夜间节奏空了一晚，回来时带着九项变更，而上一版是四项：据 npm registry（取于 2026-11-11），没有任何 dshmarket 版本的发布时间落在 2026-11-10，1.73.18 于 11 月 11 日 16:49:38 UTC 上架并接走 dist-tag latest——dshmarket 1.73.17：三项修复与一项市场提速，全部出自首次贡献者（11 月 9 日）覆盖了空档之前的最后一版。GitHub 发布页时间戳 16:42:32 UTC，由仓库的 github-actions 机器人署名，并附有 v1.73.17…v1.73.18 的对比区间。

九项变更，七位作者，三位首次贡献者

据发布说明，What’s Changed 恰列九项——八项 fix 与一项 feat；New Contributors 一节点名三位完成首次贡献的作者：@ai-zen-future（#1169）、@CyberYui（#1172）与 @justinzyc271828-sys（#1173）。九项出自七位作者：@gongfpp 与 @Eapp1e 各占两项——据 1.73.16 的发布说明，@Eapp1e 正是那一晚唯一的新面孔——而 1.73.17 发布说明点名的四位首次贡献者无一出现在本次名单中。

各 PR 记录的合并时间戳把九项中的五项放在发布日之前。#1159 于 11-09 17:49 UTC 合并，距 1.73.17 在 npm 上架约四十分钟；#1165 与 #1166 于 11-10 13:24 UTC 一同合并，#1168 与 #1169 于同日 16:48 UTC 一同合并。其余四项于 11-11 16:41 UTC 合并，与发布页的时间戳相隔不到一分钟。

  • PR #1177（fix(toggle)）——启用 carrier bundle 时不再清掉 disabled: !!js 守卫。据 issue #1175（Fomalhaut-hub 于 11-11 10:04 UTC 提交，环境为 dshmarket 1.73.17 与 @deepseek-harness-tui/dsh-tui 0.19.0），在市场的插件页把 DSH TUI 全屏终端打开，市场先连续写 4 条 -> on: fiber=true，紧接着整个 dsh web 进程以 StorageError: storage form 'domain' is already mounted 退出；重启后这个插件又显示为关闭，于是「打开 → 进程退出 → 重启后仍是关闭」可以反复复现。据 PR 正文，carrier bundle 的 patch 为宿主可能已经挂载的行准备 disabled: !!js … 守卫——web profile 里 storage-domain 由 dsh-base 挂载，守卫求值为 true，所以启动正常——但实时的「打开」路径没有认这套守卫：setEntryDisabled(name, false) 对每个匹配到的 entry 调 update({ disabled: null })，把守卫求值出来的 true 清掉，dsh-tui-storage-domain 随即在同一个进程里第二次挂载 domain；dsh 对重复挂载是 fail-loud 的，进程直接退出。正文指出同一个判断在持久层早就有了——switchPluginLayers() 用 bundleExpressionRowIds() 跳过这些行（#1043）——而实时层跑在它之前。修复在两处把已有规则往前挪一层：实时开关在「开」的时候跳过包自己用表达式决定的行，且只在「开」的时候跳，因为用户想让一条被守卫的行关掉，这个意图应该始终成立；carrier bundle 的「开」和它的「关」一样，留给下一次组合——toggle 路由本来就把 carrier 的开关报成 restart: true。据正文，新增的两个 flows 用例去掉本修复后是红的，npm test 为 3329 通过、4 跳过；issue 里的第三条建议——matchingEntries() 的 carrier 兜底不应把宿主提供的包算作第三方 bundle 的行——没有一起改，留在 issue 里等维护者决定。从 issue 提交到修复合并不到七小时：PR 于 14:37 UTC 提交，16:41 UTC 合并。

  • PR #1165（fix(install)）——「声明被移除」提示改按实际装入的包名清除。据 issue #1164（Start-Gao 提交，环境为 DSH Desktop 0.2.2-rc.1），「已安装」页顶部的橙色提示条一直显示 dsh-better-sidebar 侧边栏工作台取消更新后被移除了，而插件已于 2026-11-08 通过市场重装成功、状态为 live；提示在刷新页面、重启桌面端、市场升级到 1.73.17 之后仍然存在，唯一能消除它的是手动点「不再显示这条」——issue 指出，设计预期的那条路径（重装成功后自动清除）会写一条 update-reinstalled 日志，而导出的日志里没有这条。据 PR 正文，brokenPlugins 以 profile 依赖名为键，install 路由却用 entry.name 去清——那是目录的展示名，沿用 GitHub 仓库的大小写——于是每一个两个名字不一致的条目，清理都打在一个从不存在的键上，clearBrokenPlugin() 什么都没写就返回了；issue 自己的案例是目录条目名 DSH-better-sidebar 对 npm 包名 dsh-better-sidebar。修复改为按本次运行真正装进 profile 的内容清理——addedPackages 集合——再加上条目自己经过校验的 npm 名；两者都是精确键，所以没有记录的条目仍是无操作，也不会误清别的插件的提示。据正文，回归测试在真实的路由层与编排层上重走报告者的序列，回退那一行清理后是红的；flows 与 routes 两个 spec 共 525 通过。在 issue 下，fkysly（据各 PR 记录，本版九个 PR 均由该账户合并）于 11-10 确认根因，并写明修复会随下一个版本发布。

  • PR #1172（fix(discovery)）——宿主核心包被写成普通 dependency 时不再判为兼容。据 issue #1171（PR 作者 CyberYui 在提交 PR 约两分钟前提交），deriveHostCompatibility() 只读 engines.dsh 和 peerDependencies，插件如果把 DSH 宿主核心包写成普通 dependency，即使声明的范围运行时的版本根本满足不了，也仍然会被判为 compatible 或 undeclared——而 pnpm 会把那份副本装进来，盖住宿主自己的。记录在案的真实事故：dsh-qqbot@1.0.2 把 @deepseek-ai/dsh-settings 与 @deepseek-ai/dsh-credentials 声明为 ^0.1.0-rc.5；profile 用 nodeLinker: hoisted，pnpm 把解析出来的 0.1.0-rc.x 提升上去，遮蔽了运行时自带的 0.2.2-rc.1，加载器禁用了 settings 行，桌面欢迎页调 settings/describe 得到 settings service is absent，桌面端每次启动都崩，直到手工修好 profile——而市场自己的装前兼容性检查没有报出任何东西。issue 把它对应到 issue #98 提出过的一条检查项，并引用 src/check.ts 里一段仍在等某个 manifest PR 的注释；据 issue，那个 PR 从未提交。据 PR 正文，manifestFacts 现在读取 manifest.dependencies、只保留 @deepseek-ai/ 前缀，另有两个设计决定由测试锁住：不给 peer 宽容——^0.0.1 作为 peer 会被原谅，作为 dependency 必须拒绝，因为 dependency 是安装指令而不是意图声明；不加 dsh- 前缀限制，因为任何宿主提供的包被写成 dependency 都会被安装并提升。缺失 dependencies 字段仍然合法，持久缓存可以跨升级存活。据正文：discovery-compatibility 这个 spec 为 38/38，npm test 为 3326 通过、2 失败，两个失败都是符号链接权限用例，在 main 上同样失败。

  • PR #1173（fix(compat)）——按真正的优先级给出 pnpm store 的重连办法。据 PR 正文，ERR_PNPM_UNEXPECTED_STORE 这条分支给所有人的修法只有一句——把 node_modules/.modules.yaml 里记录的 store 写进 profile 的 pnpm-workspace.yaml——而作者在 pnpm 11.28.5 上实测，决定 store 的是一条更长的链：--store-dir、PNPM_CONFIG_STORE_DIR、pnpm-workspace.yaml 的 storeDir、全局 npmrc 的 store-dir、默认位置。正文列出这句话不成立、且失败时没有任何提示的四种情况：profile 里已经写了记录里的路径（#1100 的场景）；写的是 kebab 写法 store-dir，pnpm 忽略该键、只在 stderr 留一行 WARN；环境变量设了 store，而文件优先级更低；记录里的 store 已被移走。第三种就是作者自己那台机器的实际情况：PNPM_CONFIG_STORE_DIR 指向新盘，报错给出的修法照着做两遍，第三遍还是同样的错。新消息只按实际生效的那一层给办法，并给一条能自证结果的检查——pnpm store path 必须正好打印记录里的路径；路径读不出来时仍然保留键名与检查，不再编造路径。据正文，它不加自动修复——store 选哪个是用户自己的事，#244 的既有测试钉住了 recoverable === false——新增的 5 个测试改动前全部失败；npm test 为 3319 通过、8 失败，正文把这 8 个归为本机没有创建符号链接与 junction 权限的既有失败，在未改动的 nightly1014 上同样失败。

  • PR #1168（fix(settings)）与 PR #1166（fix(verify)）——issue #1144 报告的 dsh 0.2.x 上三处静默失效中的两处，均出自 @Eapp1e。据 #1168 的正文，dsh 0.1.7 起 settings 服务只剩 describe 与 update、没有 register，宿主改成从插件自己的 Config schema 派生表单；本仓导出的是 export type Config——纯类型，运行时不存在 schema——于是这个 entry 被整条跳过，插件配置页没有这个插件的任何可编辑项。修复补上运行时的 export const Config，用的是 schemastery，与 src/settings.ts 同一个包，不新增依赖；allowRestart 与 maxSnapshots 带 volatile 标记，每个字段和根都是 .loose()，已经写在 cordis.yml 里的值照常启动，有 register 的旧宿主一条路径都没动。正文还点出一处必须同时改的读数：带 volatile 标记的字段在新宿主上解析成的是一个实时引用，不是值本身，所以 apply() 里三处读这两个字段的地方先取值再往下传；不取的话，register 路径会把那个对象交给 MarketSettings，校验抛错，命名空间注册失败，/dsh-market/status 永远停在 pending——正文称这正是 CI 上 0.1.0、0.1.2、0.2.0、0.2.1 各代 web-e2e 全红的直接原因。据 #1166 的正文，@deepseek-ai/dsh-hooks-claude-code 作为 profile 的依赖安装，在每个跑了使用它的预设的会话里都正常工作，卡片却写着「已安装，未生效」：verifyActivation 只问了 bundle 层与 loader，而两者都看不到预设——预设的 plugins 行是按会话挂载的，从不进入宿主 loader。修复读取 profile 自己的 cordis.patch.yml，收集 agent-preset 行的 presets[].plugins[].name，以点名该包的那些预设作答；loader 的证据仍然优先，宿主实际加载的包保持 live。同一份正文把 #1144 的第二条——桌面宿主版本未知——留给另一个 PR。

  • PR #1159（fix(updates)）——find-compatible 只在更新确实执行 release-age 等待的地方报告它。据 PR 正文，自 #1133 起 /dsh-market/find-compatible 总是附上 maturity 结果；而在 CLI 宿主上，更新路径会带着 --config.minimum-release-age=0 重试一次，年轻的版本照样能装——对话框却读到 held: true，说该版本仍在 release-age 等待期内并禁用更新按钮，同时市场自己的更新列表给出的正是这个版本。修复让非桌面宿主上的更新返回 maturity: null，客户端本来就把它当作「给出该版本」；桌面宿主与全新安装维持 #1133 写下的 maturity 结果。据正文，新增的 flows 用例在 nightly1014 上失败、带修复后通过，npm test 为 3252 通过。

  • PR #1163（fix）——识别带版本号的 GitHub release 归档文件名。据 PR 正文，WhaleMaid 1.3.1 还曾以 dsh-whalemaid-full-1.3.1.tgz 分发，而当前目录公布的是 dsh-whalemaid-full.tgz，#1119 引入的精确文件名检查让这些来自同一仓库的旧安装看不到更新按钮。修复在文件名带有稳定的数字版本后缀、该后缀等于已安装 URL 的 release tag、且去掉后缀即得目录资产名时予以识别；仓库匹配、目录认可的更新目标、已发布 manifest 的校验与降级检查均保留，不相关的资产、不匹配的 tag 与被钉住的目录条目仍不符合条件。据正文，受影响的 572 个测试全部通过。据 PR 记录，这是九项中唯一目标分支为 main 而非 nightly1014 的一项。

  • PR #1169（feat(client)）——插件分组的全部收起与全部展开，本版唯一的 feat。据 PR 正文，分组较多时，用户需要逐个点击才能收起或展开列表；本 PR 在分组列表上方增加「全部收起 / 全部展开」，复用现有折叠状态，覆盖空分组，不影响未分组插件或插件启用状态。正文记录的范围：没有分组时隐藏按钮，已全部收起或展开时禁用对应按钮；搜索期间继续显示命中的分组与成员，并暂时禁用批量操作，清空搜索后恢复原折叠状态。文案包含中、英、日三种，不新增默认收起设置或持久化偏好——而正文标注由本 PR 关闭的 issue #1129，除全局按钮外还提出过默认状态的偏好项。据正文，npm test 为 3322 项通过、3 项跳过，未做原生桌面端实测。

说明在九项之外未列出任何内容。

节奏

据同一次 2026-11-11 的 registry 取证：10-22 至 11-11 的二十一个晚上有十九个晚上至少发布一个 dshmarket 版本。安静的 10-25 不再是唯一空档——11-10 是第二个；截至取证，11-11 恰有一个版本（16:49:38 UTC）。DSH 插件市场的发布页依旧由仓库的 github-actions 机器人署名，而非人工账户。

本系列更多

官方参考