Forum Topic Proposal: Plugin Discoverability and Management via Joplin CLI
Title
Feature Request: Plugin Discovery and Management Commands for Joplin CLI
Category
Plugins
Tags
feature-request, cli, plugins, agent-access
Summary
I propose adding plugin discovery and management capabilities to the Joplin CLI application to enable automated agents and power users to search, install, and manage plugins programmatically. This would be particularly valuable for AI agents, automation scripts, and headless deployments that need to extend Joplin's functionality through plugins.
Use Case: Agent Access to Joplin
My specific use case involves providing AI agents with programmatic access to Joplin via the CLI. Agents need to:
- Discover available plugins to understand what functionality can be added
- Install specific plugins (e.g., backlinks, data export, formatting tools)
- List installed plugins and their status
- Configure plugins programmatically
- Update or remove plugins as needed
Currently, this is impossible because "plugins are not supported on the CLI app at the moment" 1 .
Current State
The CLI application has plugin infrastructure internally but it's only used for testing purposes 2 . Additionally, the CLI and desktop applications use different configuration directories (~/.config/joplin vs ~/.config/joplin-desktop), so plugins installed via desktop don't appear in CLI 3 .
Proposed Implementation
1. Plugin Discovery Commands
# Search available plugins
joplin plugin search <query>
joplin plugin list --available
# Get plugin details
joplin plugin info <plugin-id>
2. Plugin Management Commands
# Install plugins
joplin plugin install <plugin-id>
joplin plugin install-from-file <path-to-jpl>
# Manage installed plugins
joplin plugin list
joplin plugin enable <plugin-id>
joplin plugin disable <plugin-id>
joplin plugin uninstall <plugin-id>
# Update plugins
joplin plugin update <plugin-id>
joplin plugin update-all
3. Plugin Configuration
# View and modify plugin settings
joplin plugin config <plugin-id>
joplin plugin config <plugin-id> --set <key>=<value>
Technical Considerations
Existing Infrastructure to Leverage
-
Plugin Repository CLI: There's already a
plugin-repo-clipackage that handles plugin repository operations 4 . This could be adapted or integrated. -
PluginService Class: The CLI already has a
PluginServiceclass with install/uninstall methods 2 that could be exposed to end users. -
Plugin Architecture: The plugin system architecture supports multiple platforms 5 , so extending it to CLI should be feasible.
Configuration Directory Considerations
We need to address the configuration directory separation. Options include:
- Use the same directory as desktop (
~/.config/joplin-desktop) - Add a config option to specify plugin directory
- Create a shared plugin directory that both can access
Benefits
- Agent Enablement: Allows AI agents to programmatically extend Joplin functionality
- Automation: Enables scripting and CI/CD workflows with plugins
- Headless Deployments: Supports server deployments without GUI
- Developer Experience: Improves workflow for CLI-first developers
- Consistency: Aligns CLI capabilities with desktop/mobile applications
Questions for Community
- Should CLI plugins be stored separately from desktop plugins or shared?
- Which plugin APIs should be prioritized for CLI compatibility?
- Should there be a "CLI-compatible" flag in plugin manifests?
- How should plugin dependencies be handled in CLI context?
- Should we support all plugin types or focus on specific categories (e.g., data processing, export/import)?
Implementation Priority
- Phase 1: Basic plugin listing and installation from repository
- Phase 2: Plugin configuration and status management
- Phase 3: Advanced features like dependency resolution and updates
References
- Current plugin architecture documentation 5
- Plugin development guide 6
- Existing plugin repository management tools 7
Would love to hear thoughts from the community, especially from:
- Plugin developers about CLI compatibility
- Users with automation needs
- The core development team about feasibility
What do you think? Is this a valuable direction for Joplin's CLI development?