dsh-reload

LIMITATIONS

Known limitations

- **No uninstall tool.** `reload_plugin` cannot remove a plugin; removing a patch row is a config change, not a reload. The host reconciles that change live — after deleting three probe rows the running Loader tree went from 209 to 206 rows with no restart — and `scripts/uninstall.sh` performs the removal (patch row, `node_modules/dsh-reload`, skill) for a local install. - **`disabled: true` rows are never force-enabled.** `reload_plugin` reports the row instead and points at the profile's `cordis.patch.yml` (or the plugin manager). That is a config change. - **Only the target plugin's own modules are reloaded.** `node_modules` dependencies are deliberately left in the cache; touching them would swap out other plugins too. A plugin that is not in the ESM `loadCache` — one that was not loaded through the Loader — cannot be reloaded, and the report says so. - **Client (browser) halves still need a page refresh.** After the host half reloads, the browser may keep rendering the old components; with `pnpm run dev:web` running, the bundle watcher replaces them automatically. - **Internal APIs may change between DSH versions.** The plugin touches `ctx.loader`, `ctx.hmr`, `ctx.skills` and `ctx.registry`. Every internal call is guarded with `undefined` checks and `try`/`catch`, so a breaking DSH change produces an explicit error and a rollback rather than silent misbehaviour — but the structures it reads are not public API.