Plate Slate v2 硬切割slate-markdown 与 slate-table 包的去留决策与能力归属重构【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本文围绕 Plate 仓库中 Slate v2 重写的一条关键决策记录展开将slate-markdown与slate-table两个原始 Slate 包从 Slate 侧彻底移除把 Markdown 语法策略与表格功能策略重新划归到 Plate 或应用/示例代码层。读完本文你可以理解这次硬切割Hard Cut背后的架构动机、四项具体决策、进度与验证命令以及当前仓库中 Markdown/表格能力实际落位的包结构从而掌握 Slate无主见的底层内核与 Plate有主见的功能层之间的边界划分方法。背景为什么要对 Markdown 与表格包做硬切割Slate v2 是 Plate 团队对 Slate 内核的一次重写仓库docs/plans/目录下存在大量以slate-v2命名的规划文档如 Slate v2 相关规划。在重写过程中团队面临一个典型的分层问题Markdown 的解析/序列化规则、表格的行为策略GFM 表格、单元格选择 UX本质上属于产品化、有主见的能力而 Slate 的定位是一个无主见unopinionated的富文本内核。决策文档 Slate v2 Markdown/Table Package Hard Cut 给出的目标非常明确Remove raw Slateslate-markdownandslate-tablepackage surfaces. Markdown syntax policy and table feature policy belong in Plate or app/example code, not in unopinionated Slate.即从原始 Slate 中移除slate-markdown和slate-table的包表面package surface因为 Markdown 语法策略和表格功能策略应属于 Plate 或应用/示例代码而不属于无主见的 Slate。从源码结构看这类能力下沉/上移的边界判断在内核重写中是反复出现的主题——仓库docs/plans/下围绕 Slate v2 的包命名规范化、roadmap 收束、包表面回收如slate-v2-roadmap-package-name-normalization、slate-v2-instance-surface-recovery等系列规划都在做同一件事把内核的 API 表面收敛到纯基础设施。四项核心决策决策文档的Decisions一节列出了四条边界规则它们共同定义了切割后各方的职责原始 Slate 只保留基座 APIsubstrate APIsschema、transforms、selections、normalization、clipboard/input hooks以及 layout 原语。这些是数据模型 DOM 桥接 操作层面的通用能力与具体产品特性无关。Plate 拥有 Markdown 能力包parse / serialize / input-rule 包全部归属 Plate。Plate 拥有表格能力table maps、commands、cell-selection UX 与 GFM 表格行为归 Plate 所有。Slate 示例可以保留本地 fixture示例代码中允许保留本地测试数据来证明通用基座行为但不依赖被移除的包。slate-layout必须消费应用侧提供的通用几何信息对表格类内容的布局计算slate-layout不得再依赖原始 Slate 的 table 包而是消费由应用提供的通用几何数据。第 4、5 条尤其值得注意它们不是简单的删包而是回答了删完之后谁消费这些几何/布局数据的问题——布局层退化为对应用侧几何信息的消费方这是典型的内核去业务化手法内核不假设存在表格布局层通过通用接口拿到表格所需的行列几何。当前仓库状态印证能力落位在哪里本决策是在 Slate v2 重写分支验证命令运行于.tmp/slate-v2临时检出见下文验证一节中执行的。当前主仓库的包结构正好呈现了切割后的稳态结果内核侧packages/slateplatejs/slate 的包入口 packages/slate/src/index.ts 的导出结构与文档所述基座 API完全对应export * from ./create-editor; export * from ./slate-dom; export * from ./types; export * from ./interfaces/index; export * from ./slate-history/index; export * from ./utils/index;从源码结构看interfaces类型契约、slate-domDOM 桥接、slate-history撤销/重做、utils路径、选区等工具构成了决策中提到的 schema/transforms/selections/normalization 等基座能力的载体其中不含任何 Markdown 或表格专属模块。其 package.json 也印证了薄内核定位运行时依赖仅为slate0.126.2、slate-dom0.126.0、lodash等版本号为 53.3.10。功能侧packages/markdownplatejs/markdownMarkdown serializer plugin for Platev53.3.12正是决策中Plate owns Markdown parse/serialize/input-rule packages的落地位置。其依赖清单直接反映了 Plate 侧 Markdown 能力的技术栈选型remark-parse/remark-stringify/unifiedCommonMark 解析与序列化管线marked^15.0.12轻量解析路径remark-mdx/mdast-util-mdx/mdast-util-mathMDX 与数学扩展unist-util-visitAST 遍历。更关键的是测试文件本身就证明GFM 表格行为在 Plate 侧被验证packages/markdown/src/lib/table.spec.ts 与同目录下的gfmSurface.spec.ts、commonmarkSurface.spec.ts、taskList.spec.ts等按表面surface组织的规格测试覆盖了 GFM 表格在 Markdown 解析/序列化链路中的行为。也就是说表格的语法策略如何解析/产出 GFM 表格 Markdown确实留在了 Plate 的 Markdown 包内与决策一致。功能侧packages/tableplatejs/tableTable plugin for Platev53.0.9承载决策中Plate owns table maps, commands, cell-selection UX的运行时能力它同时暴露核心入口.与 React 入口./react并依赖platejs/resizable提供表格相关的交互增强。表格的 maps数据结构映射、命令与单元格选择 UX 由此独立于 Slate 内核存在。切割结果确认slate-markdown/slate-table不在仓库中当前仓库packages/目录下的包清单中不存在slate-markdown与slate-table与决策文档 Progress 中Deletepackages/slate-markdown/ Deletepackages/slate-table的勾选结果一致。需要注意的适用前提是这两次删除与验证都发生在 Slate v2 重写的工作线.tmp/slate-v2检出上主仓库plate-2工作区自始以 Plate 包platejs/markdown、platejs/table作为这些能力的载体。进度清单Progress决策文档将执行过程记录为逐项勾选的清单全部完成Confirm package surfaces exist确认两个包表面确实存在Deletepackages/slate-markdownDeletepackages/slate-tableRemove TypeScript/workspace references清理 TS 与 workspace 引用Rewrite docs and plan references重写相关文档与规划引用Run focused verification执行聚焦验证其中Remove TypeScript/workspace references一步在多包工作区中尤为关键删除包目录本身只完成一半还必须同步清理tsconfig的 references 与 workspace 成员声明否则类型检查与构建会残留对已删包的引用。验证命令与结果Verification决策文档记录了聚焦验证的命令与环境这里完整继承并补充执行环境说明命令执行环境结果bun typecheck:packages.tmp/slate-v2Slate v2 重写检出通过bun typecheck:root.tmp/slate-v2通过bun lint:fix.tmp/slate-v2通过无修改bun test:bun.tmp/slate-v2通过1157 pass / 95 skippnpm lint:fixplate-2主工作区通过无修改验证策略体现了一个跨仓库切分项目的典型做法删除动作发生在 Slate v2 检出因此类型检查、lint 与全量 Bun 测试1157 通过、95 跳过都在.tmp/slate-v2中执行同时用pnpm lint:fix在主工作区plate-2做一次无副作用的 lint 确认确保主仓库引用未受牵连。lint:fix报告no fixes applied是删除类变更的强信号——说明没有遗留的未使用导入或格式残骸需要自动修复。小结内核去业务化的三条可复用经验结合本文档与当前仓库的包结构这次硬切割给出了三条对内核/功能分层项目都有参考价值的经验策略与基座分离语法策略Markdown 规则、GFM 表格行为与产品 UX单元格选择上移到功能层packages/markdown、packages/table内核packages/slate只保留 schema、transforms、selections、normalization 等通用基座。删除要删透包目录、TS/workspace 引用、文档引用三类位置全部清理并以全仓 typecheck lint 测试套件作为验收门槛。为删掉之后指定消费者slate-layout通过消费应用侧提供的通用几何信息替代对 table 包的依赖避免布局原语重新耦合回业务数据结构。相关深入材料可参考 决策原文、内核包 packages/slate/README.md 以及仓库docs/plans/下其他 Slate v2 系列规划文档。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Plate Slate v2 硬切割：slate-markdown 与 slate-table 包的去留决策与能力归属重构
Plate Slate v2 硬切割slate-markdown 与 slate-table 包的去留决策与能力归属重构【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本文围绕 Plate 仓库中 Slate v2 重写的一条关键决策记录展开将slate-markdown与slate-table两个原始 Slate 包从 Slate 侧彻底移除把 Markdown 语法策略与表格功能策略重新划归到 Plate 或应用/示例代码层。读完本文你可以理解这次硬切割Hard Cut背后的架构动机、四项具体决策、进度与验证命令以及当前仓库中 Markdown/表格能力实际落位的包结构从而掌握 Slate无主见的底层内核与 Plate有主见的功能层之间的边界划分方法。背景为什么要对 Markdown 与表格包做硬切割Slate v2 是 Plate 团队对 Slate 内核的一次重写仓库docs/plans/目录下存在大量以slate-v2命名的规划文档如 Slate v2 相关规划。在重写过程中团队面临一个典型的分层问题Markdown 的解析/序列化规则、表格的行为策略GFM 表格、单元格选择 UX本质上属于产品化、有主见的能力而 Slate 的定位是一个无主见unopinionated的富文本内核。决策文档 Slate v2 Markdown/Table Package Hard Cut 给出的目标非常明确Remove raw Slateslate-markdownandslate-tablepackage surfaces. Markdown syntax policy and table feature policy belong in Plate or app/example code, not in unopinionated Slate.即从原始 Slate 中移除slate-markdown和slate-table的包表面package surface因为 Markdown 语法策略和表格功能策略应属于 Plate 或应用/示例代码而不属于无主见的 Slate。从源码结构看这类能力下沉/上移的边界判断在内核重写中是反复出现的主题——仓库docs/plans/下围绕 Slate v2 的包命名规范化、roadmap 收束、包表面回收如slate-v2-roadmap-package-name-normalization、slate-v2-instance-surface-recovery等系列规划都在做同一件事把内核的 API 表面收敛到纯基础设施。四项核心决策决策文档的Decisions一节列出了四条边界规则它们共同定义了切割后各方的职责原始 Slate 只保留基座 APIsubstrate APIsschema、transforms、selections、normalization、clipboard/input hooks以及 layout 原语。这些是数据模型 DOM 桥接 操作层面的通用能力与具体产品特性无关。Plate 拥有 Markdown 能力包parse / serialize / input-rule 包全部归属 Plate。Plate 拥有表格能力table maps、commands、cell-selection UX 与 GFM 表格行为归 Plate 所有。Slate 示例可以保留本地 fixture示例代码中允许保留本地测试数据来证明通用基座行为但不依赖被移除的包。slate-layout必须消费应用侧提供的通用几何信息对表格类内容的布局计算slate-layout不得再依赖原始 Slate 的 table 包而是消费由应用提供的通用几何数据。第 4、5 条尤其值得注意它们不是简单的删包而是回答了删完之后谁消费这些几何/布局数据的问题——布局层退化为对应用侧几何信息的消费方这是典型的内核去业务化手法内核不假设存在表格布局层通过通用接口拿到表格所需的行列几何。当前仓库状态印证能力落位在哪里本决策是在 Slate v2 重写分支验证命令运行于.tmp/slate-v2临时检出见下文验证一节中执行的。当前主仓库的包结构正好呈现了切割后的稳态结果内核侧packages/slateplatejs/slate 的包入口 packages/slate/src/index.ts 的导出结构与文档所述基座 API完全对应export * from ./create-editor; export * from ./slate-dom; export * from ./types; export * from ./interfaces/index; export * from ./slate-history/index; export * from ./utils/index;从源码结构看interfaces类型契约、slate-domDOM 桥接、slate-history撤销/重做、utils路径、选区等工具构成了决策中提到的 schema/transforms/selections/normalization 等基座能力的载体其中不含任何 Markdown 或表格专属模块。其 package.json 也印证了薄内核定位运行时依赖仅为slate0.126.2、slate-dom0.126.0、lodash等版本号为 53.3.10。功能侧packages/markdownplatejs/markdownMarkdown serializer plugin for Platev53.3.12正是决策中Plate owns Markdown parse/serialize/input-rule packages的落地位置。其依赖清单直接反映了 Plate 侧 Markdown 能力的技术栈选型remark-parse/remark-stringify/unifiedCommonMark 解析与序列化管线marked^15.0.12轻量解析路径remark-mdx/mdast-util-mdx/mdast-util-mathMDX 与数学扩展unist-util-visitAST 遍历。更关键的是测试文件本身就证明GFM 表格行为在 Plate 侧被验证packages/markdown/src/lib/table.spec.ts 与同目录下的gfmSurface.spec.ts、commonmarkSurface.spec.ts、taskList.spec.ts等按表面surface组织的规格测试覆盖了 GFM 表格在 Markdown 解析/序列化链路中的行为。也就是说表格的语法策略如何解析/产出 GFM 表格 Markdown确实留在了 Plate 的 Markdown 包内与决策一致。功能侧packages/tableplatejs/tableTable plugin for Platev53.0.9承载决策中Plate owns table maps, commands, cell-selection UX的运行时能力它同时暴露核心入口.与 React 入口./react并依赖platejs/resizable提供表格相关的交互增强。表格的 maps数据结构映射、命令与单元格选择 UX 由此独立于 Slate 内核存在。切割结果确认slate-markdown/slate-table不在仓库中当前仓库packages/目录下的包清单中不存在slate-markdown与slate-table与决策文档 Progress 中Deletepackages/slate-markdown/ Deletepackages/slate-table的勾选结果一致。需要注意的适用前提是这两次删除与验证都发生在 Slate v2 重写的工作线.tmp/slate-v2检出上主仓库plate-2工作区自始以 Plate 包platejs/markdown、platejs/table作为这些能力的载体。进度清单Progress决策文档将执行过程记录为逐项勾选的清单全部完成Confirm package surfaces exist确认两个包表面确实存在Deletepackages/slate-markdownDeletepackages/slate-tableRemove TypeScript/workspace references清理 TS 与 workspace 引用Rewrite docs and plan references重写相关文档与规划引用Run focused verification执行聚焦验证其中Remove TypeScript/workspace references一步在多包工作区中尤为关键删除包目录本身只完成一半还必须同步清理tsconfig的 references 与 workspace 成员声明否则类型检查与构建会残留对已删包的引用。验证命令与结果Verification决策文档记录了聚焦验证的命令与环境这里完整继承并补充执行环境说明命令执行环境结果bun typecheck:packages.tmp/slate-v2Slate v2 重写检出通过bun typecheck:root.tmp/slate-v2通过bun lint:fix.tmp/slate-v2通过无修改bun test:bun.tmp/slate-v2通过1157 pass / 95 skippnpm lint:fixplate-2主工作区通过无修改验证策略体现了一个跨仓库切分项目的典型做法删除动作发生在 Slate v2 检出因此类型检查、lint 与全量 Bun 测试1157 通过、95 跳过都在.tmp/slate-v2中执行同时用pnpm lint:fix在主工作区plate-2做一次无副作用的 lint 确认确保主仓库引用未受牵连。lint:fix报告no fixes applied是删除类变更的强信号——说明没有遗留的未使用导入或格式残骸需要自动修复。小结内核去业务化的三条可复用经验结合本文档与当前仓库的包结构这次硬切割给出了三条对内核/功能分层项目都有参考价值的经验策略与基座分离语法策略Markdown 规则、GFM 表格行为与产品 UX单元格选择上移到功能层packages/markdown、packages/table内核packages/slate只保留 schema、transforms、selections、normalization 等通用基座。删除要删透包目录、TS/workspace 引用、文档引用三类位置全部清理并以全仓 typecheck lint 测试套件作为验收门槛。为删掉之后指定消费者slate-layout通过消费应用侧提供的通用几何信息替代对 table 包的依赖避免布局原语重新耦合回业务数据结构。相关深入材料可参考 决策原文、内核包 packages/slate/README.md 以及仓库docs/plans/下其他 Slate v2 系列规划文档。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
