Preliminary Work for Roo Code to Support JetBrains and CLI

[qdaxb]

Currently, the Roo Code project is only a VS Code extension and is tightly coupled with the VS Code platform. Some collaborators and I are exploring the possibility of expanding Roo Code to support the JetBrains platform or even run as a standalone CLI component.

You can refer to how Continue handles this:

• https://github.com/continuedev/continue/blob/main/core/index.d.ts
• https://github.com/continuedev/continue/tree/main/core/protocol/messenger
• https://github.com/continuedev/continue/blob/main/gui/src/context/IdeMessenger.ts

To move in this direction, a few tasks are required:

1. Refactor the project structure: keep webview-ui and src, and add a plugins/ directory.
2. Move the current VS Code extension's packaging logic and extension.ts into plugins/vscode. Dependencies from extension.ts should point to the root src directory. The existing packaging scripts should also be migrated into a new script under plugins/vscode.
3. Create a new IIDE interface to abstract differences between VS Code and other platforms. Replace all direct VS Code dependencies in the codebase with dependencies on the IIDE interface, and implement VSCodeIDE extends IIDE. (This will be a large amount of work.)
4. Add implementations for plugins/jetbrains or plugins/cli.

I believe this would be a major change, but every big change needs a starting point.
I think it's a good time to start a discussion around this.

[adamhill]

How does it handle the Kotlin / TS bridging back and forth?

[qdaxb]

flowchart TD
    JB_IDE --> JB_Plugin
    JB_Plugin --> WebView
    JB_Plugin <-->|IPC| NodeService
    WebView --> | injected JS function | JB_Plugin
    WebView <-.-> |bridged by JB_Plugin| NodeService

Loading

[MoonIRL]

它如何处理 Kotlin / TS 之间的来回桥接？

To support IntelliJ in a VSCode plugin and bridge communication between Kotlin and TypeScript (TS), follow these steps for design and implementation:

---

1. Architecture Design

• Decouple Core Logic from IDE Adaptation Layers:

  • Encapsulate core business logic (e.g., code analysis, data processing) into standalone modules.
  • Implement IDE-specific adaptation layers for VSCode (TS) and IntelliJ (Kotlin) to handle API calls and event listeners.

• Communication Mechanisms:

  • Inter-Process Communication (IPC): Use subprocesses or local sockets for cross-language calls.
  • WebSocket/HTTP Services: Deploy core logic as a local service, with TS and Kotlin communicating via HTTP/WebSocket.
  • Shared Files/Message Queues: Use filesystems or message queues (e.g., ZeroMQ) for asynchronous data exchange.

---

2. Implementation Steps

2.1 Define Unified Interfaces and Data Formats

• Use Protobuf/JSON Schema:

  // example.proto
  message Request {
    string command = 1;
    bytes data = 2;
  }
  
  message Response {
    bool success = 1;
    string result = 2;
  }

• Generate data models for TS and Kotlin:
  • TS: protoc --ts_out=. example.proto
  • Kotlin: Use kotlinx-serialization or protobuf-gradle-plugin.

2.2 Implement Communication Layer

• Kotlin (IntelliJ Plugin):

  // Start a local service (e.g., Ktor)
  embeddedServer(Netty, port=8080) {
      routing {
          post("/api") {
              val request = parseRequest(call.receiveText())
              val result = processCoreLogic(request)
              call.respond(Json.encodeToString(Response(result)))
          }
      }
  }.start()

• TypeScript (VSCode Plugin):

  // Call Kotlin service
  import axios from 'axios';
  
  async function callKotlinService(command: string, data: any) {
      const response = await axios.post('http://localhost:8080/api', {
          command,
          data: JSON.stringify(data)
      });
      return response.data.result;
  }

2.3 Reuse Core Logic

