MJS is designed for extensibility via a (planned) plugin/module system. This guide describes the architecture, how to create plugins, and best practices.
Plugins allow you to:
- Add new API endpoints
- Extend or override UI components
- Hook into workflow events (submission, review, publication, etc.)
- Integrate with external services (analytics, payment, etc.)
- Plugins are loaded at runtime and registered via a manifest file.
- Each plugin can declare dependencies, configuration, and hooks.
- Plugins can be enabled/disabled per deployment.
- Scaffold a new plugin directory (e.g.,
plugins/my-plugin/). - Add a
plugin.jsonmanifest with metadata, entry points, and dependencies. - Implement your plugin logic in TypeScript (frontend), Rust (backend), or Python (AI service), depending on the extension point.
- Register hooks or UI components as needed.
- Add tests and documentation.
- Install: Place plugin in the
plugins/directory and register in the config. - Enable: Activate via admin UI or config file.
- Upgrade: Update plugin code and manifest; run migrations if needed.
- Disable/Remove: Deactivate and remove files; clean up data if necessary.
Plugins can subscribe to system events, such as:
- Submission created/updated
- Review assigned/completed
- User registered/logged in
- Article published
See ARCHITECTURE.md for extensibility details and planned hook/event APIs.
- Keep plugins modular and focused on a single responsibility.
- Document all public APIs and configuration options.
- Write tests for plugin logic.
- Follow security best practices (see SECURITY.md).
- Contribute your plugin to the community if it may be broadly useful!
See ROADMAP.md for planned plugin system milestones and API stability guarantees.