# JetBrains Plugin Support - Technical Design Document ## Context This document addresses [Issue #9982](https://github.com/RooCodeInc/Roo-Code/issues/9982), which requests JetBrains IDE support for Roo Code. ### User Requirements Based on community feedback, users are requesting: - Full Roo Code functionality in JetBrains IDEs - Primary focus on IntelliJ IDEA and WebStorm - Custom model integration capabilities (highest priority) - Leverage JetBrains' superior Java and Git tooling - Native JetBrains UI experience ## Current Architecture Analysis ### VS Code Extension Structure Roo Code is currently built as a VS Code extension with the following key components: 1. **Core Extension** (`src/extension.ts`) - VS Code API integration - Extension lifecycle management - Command registration and handling 2. **Webview UI** (`webview-ui/`) - React-based interface - VSCode webview toolkit integration - Communication via message passing 3. **Core Services** - Provider management (Anthropic, OpenAI, OpenRouter, etc.) - Model configuration and selection - Terminal integration - File system operations - Code indexing - MCP (Model Context Protocol) server support 4. **Cloud Integration** (`@roo-code/cloud`) - Authentication and user management - Remote control capabilities - Profile synchronization 5. **Type Definitions** (`@roo-code/types`) - Shared TypeScript interfaces - Provider settings schemas - API contracts ### VS Code-Specific Dependencies The following components are tightly coupled to VS Code APIs: - **Editor Integration**: TextEditor, TextDocument, Range, Selection APIs - **Webview System**: VS Code's webview API for UI rendering - **Terminal Integration**: Terminal creation and command execution - **File System**: VS Code's workspace and file system APIs - **Configuration**: VS Code's settings and state management - **Commands**: VS Code's command palette integration - **Diff Views**: Custom diff view provider - **Code Actions**: Quick fix and refactoring suggestions ## Approaches to JetBrains Support ### Option 1: Native JetBrains Plugin (Recommended) Build a separate native plugin using JetBrains Platform SDK. #### Architecture ``` roo-code-jetbrains/ ├── src/main/kotlin/ # Plugin code in Kotlin/Java │ ├── actions/ # IntelliJ Actions (commands) │ ├── services/ # Background services │ ├── ui/ # Tool windows and dialogs │ ├── settings/ # Settings UI │ └── integration/ # IDE integration points ├── src/main/resources/ # Resources and plugin.xml └── build.gradle.kts # Gradle build configuration ``` #### Key Components to Implement 1. **Tool Window**: Replace VS Code sidebar - Use IntelliJ's ToolWindow API - Implement UI with Swing or Kotlin UI DSL - Or embed browser component for web-based UI 2. **Editor Integration** - Document modification API - PSI (Program Structure Interface) for code analysis - Editor actions and intentions 3. **Terminal Integration** - TerminalRunner API - Command execution 4. **File System Operations** - VirtualFileSystem API - Document manager 5. **Settings Management** - PersistentStateComponent - Configurable interface for settings UI 6. **Provider Management** - Port provider configuration system - API key management - Model selection interface #### Shared Components Leverage existing code where possible: - **API Integration**: HTTP clients for LLM providers (can be shared) - **Type Definitions**: TypeScript types → Kotlin data classes - **Business Logic**: Core algorithms and workflows - **Model Configurations**: JSON schemas and definitions #### UI Strategy **Option A: Native Kotlin UI** - Pros: True native experience, better IDE integration - Cons: Requires complete UI rewrite, more maintenance **Option B: Hybrid (Embedded Browser)** - Pros: Can reuse React UI, faster development - Cons: Less native feel, performance overhead - Use JCEF (Java Chromium Embedded Framework) ### Option 2: Language Server Protocol (LSP) Bridge Create a language server that both VS Code and JetBrains can connect to. #### Architecture ``` ┌─────────────┐ ┌──────────────────┐ ┌─────────────┐ │ VS Code │◄───────►│ Roo Code LSP │◄───────►│ JetBrains │ │ Extension │ LSP │ Server │ LSP │ Plugin │ └─────────────┘ └──────────────────┘ └─────────────┘ │ ▼ ┌──────────────┐ │ LLM Providers│ └──────────────┘ ``` #### Pros - Shared business logic - Single codebase for core functionality - Standard protocol #### Cons - LSP not designed for AI coding assistants - Limited UI capabilities - Custom protocol extensions needed - Still requires significant client-side code ### Option 3: Minimal Adapter Plugin Create a lightweight JetBrains plugin that communicates with the VS Code extension. #### Architecture ``` ┌─────────────┐ ┌──────────────────┐ │ JetBrains │ │ VS Code │ │ Plugin │◄───────►│ Extension │ │ (Thin UI) │ HTTP/ │ (Core Logic) │ └─────────────┘ WS └──────────────────┘ ``` #### Pros - Minimal JetBrains-specific code - Leverage existing VS Code extension #### Cons - Requires VS Code running in background - Poor user experience - Dependency complexity - Not truly native ## Recommended Approach **Build a native JetBrains plugin** (Option 1) with a hybrid UI strategy. ### Phase 1: Core Functionality (MVP) 1. Tool window with chat interface 2. Provider configuration (custom models priority) 3. Basic file editing capabilities 4. Terminal command execution 5. Settings UI ### Phase 2: Advanced Features 1. Code indexing and search 2. Multi-file operations 3. Diff views 4. Cloud integration 5. MCP server support ### Phase 3: Polish and Optimization 1. Performance optimization 2. JetBrains-specific features (PSI integration) 3. Multiple IDE support (IntelliJ, WebStorm, PyCharm) 4. Comprehensive testing ## Technical Challenges ### 1. UI Framework - **Challenge**: React webview UI won't work in JetBrains - **Solution**: - Option A: Rewrite in Kotlin with Compose/Swing - Option B: Use JCEF to embed web UI - **Recommendation**: Start with JCEF for faster MVP, migrate to native later ### 2. Editor Integration - **Challenge**: Different APIs for document manipulation - **Solution**: Create abstraction layer over editor operations - Map VS Code concepts to IntelliJ equivalents: - TextDocument → Document - TextEditor → Editor - Range → TextRange - Selection → Caret ### 3. State Management - **Challenge**: VS Code's ExtensionContext vs IntelliJ's services - **Solution**: Use IntelliJ's service architecture and state components ### 4. File System Operations - **Challenge**: Different file system APIs - **Solution**: Abstract file operations behind common interface ### 5. Terminal Integration - **Challenge**: Different terminal APIs - **Solution**: Adapter pattern for terminal operations ### 6. Configuration Sync - **Challenge**: Users may want settings across both IDEs - **Solution**: Leverage Roo Code Cloud for cross-IDE profile sync ## Development Roadmap ### Prerequisites - JetBrains Platform SDK knowledge - Kotlin/Java development - Gradle build system - IntelliJ plugin development experience ### Estimated Timeline **Phase 1 (MVP): 3-4 months** - Plugin structure and basic UI: 4 weeks - Provider integration and model config: 3 weeks - File editing capabilities: 3 weeks - Terminal integration: 2 weeks - Testing and bug fixes: 2 weeks **Phase 2 (Feature Parity): 3-4 months** - Advanced file operations: 4 weeks - Code indexing: 4 weeks - Cloud integration: 3 weeks - MCP support: 3 weeks - Testing and refinement: 2 weeks **Phase 3 (Polish): 2-3 months** - Performance optimization: 4 weeks - Multi-IDE support: 4 weeks - Documentation: 2 weeks - Beta testing: 2 weeks **Total: 8-11 months for full feature parity** ## Resource Requirements ### Team Composition - 1-2 JetBrains plugin developers (Kotlin/Java) - 1 UI developer (if building native UI) - 1 backend developer (shared logic) - 1 QA engineer (testing across IDEs) - Product manager (feature prioritization) ### Infrastructure - JetBrains marketplace account - CI/CD for plugin builds - Testing infrastructure (multiple IDE versions) - Documentation site updates ## Risks and Mitigation ### Risk 1: Maintenance Burden - **Risk**: Maintaining two separate codebases - **Mitigation**: - Maximize code sharing through packages - Shared API client libraries - Common business logic in TypeScript (can be ported) - Automated testing ### Risk 2: Feature Divergence - **Risk**: Features available in one IDE but not the other - **Mitigation**: - Clear feature roadmap - Parity tracking - Staged rollout across platforms ### Risk 3: User Confusion - **Risk**: Different experiences across IDEs - **Mitigation**: - Consistent UI/UX where possible - Clear documentation - IDE-specific guides ### Risk 4: Development Complexity - **Risk**: Learning curve for JetBrains platform - **Mitigation**: - Hire experienced JetBrains plugin developers - Start with simpler features - Leverage JetBrains documentation and community ## Code Sharing Strategy ### Shared Components 1. **API Clients** - HTTP clients for LLM providers - Authentication logic - Model definitions 2. **Type Definitions** - Convert TypeScript types to Kotlin data classes - Shared JSON schemas 3. **Business Logic** - Prompt engineering - Response parsing - Error handling 4. **Configuration** - Provider settings schemas - Model configurations ### Implementation Approach ``` roo-code/ ├── packages/ │ ├── core/ # Shared business logic (TypeScript) │ ├── types/ # Shared type definitions │ └── api-clients/ # Provider API clients ├── vscode-extension/ # Current VS Code extension └── jetbrains-plugin/ # New JetBrains plugin ├── src/main/kotlin/ # Kotlin implementation └── src/main/resources/ ``` ## Alternative: Web-Based Solution ### Roo Code Desktop App Instead of IDE plugins, create a standalone desktop application. #### Pros - Single codebase - Works with any IDE - Easier maintenance #### Cons - Not integrated into IDE - Separate window context - Less seamless workflow This could be a future option but doesn't address the core request for native IDE integration. ## Recommendations 1. **Validate Demand**: Survey users to gauge interest and prioritize features - Create GitHub discussion - Discord/Reddit polls - Understand willingness to adopt 2. **Start with Design Prototype**: Before full implementation - UI mockups for JetBrains plugin - User flow diagrams - Technical proof of concept 3. **Phased Approach**: Don't aim for feature parity immediately - Start with core features users care about most (custom models) - Iterate based on feedback - Add advanced features incrementally 4. **Consider Strategic Partnership** - Engage with JetBrains - Potentially official partnership - Marketplace promotion 5. **Open Source Collaboration** - Community contributions - Plugin architecture allows experimentation - Early adopter testing ## Success Criteria ### MVP Success (Phase 1) - [ ] Plugin installable from JetBrains Marketplace - [ ] Custom model configuration working - [ ] Basic chat interface functional - [ ] File editing capabilities - [ ] 100+ active users within first month ### Feature Parity Success (Phase 2) - [ ] 80%+ feature parity with VS Code extension - [ ] Cloud sync working across IDEs - [ ] 1000+ active users - [ ] <5% crash rate ### Long-term Success (Phase 3) - [ ] All major features available - [ ] Support for IntelliJ, WebStorm, PyCharm - [ ] 10,000+ active users - [ ] 4+ star rating on JetBrains Marketplace - [ ] Sustainable maintenance model ## Next Steps 1. **Community Feedback** (Week 1-2) - Share this document with issue reporter - Gather additional requirements - Validate assumptions 2. **Technical Spike** (Week 3-4) - Create minimal JetBrains plugin prototype - Test JCEF embedding - Validate architecture decisions 3. **Go/No-Go Decision** (Week 5) - Review prototype results - Assess resource availability - Decide on timeline 4. **Kickoff** (Week 6+) - Assemble team - Set up project structure - Begin Phase 1 development ## Conclusion Building JetBrains plugin support for Roo Code is technically feasible but requires significant investment. The recommended approach is a native plugin with a hybrid UI strategy, developed in phases over 8-11 months. Key considerations: - **User Demand**: Validate that sufficient users want this - **Resource Commitment**: Requires dedicated team - **Maintenance**: Ongoing cost of supporting multiple platforms - **Strategic Value**: Expands market, especially for Java developers The custom model integration feature, which is the highest priority for the requesting user, can be delivered in Phase 1 (MVP), providing value quickly. **Recommendation**: Proceed with community validation and technical spike before committing to full development. --- **Document Status**: Draft for Community Review **Related Issue**: [#9982](https://github.com/RooCodeInc/Roo-Code/issues/9982) **Author**: Roomote **Date**: 2025-12-12 **Version**: 1.0