feat: runtime extensibility with plugin-like implementation#160
Draft
NNTin wants to merge 3 commits intopablodelucca:mainfrom
Draft
feat: runtime extensibility with plugin-like implementation#160NNTin wants to merge 3 commits intopablodelucca:mainfrom
NNTin wants to merge 3 commits intopablodelucca:mainfrom
Conversation
- Add src/plugin/types.ts: IPixelAgentsPlugin, IAgentProvider, IAgentHandle, IMessageBridge, IRuntimeUI, PostMessage, and related interfaces - Add src/plugin/registry.ts: registerPlugin/getPlugin singleton - Add src/vscode/VSCodePlugin.ts: WebviewViewProvider + IPixelAgentsPlugin impl - Add src/vscode/VSCodeAgentProvider.ts: terminal lifecycle via IAgentProvider - Add src/vscode/VSCodeMessageBridge.ts: webview ↔ extension bridge - Add src/vscode/VSCodeRuntimeUI.ts: VS Code dialog/state APIs via IRuntimeUI - Add src/core/agentLifecycle.ts: runtime-agnostic agent + message coordination - Replace vscode.Webview param with PostMessage in fileWatcher, transcriptParser, timerManager, assetLoader - Replace ExtensionContext param with IRuntimeUI in layoutPersistence - Replace AgentState.terminalRef with AgentState.handle (IAgentHandle) - Remove PersistedAgent from types.ts (replaced by PersistedAgentHandle) - Delete PixelAgentsViewProvider.ts and agentManager.ts (replaced by new modules) - Slim extension.ts to only wire up the plugin and lifecycle Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The /api/dev-assets endpoint was Vite dev-server only (configureServer hook), causing 404 in the production static build on Vercel. Added a generateBundle hook to emit dev-assets.json alongside the JS/CSS artifacts so browser mock asset loading works in production. Also renamed the dev middleware path to /dev-assets.json for consistency. Removed broken /vite.svg favicon reference. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
florintimbuc
added
type: feature
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
2 participants
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.
❗ This PR will be in draft for a while. When I work on the PR I will rebase main/merge main into it. This is not production ready. A few iteration is needed to maybe add Plugin-like support. ❗
Many PRs and Issues are regarding extending support. A proper way to support other services or allowing custom implementation is needed. Hence I worked on a plugin system:
Plugin / main PR:
NNTin#8
example usage of plugin:
NNTin#9
-> here a custom backend solution is used to mirror Discord Users as Agents and have Discord Messages displayed in the browser frontend.
It turns out "plugin" is not a viable approach. VS Code does not support plugins directly interfering with each other, rewriting its behavior. What can be done instead is having third party services collaborate with each other through pre-defined interfaces. e.g. via http, ws, RPC.
So this part of it needs to be re-written.
What's important is to separate VSC/Cursor related code from the core of it so other runtimes can register. Including a custom runtime, like NNTin#9
The question is now the definition of the interface with third party services. Should this be done over HTTP, WebSocket or RPC? Or PubSub? With Register/Deregister? Support multiple "providers" or only a single one?
I'm fine with either implementations. It's just important that this step is specified so it can be implemented that way.
I would like to provide a specification along with it. OpenAPI is a solid one I have experience with but with our event-driven nature it is not suited. AsyncAPI and OpenRPC I have not much experience with. So having guidance there would be cool.