proposal: 收敛 cherry-markdown 编辑器定位并按职责拆分能力包 #1862

最终结论

Cherry Markdown 的能力应按“用户场景和职责”拆分，而不是按当前源码目录或构建产物名称直接拆包。

核心定位：

cherry-markdown 负责编辑器；Engine 负责解析；Preview 负责纯展示；Stream 负责流式渲染；Milkdown 作为第一阶段的独立所见即所得实验；最终架构中不保留 Core 概念、Core 包或 Core 构建入口。

目标包规划

第一阶段不创建 @cherry-markdown/editor，因为 cherry-markdown 本身就是编辑器包。

正确依赖关系

以下箭头表示“依赖”：

cherry-markdown ──→ @cherry-markdown/preview ──→ @cherry-markdown/engine
        │
        └──────────────→ @cherry-markdown/engine

@cherry-markdown/stream ──→ @cherry-markdown/preview ──→ @cherry-markdown/engine

@cherry-markdown/milkdown ──→ Milkdown
                         └──→ @cherry-markdown/engine

@cherry-markdown/milkdown 只代表第一阶段的具体实现。暂不创建抽象的 @cherry-markdown/wysiwyg，避免过早承诺通用 WYSIWYG API。

数据和运行时边界

Markdown 仍然是唯一的持久化数据格式：

Markdown
  ↔ Milkdown 文档模型 / CodeMirror
  → @cherry-markdown/engine
  → HTML
  → @cherry-markdown/preview

• Milkdown 负责编辑交互，不改变 Cherry 的 Markdown 语义；
• Engine 是最终 Markdown 解析和 HTML 输出标准；
• 所见即所得通过 EditorAdapter 隔离，未来可以替换 Milkdown；
• 无法编辑的 Cherry 专有语法必须明确保留、降级或暂不支持，不能静默丢失。

Core 的最终处理

Core 不作为未来架构的一部分：

• 不新增 @cherry-markdown/core；
• 不保留 cherry-markdown.core.* 作为 1.x 的兼容构建入口；
• 不以 src/core 作为 Engine 的长期架构概念；
• 原有 Hook、SyntaxBase、HookCenter、Markdown Hooks 等逻辑迁移到 Engine 的明确模块中；
• MenuHookBase、工具栏和编辑器交互归入 cherry-markdown。

允许在 0.x 迁移期间临时保留旧 Core 入口用于迁移和验证，但必须在 1.0.0 前删除。1.x 不再新增 Core 兼容层，也不再围绕 Core 维护额外产物。

所见即所得

第一阶段建立 @cherry-markdown/milkdown，但不立即替换 CodeMirror，也不进入根包默认依赖。

第一阶段重点验证：

• Markdown round-trip；
• 中文 IME；
• Selection、撤销重做和粘贴；
• 表格、列表、代码块和图片；
• Cherry 专有语法的保留或明确降级；
• 与 Engine 输出结果的一致性；
• 包体积、性能和可替换性。

规则冻结

@cherry-markdown/engine-compat 不属于第一阶段必需包。

@cherry-markdown/engine 在 1.x 进入稳定规则线：不进行破坏性解析、API 和输出结构调整，只接受向后兼容的功能、修复和必要的安全更新。

如果未来仍有“永远固定输出”的强需求，再基于稳定版本独立发布 engine-compat。它不能跟随最新 Engine 自动升级。

不兼容策略和 1.x 稳定性

• 0.x 阶段完成分包、入口调整和 Core 删除；
• 1.0.0 发布最终包边界和公开 API；
• 1.x 不再进行大的架构调整；
• 1.x 只接受向后兼容的 API、解析规则、输出和依赖变化；
• 如果未来必须破坏 Engine 语义或公开 API，进入 2.0.0；
• 旧 0.x 用户通过迁移说明升级，不承诺永久兼容旧 Core 入口。

发版和治理

• 各包独立版本、独立发布；
• 使用 Changesets 管理包间依赖；
• Engine 规则变化必须有 fixture / snapshot；
• 发布包必须进行真实独立安装和产物依赖检查；
• CI 检查各包不携带不应包含的依赖；
• Mermaid、ECharts、PlantUML 等大型能力后续按插件拆分。

推荐顺序

1. 在 0.x 阶段明确包边界并完成 Core 迁移；
2. 抽出 @cherry-markdown/engine；
3. 抽出 @cherry-markdown/preview 和 @cherry-markdown/stream；
4. 同期建立 @cherry-markdown/milkdown，完成所见即所得验证；
5. 删除 Core 入口和 Core 架构概念；
6. 发布 1.0.0，冻结主要包边界和公开 API；
7. 根据实际需求决定是否发布 engine-compat 和独立插件包。

需要作者确认

1. 是否认可 cherry-markdown 收敛为编辑器包？
2. 是否认可在 0.x 完成 Core 删除，并让 1.x 进入稳定架构？
3. 是否认可 Engine、Preview、Stream 独立演进？
4. 是否同意第一阶段引入独立的 @cherry-markdown/milkdown？
5. 是否接受未来破坏性 Engine 变化进入新的 major 版本？