dsh-plugin-upgrader 1.0.2 → 1.1.1

package/CHANGELOG.md

@@ -1,5 +1,139 @@
 # Changelog
 
+## 1.1.1 — 2026-10-27
+
+- **The row no longer offers to switch the running version to itself.** A
+  path-installed bundle asked the registry for its version list but did not pass
+  its installed version along, so no row was marked as the one loaded. The row
+  the user is already on then drew a live "back to latest" button that pointed at
+  that same version. Two fixes: the installed version is passed through for path
+  installs too, and the button label no longer keys on "this is the latest
+  release" alone — a row that is both current and latest reads "switch", disabled.
+
+## 1.1.0 — 2026-10-27
+
+The first published release since 1.0.2: the `1.0.3` entries below shipped in
+this version, together with everything listed here.
+
+- **Upgrading a theme plugin no longer leaves the page unstyled.** Replacing an
+  appearance plugin (`dsh-dream-skin`, `*-skin-*`, `dsh-client-ui-theme`) unloads
+  the code that injected its stylesheet, so the page snaps back to the host's
+  default look. The settings are NOT lost — `dsh-dream-skin` keeps them in
+  `$DSH_HOME/dream-skin.json`, outside the profile and written atomically, which
+  is why that file survives an upgrade untouched — but the injected CSS and the
+  `data-*` attributes on `<html>` lived only in the page, and the restarted
+  plugin has no way to put them back without being asked. A batch that actually
+  replaced such a plugin now says so and reloads the page once, after the plugin
+  has restarted, so the look comes back from that file. The reload is skipped for
+  failed steps, for steps that changed nothing, and for every ordinary plugin — a
+  failed upgrade must not also throw the page away.
+- **The upgrader's own row explains itself, and can update itself.** Both halves
+  of "这个插件没法管理自己" were real, and they are different problems:
+  - *The row was blank.* Installing as `link:`/`file:` made the overview skip the
+    registry lookup entirely, so the row showed a version, an arrow with nothing
+    after it, and no history. A path install now still reads the published list
+    (the directory keeps its own version, which is what is actually loaded) and
+    says so, instead of looking like a package that was never published. It stays
+    non-upgradable: replacing a `link:` with a registry tarball is a different
+    install, not an upgrade.
+  - *It could not update itself.* A version change through the batch job starts
+    with `removeBundle`, and removing this bundle unloads the very code that
+    would run the install that follows — the batch dies with the plugin that was
+    driving it, leaving the profile without it. The row now offers the page's own
+    installer instead (`plugins.tab` owner prop `install`), which is owned by the
+    plugin manager and therefore survives the unload. The batch and "Select all"
+    skip this row for the same reason, so one click can no longer strand the
+    profile.
+- **The version list no longer silently disappears.** Several plugins drew no
+  history button and no explanation, which looked like "this package has no
+  published versions" — it was a failed registry lookup being swallowed. Three
+  separate causes, all measured against `registry.npmmirror.com`:
+  - **The tab asked for every package at once.** Eleven concurrent connections
+    timed out at the 10 s deadline while the same eleven asked one at a time
+    answered in under 1.2 s. Lookups now go through a four-at-a-time cap.
+  - **The documents are large.** `billion-context` is a 26 MB packument and
+    10 MB even abbreviated, so a healthy request could lose a 10 s race on its
+    own. Lookups now ask for npm's abbreviated form
+    (`application/vnd.npm.install-v1+json`, which keeps `time`, `engines` and
+    `deprecated`), the deadline moved to 20 s, and a transport failure is
+    retried once — a `UND_ERR_CONNECT_TIMEOUT` is socket contention, not a
+    verdict about the package.
+  - **The failure was invisible.** A row whose lookup failed is now drawn with
+    the reason (`版本列表读取失败，点「检查更新」可重试`) instead of looking
+    like a package with no history. A failed lookup is also cached for a shorter
+    window than a successful one, so one bad render does not make the next
+    mount slow too.
+- **A mirror's stale `latest` tag no longer turns an upgrade into a downgrade.**
+  npmmirror serves `@deepseek-ai/dsh-subagent-codex` with `latest: 0.0.1-rc.1`
+  while the profile runs `0.2.1-rc.3`, so the row claimed the installed build
+  was newer than latest and offered a downgrade as an upgrade. A tag that sorts
+  below the installed version is now treated as broken and recovered from the
+  published list, preferring a stable release over a prerelease. A prerelease
+  that merely sorts above a healthy tag still does not steal `latest`.
+- **An upgrade no longer dies on `bundle-in-use`.** Replacing a version means
+  remove + install, and `removeBundle` only unloads a bundle it reads as enabled.
+  A plugin that is disabled but still holds a live loader fiber therefore went
+  straight to the "in use" check and was refused, which made every upgrade of a
+  disabled plugin fail. The removal now clears that fiber and retries once.
+- **The unload asks the right question.** 1.0.3's follow-up assumed
+  `setBundleEnabled(name, false)` reloads unconditionally, so it would dispose the
+  fiber. It does not: `selectBundle` returns early when the bundle is already
+  deselected, so the manifest does not change, so `reconcileProfile` has no
+  dropped row to dispose and the fiber survives — the retry then failed for
+  exactly the same reason. The removal now reads `enabled` first and, for a
+  bundle the manager already reads as disabled, re-selects it and deselects it
+  again, which is the only form of the toggle that produces a change a live
+  process can act on.
+- **A refusal the host cannot fix says so.** A second `bundle-in-use` now comes
+  back with the manager's code *and* a bilingual diagnostic ("the loader still
+  holds its plugin row; restart DSH and upgrade again"), and the tab shows the
+  diagnostic instead of the bare code. Retrying in the same process cannot clear
+  it, so the panel has to name the one action that does. The re-select is also
+  undone on the way out, so a failed upgrade never leaves the plugin enabled.
+- **The primary button follows the theme.** Its label colour comes from
+  `--dsw-alias-label-primary-inverted` instead of a hard-coded white, so it stays
+  readable when the host theme uses a light primary fill.
+- **Tests**: `test/install.test.ts` covers the replacement path (the remove +
+  install fallback and its fresh request id, the unload retry, the
+  already-disabled re-select including a refused one, the enabled-state restore,
+  and the restart diagnostic on both refusal spellings); `test/registry.test.ts`
+  covers the abbreviated request, the single retry, the shorter failure cache and
+  the 404-is-not-contention rule; `test/overview.test.ts` fails if a page load
+  stops respecting the cap; `test/shape-packument.test.ts` pins the stale-tag
+  rule. `scripts/verify-overview-live.mjs` runs the built host half against the
+  real mirror.
+
+## 1.0.3 — unreleased as its own version
+
+These changes were staged for 1.0.3, which was never published on its own; they
+first shipped in 1.1.0.
+
+- **Upgrades report what pnpm is doing.** The host subscribes to
+  `plugin-manager/install-log` and `plugin-manager/install-state`, so pnpm's own
+  output ("Verifying lockfile against supply-chain policies", `ETIMEDOUT` retries,
+  registry fallbacks) now streams into the job log while the step runs, instead of
+  only surfacing after it ends. An upgrade that sits for five minutes on the mirror
+  retry ladder finally looks like what it is.
+- **The progress bar is honest about long steps.** While a step is in flight the
+  panel shows a live elapsed clock, the phase (`installing` / `applying` /
+  `cancelling`), the registry attempt when a fallback is in progress, and an
+  indeterminate bar. `done/total` only moves when a step really finishes, which
+  previously left it pinned at 0% for minutes.
+- **Cancel works at every stage.** The second install of a remove + install used to
+  pass `requestId: undefined`, so that whole stretch was uncancellable; each install
+  now mints its own id and the job reports it back. Cancelling also explains what
+  happened: settled already, past the point of no return, or stopping now.
+- **The heartbeat is a timer (2 s) instead of a per-step write.** A single step over
+  the 15-minute stale window was declared abandoned mid-work, which both killed a
+  healthy job and let a second batch start against the same profile.
+- **A failed install no longer tries to restore the enabled state** of a package it
+  never added, which used to report a second `operation-error` on top of the real
+  failure.
+- **The panel no longer sticks after a batch settles.** `submitJob` resolves only
+  after the whole batch finished, and the tab wrote a fresh `queued` snapshot over
+  the result, leaving the spinner and the disabled buttons behind until the tab was
+  remounted.
+
 ## 1.0.1 — 2026-10-23
 
 - **Rewritten in TypeScript.** The whole project is now typed; `pnpm run typecheck`

package/README.en.md

@@ -18,6 +18,9 @@ English · [中文](./README.md)
 
 - **One-click upgrade** — bump every upgradable plugin to its newest version, with
   progress, per-plugin results and failure reasons.
+- **Progress you can actually see** — the raw pnpm output (registry retries, lockfile
+  verification), a live elapsed clock per step, an indeterminate bar while a step
+  runs, and a cancel button that works.
 - **Multi-select upgrade** — tick any subset of plugins and upgrade only those.
 - **Version history / rollback** — expand any plugin to see every published version
   (with publish date and engine requirement) and switch to it in one click.
@@ -75,8 +78,8 @@ host half:
 | --- | --- |
 | `GET /api/plugin-upgrader/overview` | installed plugins plus their published versions (registry packument, 5-minute cache, 10-second timeout) |
 | `POST /api/plugin-upgrader/job` | queue a batch of upgrade / switch steps, return a job id immediately |
-| `GET /api/plugin-upgrader/job?id=…` | poll progress and per-plugin results |
-| `POST /api/plugin-upgrader/cancel` | abort the step in flight |
+| `GET /api/plugin-upgrader/job?id=…` | poll progress, current phase, elapsed time, per-plugin results and the live log |
+| `POST /api/plugin-upgrader/cancel` | abort the step in flight, including the second install of a remove + install |
 
 Every route is loopback-only: a batch installs packages, so a paired remote device
 or a cross-site page must never reach it.
