Skip to content

feat(tui): diff plugin generations on reconcile instead of full teardown #39777

Closed

Description

@kitlangton

Context

#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:

  1. 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.
  2. 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
  3. 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.

Activity

  1. Dante-dan commented on Sep 29, 2026

    @Dante-dan
    Contributor

    #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.

  2. neriousy commented on Oct 23, 2026

    @neriousy
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions