refactor(appkit): forward eager plugin instance through preparePlugins#297
Closed
MarioCadenas wants to merge 1 commit intoagent/5d-relocate-shared-agent-filesfrom
Closed
Conversation
`toPluginWithInstance` eagerly constructs a plugin instance at factory-call time and exposes it via `PluginData.instance`. Previously, `preparePlugins` stripped this field before handing control to `createAndRegisterPlugin`, which then fell through to `new Plugin(baseConfig)` and constructed a second instance. The first instance (the handle the user holds at module scope) was discarded; dispatch used the second. Widen `InputPluginMap`'s entry type with an optional `instance?: BasePlugin` field and forward it through `preparePlugins`. The existing `preBuilt ?? new Plugin(baseConfig)` branch handles reuse. Plugins built via plain `toPlugin` have no `instance` field and continue to construct fresh inside `createAndRegisterPlugin`. This hardens an invariant that agents/agents.ts and other tooling now rely on: the handle returned from `analytics()` and friends is the same object that answers runtime requests. Signed-off-by: MarioCadenas <MarioCadenas@users.noreply.github.com>
This was referenced Apr 21, 2026
Collaborator
Author
|
Superseded by the v2 6-PR stack:
The v2 stack reorganizes the same work so no PR ships API that a later PR deletes. Start at #301 for the new entry point. Branches from this older stack are preserved unchanged. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Stepping-stone PR unblocking
fromPlugin(PR #298).At this point in the stack,
toPluginWithInstanceeagerly constructs a plugin instance (Instance A) at factory-call time and attaches it to the returnedPluginDataas an.instancefield. Previously,createApp'spreparePluginsstripped that field before handing control tocreateAndRegisterPlugin, which then fell through tonew Plugin(baseConfig)and constructed a second instance (Instance B). Dispatch used B; the handle the user held at module scope was A.This PR:
OptionalConfigPluginDefinpackages/shared/src/plugin.tswith an optionalinstance?: BasePluginfield.pluginData.instancethroughpreparePluginsinpackages/appkit/src/core/appkit.ts. The existingpreBuilt ?? new Plugin(baseConfig)branch handles reuse — ifinstanceis present, reuse it; otherwise construct fresh.Effect: for plugins built via
toPluginWithInstance(analytics, files, genie, lakebase), the handle a user holds at module scope is now the same object that answers runtime requests. Plugins built via plaintoPluginhave noinstancefield and continue to construct fresh — no behavior change.Why this is its own PR
The instance-forwarding fix is small, mechanical, and reviewable in isolation. PR #298's
fromPluginbuilds on top of it.Note for reviewers: this plumbing is reverted later in the stack (PR #300) once
toPluginWithInstanceitself is retired in favor offromPlugin. At that point no factory produces aninstancefield, so the forwarding logic becomes dead code and gets removed. We kept this PR in the stack rather than squashing because it was genuinely useful while it existed — it let #298 land incrementally on top of a working baseline, and it makes thefromPlugindesign rationale legible in review.PR Stack
agents()plugin +createAgent(def)+.toolkit()— feat(appkit): add agents() plugin, createAgent() factory, and .toolkit() #294agents()— feat(appkit): migrate agent-app and docs to the new agents() plugin #295preparePluginsforwards eager instance (this PR)fromPlugin()API — feat(appkit): add fromPlugin() for referencing plugin tools in code-defined agents #298agent()+createAgentApp— chore(appkit): remove deprecated agent() plugin and createAgentApp shortcut #299toPluginWithInstance+ bug fixes — refactor(appkit): retire toPluginWithInstance; consolidate on fromPlugin + fix schema/routing bugs #300Test plan
packages/appkit/src/core/tests/appkit.test.tsasserting instance identity fortoPluginWithInstancefactories and unchanged behavior for plaintoPlugin