@@ -94,6 +97,29 @@ Removing a plugin drops its enabled / disabled state, so each step re-applies
 `setBundleEnabled` with the state it had before the upgrade. A disabled plugin stays
 disabled after being upgraded.
 
+### Why an upgrade sometimes takes minutes
+
+Not this plugin: pnpm. Before installing, pnpm 11 re-checks every lockfile entry
+against the registry (`Verifying lockfile against supply-chain policies`), and a
+mirror such as `registry.npmmirror.com` answers `ETIMEDOUT` for plenty of packages,
+which starts a 10-second → 1-minute retry ladder. Upgrading an already-installed
+package additionally costs two pnpm runs (remove, then install).
+
+The old build showed nothing during that time and moved the bar once per completed
+step, so it read as a hang. The host now subscribes to
+`plugin-manager/install-log` and `plugin-manager/install-state` and streams pnpm's
+own output, the phase and the retry count into the job log, while the panel shows an
+elapsed clock and an indeterminate bar — a slow install looks like a retrying one
+instead of a frozen 0%.
+
+Two related bugs fixed with it:
+
+- The heartbeat is a timer (2 s), no longer a write per completed step. A single step
+  lasting over 15 minutes used to be declared abandoned, cancelling a healthy job and
+  letting a second batch start on the same profile.
+- The second install of a remove + install passed `requestId: undefined`, making that
+  stretch uncancellable. Every install now has its own id, so cancel works throughout.
+
 ### One batch at a time
 
 The host runs one job at a time. A second submission gets `409 busy` with the id of
@@ -104,7 +130,7 @@ error:
   the running batch
 - `overview` carries an `active` field, so a freshly mounted tab reconnects to work
   in progress
-- a job writes a heartbeat every few seconds; a job left behind by a host restart is
+- a job re-stamps a heartbeat every 2 seconds; a job left behind by a host restart is
   declared abandoned once the heartbeat goes stale, so it cannot block every later
   upgrade with a permanent `busy`
 

package/README.md

@@ -15,6 +15,8 @@ DSH 自带的插件页能装、能卸、能看已安装列表，但缺两件事
 ## 功能
 
 - **一键升级** —— 一次把全部可升级插件升到最新版，带进度、逐项结果和失败原因。
