dsh-updater-npm

Usage

DSH Update

• Checks every 30 minutes (the page refreshes the cached result every 60 s).
• A red dot (🔴) appears next to "DSH Update" in the Settings sidebar when a new version exists.
• "Update via npm" runs npm install -g @deepseek-ai/dsh@latest with live progress (bar + the last few lines of npm output). There is deliberately no scrolling log panel — the full npm output is written to $DSH_HOME/plugin-data/dsh-updater-npm/last-run.log when the operation ends, so the card stays quiet and the log is still there when you need it.
• When the update finishes, a "Restart DSH" button appears: it exits the current process with the original command line and relaunches it (PowerShell on Windows, /bin/sh on macOS/Linux). The same button appears after source-tree updates and deployment repairs. No new activation URL is needed — the browser re-authenticates by itself and no new window pops up.
• Once a swap succeeded (i.e. the new version is actually running) the card shows the rollback point's disk usage and a "Remove rollback point" button. The previous deployment is kept as /dsh.old- (222 MB in a real case). Safety rule, enforced on the host: only rollback points whose version differs from the running version are listed and deleted — the live deployment is never touched.
• Version comparison is semver-style: a local version newer than the remote one (e.g. rc.7 vs rc.6) is not reported as an update.

Timeout policy and run log (since v1.12)

Older versions used a blunt 10-minute hard timeout for npm installs. On a slow link a staged install was measured downloading 247 tarballs (231 of the 239 @deepseek-ai sub-packages of a 222 MB tree) in 9 min 25 s and was then killed, reporting just staging install failed: npm — not a hang, not a broken network, simply a hard timeout.

The watchdog is now two-threshold, and configurable through $DSH_HOME/plugin-data/dsh-updater-npm/config.json:

{
  "docsEnabled": false,
  "npmIdleMinutes": 10,
  "npmTimeoutMinutes": 60
}

Key	Default	Meaning
npmIdleMinutes	10	minutes of zero activity before it is declared stuck and terminated (slow but moving ⇒ never killed)
npmTimeoutMinutes	60	absolute wall-clock ceiling, to stop a truly unbounded hang

What counts as activity (corrected in v1.12.1): watching the child's stdout alone is not enough — npm prints almost nothing when it is not attached to a TTY (one measured 5-minute install produced not a single stdout line while npm's own debug log recorded 525 requests, and the watchdog killed it). Three signals are now combined, and the maximum wins:

1. --loglevel=http — npm logs every request/stage to stdout (measured: 1111 lines instead of 0);
2. --logs-dir — npm's full debug log is written to plugin-data/dsh-updater-npm/npm-logs/;
3. filesystem activity — npm's debug log may only be flushed at exit on Windows (in a measured 14-second install it sat at 0 bytes for 12 of them), so the staging directory and its node_modules/ are watched as well: extraction keeps writing files there.

Only when all three are idle is the install treated as stuck; during a silent phase a [heartbeat] … line is appended every minute (into last-run.log).

• On a watchdog kill the log carries [watchdog] … and [exit] … lines, and the error states whether it was an idle timeout or the total limit, with the elapsed time — no more opaque : npm.
• The same policy covers staged installs, non-Windows in-place npm install -g, and source-tree pnpm/npm install; msiexec /qn is silent by nature and gets a 10-minute idle window.
• /dsh-updater-npm/progress returns progress only (no log payload).

Plugin self-version and self-update gate

• The card shows this plugin's own version and compares it with the latest dsh-updater-npm on npm (GET https://registry.npmjs.org/dsh-updater-npm/latest, cached for 10 minutes).
• If the plugin itself is outdated, the card says so and shows a copyable command (dsh plugin --profile add dsh-updater-npm@). The "Update via npm" button is disabled, and /update is refused server-side with the same message.
• Reason: updating DSH is performed by the currently running plugin code, and an outdated plugin's upgrade path may itself be unsafe (1.9.0, for example, staged without -g on Windows and lost every dependency after the swap).
• Offline pass-through: nothing is blocked unless a newer plugin version is positively known, so air-gapped or offline setups are not locked out.
• Source-tree mode (git pull) is not gated, only hinted.

DSH Docs

• Sync switch (off by default): the "DSH Docs" card has an "Auto-sync official docs" toggle. While it is off, nothing is synced and the dsh_docs_search / dsh_docs_read tools are not loaded. When on, the plugin syncs on first start (~217 files: English + Chinese .zh.md) and then every 24 hours, and registers the tools. The switch state lives in $DSH_HOME/plugin-data/dsh-updater-npm/config.json.
• "Sync official docs" triggers a manual sync (the switch must be on) with a progress bar (downloaded / total plus the current file) and phases (list → download → rebuild index).
• Search and read from the docs section, or straight from a conversation with the model tools:
  • dsh_docs_search — search the local official docs index (Chinese queries prefer Chinese docs)
  • dsh_docs_read — read one document (section focus, 80 KB truncation, path-traversal guarded)

Docs live in $DSH_HOME/docs-sync/, the index in $DSH_HOME/docs-sync/.index.json.