• Option 1: Kotlin Multiplatform (KMP):

  • Write core logic in Kotlin and compile it to JS for TS.
  • build.gradle.kts:

    kotlin {
        js(IR) { // Compile to JS
            browser()
        }
        jvm { // Compile to JVM (IntelliJ) }
    }

  • Use the JS module in TS:

    import { coreFunction } from './kotlin-core';
    const result = coreFunction(data);

• Option 2: Shared RPC Service:

  • Deploy core logic as a standalone process/microservice, accessible via gRPC/HTTP.

---

3. IDE Adaptation Layers

• VSCode (TS):

  // Register command to call Kotlin service
  vscode.commands.registerCommand('extension.action', async () => {
      const result = await callKotlinService('analyze', { code: getActiveCode() });
      vscode.window.showInformationMessage(result);
  });

• IntelliJ (Kotlin):

  // Handle IDE events and call services
  class MyToolWindow : ToolWindow {
      init {
          val btn = JButton("Run")
          btn.addActionListener {
              val request = buildRequest(project)
              val result = callTypeScriptService(request)
              showResult(result)
          }
      }
  }

---

4. Build and Debugging

• Monorepo Structure:

  my-plugin/
  ├── core/           # Shared logic (KMP/RPC definitions)
  ├── vscode-extension/ # TS code, depends on core JS
  ├── intellij-extension/ # Kotlin code, depends on core JVM
  └── build.gradle.kts  # Unified build config
  

• Debugging:

  • Use launch.json (VSCode) and runIde (IntelliJ) for debugging.
  • Debug JS/TS with --inspect-brk.

---

5. Edge Cases

• Type Conversions:
  • Ensure compatibility with kotlinx-serialization (Kotlin) and class-transformer (TS).
• Async Handling:
  • Use async/await in TS and Kotlin coroutines (suspend functions).
• Error Handling:

  try {
      await callKotlinService(...);
  } catch (e) {
      vscode.window.showErrorMessage(`Bridge error: ${e.message}`);
  }

---

6. Alternatives

• Language Server Protocol (LSP):
  • Implement an LSP server in Kotlin, shared by VSCode and IntelliJ.
  • Integrate via vscode-languageclient (VSCode) and LSP4J (IntelliJ).

---

Summary

By defining a clear communication protocol (e.g., Protobuf), reusing core logic (via KMP or standalone services), and implementing lightweight IDE adapters, you can bridge Kotlin and TS effectively. Prioritize IPC or LSP-based architectures to reduce cross-IDE maintenance costs.

[adamhill]

I mean, what form does the bridge take? Is there an npm package that provides a relay already? Does JB have one in their Plugin SDK? (I haven't read through their docs yet) Or are we gonna have to write that from scratch?

I was looking for a code example. Is there some other JB plugin already doing this with source code we can look at? I want to see how hard / slow / fast / ergonomic calling through the APIs give all the changes that will have to take place.

Something as simple as a POC instantiating the extension pane on the side of a JB IDE, a moving it to other side, popping it out as a floating window and adding a single file to the context to the chat.

I am jazzed about a JB plugin!

Thanks.

[qdaxb]

Refer to https://github.com/continuedev/continue/tree/main

JB_Plugin bridge:
https://github.com/continuedev/continue/blob/main/extensions/intellij/src/main/kotlin/com/github/continuedev/continueintellijextension/continue/CoreMessenger.kt
https://github.com/continuedev/continue/blob/main/extensions/intellij/src/main/kotlin/com/github/continuedev/continueintellijextension/continue/IdeProtocolClient.kt

webview <-> JB_Plugin
https://github.com/continuedev/continue/blob/16041102c306bb69c572349a3d6aee263b99e035/extensions/intellij/src/main/kotlin/com/github/continuedev/continueintellijextension/toolWindow/ContinueBrowser.kt#L106

JB_Plugin <-> NodeService(IPC)
https://github.com/continuedev/continue/blob/16041102c306bb69c572349a3d6aee263b99e035/binary/src/IpcMessenger.ts#L206

[navkast]

Here is cline's discussion on this matter, which seems progressing: cline#581