Modular architecture

[vgpastor]

Hello!!

Many of us regularly develop using other IDEs and not just Visual Studio Code, I personally have moved to this IDE in several projects to be able to test and take advantage of this great plugin. An example of this request are in #1242 #581 #63

After analyzing it carefully, I think it would be necessary to make an effort to modify the project architecture so that this plugin can be available in multiple IDEs.

I propose a much more modular architecture, which would also allow to test each part individually and a faster development in multiplatform environments

cline/
├── packages/
│ ├── core/ # Core functionality in TypeScript
│ │ ├── src/
│ │ │ ├── ai/ # Integrations with AI (OpenAI, Anthropic, etc.)
│ │ │ ├── browser/ # Browser management
│ │ │ ├── commands/ # Core commands
│ │ │ ├── mcp/ # MCP protocol
│ │ │ └── utils/ # Shared Utilities
│ │ └── package.json
│ │
│ ├── ui/ # Shared UI in React
│ │ ├── src/
│ │ │ ├── components/ # Reusable React Components
│ │ │ └── themes/ # Shared Themes
│ │ └── package.json
│ │
│ └── shared/ # Shared Types and Utilities
│ ├── src/
│ │ ├── types/ # TypeScript types/interfaces
│ │ └── constants/ # Shared constants
│ └── package.json
│
├── ide-integrations/
│ ├── vscode/ # VSCode integration
│ │ ├── src/
│ │ │ ├── extension.ts # VSCode-specific entry point
│ │ │ └── adapters/ # VSCode-specific adapters
│ │ └── package.json
│ │
│ └── intellij/ # IntelliJ integration
│ ├── src/
│ │ ├── main/java/ # Java/Kotlin code for IntelliJ
│ │ └── main/resources/ # IntelliJ resources
│ └── build.gradle.kts
│
└── package.json # Root package.json for managing workspaces

This structure:

• Keeps the core in TypeScript/JavaScript but isolates it in its own package
• Separates the UI into a shared package that can be used by both IDEs
• Uses a shared package for common types and utilities
• Has IDE-specific integrations that:
• For VSCode: Use TypeScript directly
• For IntelliJ: Use Java/Kotlin but consume core JS through a bridge

Benefits:

• Core code is kept in JS/TS but is decoupled from IDEs
• The UI is shared and reusable, but it can be part of the IDE if we prefer styles natives
• Each IDE can implement its specific adapters
• Facilitates maintenance and testing of each component separately
• Allows adding support for new IDEs without modifying the core

Communication between the JS core and IntelliJ's Java integration can be done through:

• Java Nashorn/GraalJS to run the JS core directly in the JVM
• WebSocket for client-server communication
• An HTTP bridge between the Java plugin and the JS core

[LivioGama]

Did you try this prompt in Cline to build the JetBrains plugin?