Feature request: 插件化架构 —— 支持第三方插件开发

[skylkw]

需求

希望把 Flowix 的功能做成可插件化,支持第三方按插件的形式扩展(自定义编辑器扩展、命令、面板、AI 工具等),而不是把所有能力都编进主程序。

现状(核实结果)

目前代码里的 "plugin" 全部是编译期集成,没有面向第三方的插件系统:

• 前端所谓 plugin 都是 Tiptap / ProseMirror 编辑器扩展,直接在 app/flowix-web/features/editor/markdown-editor.tsx 里 import + 静态注册(如 extensions/markdown-link.ts、extensions/tag.ts、table/table-plugin.ts 等)。
• 后端是 Tauri 内建插件(tauri-plugin-*),同样是编译期依赖。
• 没有:插件清单(manifest)、运行时加载 / 卸载、稳定的插件 API / SDK、插件沙箱与权限模型、插件市场或本地安装目录。

即当前不具备类似 Obsidian / VS Code 那种第三方插件开发能力。

期望方向(供讨论)

一个完整的插件化会涉及不少设计决策,建议分阶段:

1. 扩展点定义:先明确对外开放哪些扩展点(编辑器节点/标记、斜杠命令、侧栏面板、状态栏项、AI 工具、命令面板动作等)。
2. 插件清单 + 加载机制:定义 manifest 格式与插件目录,支持运行时发现/启用/禁用。
3. 稳定 API/SDK:给插件暴露一套受控的前端(编辑器、store、命令)与后端(IPC 命令、文件访问)接口。
4. 安全模型:插件权限声明与沙箱(尤其涉及文件系统 / 网络 / AI provider 时),复用现有 path_scope / 白名单机制。
5. 分发:本地安装 → 后续可考虑插件市场。

这是一个较大的架构性工作,先开 issue 记录需求、收集设计意见。

收益

• 社区可自行扩展编辑器与工作流,降低主仓维护负担;
• 现有内建扩展(Tiptap 扩展、AI 工具)可逐步迁移到统一插件模型,验证 API 完备性。

[pophirasawa]

是不是可以先支持类似自定义主题那种插件化

[Fromsko]

这个提议非常好，如果有插件机制是否可以意味着 webdav 的集成，以及自动 Hook 机制整理笔记并且编译为 Wiki 分发。

[Fromsko]

但是目前 Rust 插件化，通过编译为 wasm 呢还是跨平台的 DLL | So 支持呢。看起来前端的插件化比较好做一些，楼主提出的点很好，分阶段的插件化。