You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(tui): diff plugin generations on reconcile instead of full teardown #39777
#39776 adds hot reloading of local TUI plugins: PluginProvider watches plugin sources and re-runs reconcile() on change. reconcile predates that PR and rebuilds the whole plugin generation imperatively: it deactivates every plugin (builtins included), wipes all registrations/slots/routes, then replays the entry list. Config plugins changes always behaved this way; hot reload just makes it fire on every file save.
Consequences per save:
every plugin's in-memory state resets, not just the edited one
all slots unmount/remount (visible churn), all routes re-register
manual activate/deactivate toggles from the plugins dialog reset
a save that fails to import drops the plugin entirely until the next successful reconcile
Proposal: fold-then-diff
Replace the imperative replay in packages/tui/src/plugin/context.tsx with:
Fold the entry list (discovered files + config directives, including - disables and selectors) into a desired end state: id -> { target, version, options, enabled }. For local files, version is the entrypoint mtime, which freshSpecifier already stats.
Diff against current registrations:
same target/version/options: leave untouched (no cleanup, no setup, slots stay mounted)
version or options changed: deactivate that plugin, re-import, re-activate
added/removed: activate/deactivate individually
builtins are static and never churn
Keep-last-good: when a changed source fails to re-import, keep the previous instance active and mark the state failed, instead of dropping the plugin.
This mirrors the core registry's versioned-generation semantics (packages/core/src/plugin/*: replacing a plugin with the same ID retains order; only the replacement is torn down), and makes a no-change reconcile a near-no-op, so spurious watch events (sibling files in a watched parent directory) cost a readdir + stats instead of a full rebuild.
Edge semantics to decide
plugin renames its id on edit: treat as remove old + add new
options changed in config: reload that plugin
ordering: end-state fold must preserve current directive semantics (later entries win)
Scope
TUI only. No change to the core plugin supervisor.
#39776 already landed the generation diff, selective reload, and keep-last-good behavior described here. I noticed one remaining per-save case from this issue: after a manual toggle in /plugins, a filesystem-triggered reconcile puts an otherwise unchanged plugin in the changed set because registration.active !== item.enabled, so an unrelated file save can undo that toggle.
Would the core team want manual enable/disable to persist when that plugin’s resolved generation and config directives are unchanged? I’d keep explicit changes to plugins directives authoritative. A focused follow-up could cover a manually disabled plugin surviving an unrelated file save, the same behavior for manual enable, and an explicit config directive change taking effect. This would leave #39776’s existing reload and keep-last-good behavior intact.
Closing the main plugin-generation diff request as completed. #39776 added generation comparison, selective reload, and keep-last-good behavior. The remaining manual plugin activation persistence is tracked separately in open issue #42417.
Activity
Dante-dan commentedon Sep 29, 2026
#39776 already landed the generation diff, selective reload, and keep-last-good behavior described here. I noticed one remaining per-save case from this issue: after a manual toggle in
/plugins, a filesystem-triggered reconcile puts an otherwise unchanged plugin in the changed set becauseregistration.active !== item.enabled, so an unrelated file save can undo that toggle.Would the core team want manual enable/disable to persist when that plugin’s resolved generation and config directives are unchanged? I’d keep explicit changes to
pluginsdirectives authoritative. A focused follow-up could cover a manually disabled plugin surviving an unrelated file save, the same behavior for manual enable, and an explicit config directive change taking effect. This would leave #39776’s existing reload and keep-last-good behavior intact.neriousy commentedon Oct 23, 2026
Closing the main plugin-generation diff request as completed. #39776 added generation comparison, selective reload, and keep-last-good behavior. The remaining manual plugin activation persistence is tracked separately in open issue #42417.