Support update and delete operations in Cosmos DB plugins for other IDEs (JetBrains, Eclipse, etc.)

[sajeetharan]

Discussed in #3128

^{Originally posted by sajeetharan June 5, 2026}
The VS Code Cosmos DB extension provides a great developer experience with built-in support for update and delete operations directly from the editor. However, developers using other IDEs (JetBrains IntelliJ/Rider, Eclipse, Vim/Neovim, etc.) don't have equivalent plugins with this functionality.

The idea: Would it be feasible to extract the core CRUD logic (especially update and delete) into a shared library or language server protocol that other IDE plugins could consume? This would allow the broader developer community to benefit from the same rich data manipulation experience regardless of their preferred editor.

Why this matters:

Many teams use mixed IDE environments
Developers shouldn't need to switch to VS Code just to perform update/delete operations on their Cosmos DB data
A shared core could reduce maintenance burden across plugins
I'd love to hear from other developers:

Which IDE would you most want this support in?
Would a standalone CLI tool or LSP-based approach work for your workflow?
Are there existing community plugins for other IDEs that partially address this?

Looking forward to the community's thoughts! 🙌

[KhushviB]

Great discussion @sajeetharan ! I think the LSP-based approach makes more sense long-term, it keeps the core logic in one place and any IDE with LSP support (JetBrains, Neovim, Eclipse) can consume it without duplicating the CRUD implementation.

A standalone CLI could work as a stepping stone though easier to ship quickly and lets the community validate the need before investing in full LSP infrastructure.

For existing community plugins, I haven't seen any that cover update/delete well most stop at read operations which confirms the gap you're describing.

I'm actively looking to contribute. Would love to help prototype whichever direction you decide on.

[sevoku]

I don't think it's feasible to extract any of the extension's code as is, since it's typescript/npm and can't be consumed directly by most other editors.
LSP might be a solution, or most likely the only feasible for sharing the code, but I'm not sure if it is sufficient enough besides providing language integrations (which is probably another topic for full NoSQL query language support in 3P editors!). It might be worth experimenting with a CLI stepping stone for this scenario and https://github.com/Azure/CosmosDBShell which already has rudimentary LSP support for shell scripts (*.csh)? @mkrueger thoughts?

[sevoku]

This reminds me however: how would we approach security with LSP? And what about UI parts in the 3P Editors?

[KhushviB]

@sevoku The security and UI concerns are real but both are solvable at the protocol level.

Security: LSP runs over stdio or TCP between the editor and a local server process. Cosmos DB credentials never leave the machine, auth tokens stay scoped to the LSP server and are never exposed to the editor client. This is exactly the model DefaultAzureCredential uses for local dev auth. No new attack surface introduced.

UI in 3P editors: The answer is capability-based degradation using what LSP already provides. During the initialize handshake, the client declares its capabilities, the server adapts:

1. Full LSP UI support (JetBrains IntelliJ, modern Neovim): window/showDocument opens query results as a virtual read-only document directly in the editor buffer. No WebView required.
2. Partial LSP support (Eclipse, older plugins): window/showMessage + window/logMessage render results in the editor's LSP output panel. Less rich, fully functional.
3. Minimal LSP support: Server detects missing capabilities at handshake and directs the user to CosmosDBShell for interactive operations. Graceful degradation, not a broken experience.

The core CRUD logic in the LSP server stays identical across all three cases. CosmosDBShell isn't a competing approach it's the intentional fallback UI layer for case 3.
The architecture: one LSP server handling auth + CRUD, CosmosDBShell handling interactive UI where WebView isn't available. One core, two surfaces.

I'd like to take a shot at prototyping this if the team decides to move forward, already exploring the CosmosDBShell codebase this weekend with issue #112 in mind. Happy to start with a minimal LSP server proof of concept scoped to read/query operations first, so the approach can be validated before investing in the full CRUD surface.