Skip to content

1.4.2

Choose a tag to compare

View all tags
@SuCriss SuCriss released this 29 Sep 02:55
· 10 commits to main since this release
v1.4.2
bae83d6

dsh-version-update 1.4.2

快照的记录不再落进 live 安装树，被推迟的残留清理也不再等下辈子。

修复

  • 恢复快照不再把快照自己的记录丢进 live 安装树。 一个快照目录同时是两样东西：store 条目，以及 payload。payload 是安装树的副本，而 store 条目带着插件自己的 meta.json——版本、时间戳、文件清单——由 createSnapshot 写进同一个目录。restore 原本把这个目录整个拷回去，于是 meta.json 落在了 live 树的根上；那既不是包会发布的文件，也不是 npm 会删的文件。本机 history.json 里有 9 条 restored: true，最后一条在 09:35:42，而对应的 live 树里 meta.json 已经长到 2,496,985 字节 / 26,513 条记录。现在只过滤这一个路径，而且只过滤这一个——payload 子目录里的同名 meta.json 是 payload、不是记录，照旧复制。
  • boot 期不得不推迟的残留目录，现在会被补收。 npm 替换一个包的方式，是把它 rename 成点前缀的兄弟目录（.dsh-<8 位随机字符>），reify 正常跑完就删掉；被 kill 的安装会把它留下，而 npm 自己的读取器忽略一切点前缀目录，所以它永远收不回去。boot 期会扫这些目录，但刻意跳过不足十分钟的，以免和仍在写入的安装抢。问题在于它再也不会回来：挂载时发现的、太年轻而不能碰的残留，会被上报给面板，然后原样留到下一次启动——而一个长期不重启的宿主，下一次启动永远不来。现在挂载会为「它老过闸门的那一刻」武装一个一次性定时器，运行前再确认 updater 空闲。本机那个 .dsh-MzqSjRg1——134 MB，创建于 2026-09-18，并不是 09-28 那次失败安装的产物——正是这种情况：每次挂载都被发现，一次都没被删。
  • 没有 APPDATA 也能找到 Windows 的每用户 npm 前缀。 全局安装搜索原本以 %APPDATA%\npm\node_modules 为根，那是权威位置，但不保证存在于宿主被启动时的环境里——从一个没收到它的 shell 启动的宿主，解析不出任何全局前缀，设置页于是把这个安装报成未纳管。现在由 USERPROFILE 兜底。本机实测：process.env.APPDATA 是 undefined，而 USERPROFILE 有值——所以兜底的那条路径，才是这里真正解析得出来的那条。

测试

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

Full Changelog: v1.4.1...v1.4.2

Assets 2
Loading