dsh-update-checker

Configuration & portability

All paths are auto-detected at runtime — nothing is hardcoded, so the same package works on any machine:

• Plugin / profile directory ($DSH_HOME/profiles/node_modules): derived from the plugin's own install location (import.meta.url), walking up to the enclosing node_modules. No configuration needed.
• $DSH_HOME: derived as the parent of the profiles root (state file, backups, and restart log all live there).
• Composition file (cordis.patch.yml): defaults to $DSH_HOME/profiles/web/cordis.patch.yml; if absent, any other cordis.patch.yml under $DSH_HOME/profiles/ containing the plugin id is used.
• Deployment root: detected in two strategies, in order:
  1. Junction resolution — on machines where profiles/node_modules/@deepseek-ai/dsh is a junction (the common "save C-drive" setup), realpath() yields /node_modules/@deepseek-ai/dsh, so the deployment root is derived automatically.
  2. Fallback candidates — environment variable DSH_DEPLOY_ROOT, then process.cwd() (launchers usually cd into the deployment directory). To point elsewhere, set DSH_DEPLOY_ROOT or append to DEPLOY_ROOT_CANDIDATES at the top of lib/index.js.
• Restart launcher: self-adapting — probes common names (start-dsh.cmd, 启动 dsh.bat, start-dsh.bat, …) under the detected deployment root; the web port is read from the running webServer.port. No machine-specific paths are hardcoded in the restart flow.
• Persisted state (suppression flag, backups) lives under the detected $DSH_HOME — machine-independent.