Skip to content

1.4.1

Choose a tag to compare

View all tags
@SuCriss SuCriss released this 28 Sep 06:24
· 14 commits to main since this release
v1.4.1
7fccf22

dsh-version-update 1.4.1

安装与修复不再被宿主自己的工作目录挡住。

修复

  • 宿主从自己的树内启动时，安装和随后的修复都会失败。 npm 的 reify 替换一个包的方式，是先把被替换的目录改名让开；而 Windows 不允许 rename 一个「有任何活进程把它当工作目录」的目录——目录本身被占用报 EBUSY，被占用的子目录会让父目录的 rename 报 EPERM。dsh web 继承 shell 的 cwd，于是一个从自己树内启动的宿主，恰好把 npm 即将替换的那个目录交到了 npm 手里：0.1.7-rc.2 的每一次安装都死在 dsh\lib 上的 EBUSY，而 npm 自己的 cwd 正是那个目录；紧接着跑的那次修复则栽在同一个条件上，以一句裸 EPERM 收场。npm 现在从临时目录启动——在本插件管理的每一棵树之外。分离的 relaunch helper 也一并挪开，因为它正是那个可能要把 live 树 rename 回去的进程；而替换进程的 cwd 仍然走 payload，它必须与被替换的宿主一致。
  • 因树被占用而失败的 rename 现在会说明原因。 live 树 rename 上的 EPERM 读起来像权限问题，会让人去找一个并不存在的权限。这里的 EPERM/EBUSY/EACCES 现在会被翻译成真正的原因和出路——退出 dsh，然后在终端里 npm install -g @deepseek-ai/dsh@latest。而 rename 目标只是名字被占时，在 Windows 上同样报 EPERM，这种情况被刻意不归因到占用。
  • 什么都没恢复的修复不再被记成成功。 只要 package.json 还能解析，审计记录就写 ok，于是一次已经告诉面板自己失败（且把 treeHealth.healthy 留成 false）的修复，在 history.json 里却是一次干净的修复。它现在与面板消息、operations.end、treeHealth.healthy 用同一个判据。

测试

250 用例通过，tsc --checkJs 干净。

Full Changelog: v1.4.0...v1.4.1

Assets 2
Loading