+- **看得见的进度** —— 升级时直接显示 pnpm 的原始输出（含换源重试、lockfile 校验），
+  每步都有已用时计时和不确定态进度条，卡住时可以一键取消。
 - **多选升级** —— 勾选任意几个插件，只升级选中的这些。
 - **版本历史 / 回滚** —— 展开任意插件即可看到已发布的全部版本（含发布时间与引擎要求），点一下切到那个版本。
 - **一键跳 GitHub** —— 每行的 `GH` 按钮打开插件仓库主页；点版本号直接进该版本的 GitHub 发布页。
@@ -67,8 +69,8 @@ dsh plugin --profile web add "$PWD"
 | --- | --- |
 | `GET /api/plugin-upgrader/overview` | 已安装插件 + 各插件已发布版本（registry packument，5 分钟缓存，10 秒超时） |
 | `POST /api/plugin-upgrader/job` | 提交一批升级 / 切换步骤，立即返回 job id |
-| `GET /api/plugin-upgrader/job?id=…` | 轮询进度与逐项结果 |
-| `POST /api/plugin-upgrader/cancel` | 中断当前步骤 |
+| `GET /api/plugin-upgrader/job?id=…` | 轮询进度、当前阶段、已用时、逐项结果与实时日志 |
+| `POST /api/plugin-upgrader/cancel` | 中断当前步骤（含「先卸载再安装」的第二次安装） |
 
 所有路由仅限本机回环访问：批量操作会安装软件包，配对设备或跨站页面一律拒绝。
 
@@ -83,6 +85,25 @@ dsh plugin --profile web add "$PWD"
 卸载会丢掉插件原有的启用 / 禁用状态，因此每一步在安装完成后会按操作前的状态
 重新 `setBundleEnabled`，禁用中的插件升级后仍然是禁用状态。
 
+### 为什么升级有时候要好几分钟
+
+不是这个插件慢，是 pnpm 慢。pnpm 11 在 `install` 前会拿锁文件里的每个条目去 registry
+重新核对一次（`Verifying lockfile against supply-chain policies`），国内镜像
+（`registry.npmmirror.com`）对不少包会 `ETIMEDOUT`，于是走 10 秒 → 1 分钟的重试阶梯。
+一次「升级」如果目标是已安装的包，还是 remove + install 两条 pnpm 命令，两段各等一次。
+
+旧版本在这里什么都不显示，进度条只在「整步完成」时动一格，所以看起来就是死住了。
+现在宿主端订阅了 `plugin-manager/install-log` 和 `plugin-manager/install-state`，
+把 pnpm 的原始输出、当前阶段、重试次数实时转进 job 日志，界面同时显示已用时和
+不确定态进度条：慢的时候你能看见它在重试，而不是盯着一个不动的 0%。
+
+顺带修掉的两个坑：
+
+- 心跳改成定时器（2 秒），不再按「完成一步」写。单步超过 15 分钟以前会被误判成
+  「job 已放弃」，于是一个健康的任务被作废，还能再并进来一批。
+- 「先卸载再安装」的第二次安装以前用 `requestId: undefined`，导致那一段无法取消；
+  现在每次安装都有自己的 id，取消在任何阶段都有效。
+
 ### 同一时刻只跑一批
 
 宿主端一次只允许一个 job。重复提交会拿到 `409 busy`（带正在跑的那个 job id），
@@ -90,7 +111,7 @@ dsh plugin --profile web add "$PWD"
 
 - 新开一个插件页标签、或在进度跑着时再点「一键升级」，都会看到正在进行的那一批
 - `overview` 里带 `active` 字段，标签页一挂载就能接上正在跑的任务
-- job 每隔几秒写一次心跳时间戳，宿主重启后遗留的「僵尸 job」会按心跳超时自动作废，
+- job 每 2 秒刷一次心跳时间戳，宿主重启后遗留的「僵尸 job」会按心跳超时自动作废，
   不会永久占着位置让之后所有升级都撞 `busy`
 
 主进程重启会让正在跑的 job 中断，界面会把这种情况显示为失败而不是永远转圈。