[P2] Add Plugin / Snippet extension system

[sajeetharan]

Feature Request

Priority: P2 (Medium)

Description

CosmosDB Shell has no extension/plugin mechanism for community-contributed commands. A snippet or plugin system would allow the community to build and share reusable shell extensions.

Comparable Features in Other Shells

• mongosh: Snippet system with snippet install, community registry, autoload

Proposed Behavior

Add a plugin/extension system:

• plugin install <name> — Install a plugin from a registry
• plugin list — List installed plugins
• plugin remove <name> — Uninstall a plugin
• Support loading .csh scripts from a plugins directory at startup
• Support a community registry (e.g., GitHub-based or NuGet-based)

Example Usage

plugin install cosmosdb-data-generator
plugin install cosmosdb-migration-helpers
plugin list
plugin remove cosmosdb-data-generator

[mkrueger]

It's an open source project - we should allow 3rd party PRs so everyone profits from new features/commands.

Extending features can be done basically by running scripts. But yeah I understand the request but I would like to see some ideas/feaadback for that. This ususally makes sense for projects with lots of users that want different tastes of how to do/present things.

Let's say an IDE to show errors - some like inline errors - some prefer squiqqles etc. so plugins make sense so people can switch their flavor.

[KhushviB]

Hi @sajeetharan, @mkrueger. I'd love to work on this. Before I start, could you give some guidance on the preferred architecture? Specifically whether you'd like the plugin system to be file-based (.csh scripts) or something more structured, and if there's an existing part of the codebase I should model it after. Happy to start with a minimal MVP if that helps.

[mkrueger]

Basically I don't think it makes sense in any form atm. - I said it above.

There are scripts and as open source project we take contributions. For plugins there needs to be user demand or a very good use case.

Let's say a feature that can be solved by 2 different approaches that have no good merge/3rd way of doing that. Since we support scripting extending functionality is built-in. A plugin would add another command.

If a command is missing I vote for just adding this.

[KhushviB]

Reading both perspectives here, I think the core question is whether the problem is extensibility or discoverability.

@mkrueger is right that scripting already solves extensibility, you can run .csh scripts and extend functionality today. A plugin system on top of that is redundant if it just adds commands.

But I think @sajeetharan's issue is specifically about discoverability and sharing, how does one CosmosDBShell user share a useful script with the broader community without everyone having to find it manually? That's the gap mongosh's snippet system actually solves... not extensibility, but a curated registry where the community can publish and consume reusable scripts with one command.

So the question isn't really "plugin system vs scripting", it's "do we want a way for the community to share scripts easily?"

If the answer is yes, the implementation is actually simpler than a full plugin system, a snippet install <github-url> that downloads and places a .csh script in the plugins directory would solve the discoverability problem without needing a registry, package manager, or new command architecture.

@sajeetharan does that match what you had in mind? If so I can start with that minimal scope.