Plate 项目 Next.js 构建链路去 webpack 化以 Turbopack 为主线的迁移实战【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本篇指南围绕 slate-v2 迁移项目中的一次真实工程决策展开如何在slate-v2仓库中移除强制--webpack用法并将其 Next.js 站点配置对齐到正在运行的 Plate 仓库形态使next build/next dev直接以 Turbopack 为主力通道。读完本文你将掌握去除 webpack 强制参数、清理 next.config 中的 webpack-only 分支、保留 dev 期 Turbopack 源码别名、并用构建/类型检查/静态检查/启动四道命令验证迁移的完整操作流程同时理解 Plate 仓库中对应的配置实现细节。背景与目标为什么停止强制 webpack在slate-v2迁移项目的早期阶段站点构建链路长期依赖--webpack参数强制走 webpack 打包器。这种做法的直接代价是每次构建/开发都必须显式绕过 Next 默认也是后续版本主推的 Turbopack 通道站点配置里还残留着一套只为 webpack 兼容而存在的回调分支维护成本与构建心智负担都在持续累积。本计划的 Goal 表述得非常直接见 docs/plans/2026-04-16-slate-v2-stop-webpack.mdRemove forced--webpackusage from/Users/zbeyens/git/slate-v2and align the Next setup with the working Plate repo shape.即移除slate-v2中所有强制--webpack的用法并把 Next 配置形态对齐到已经跑得通的 Plate 仓库。这里的核心方法论不是从零设计一套新构建方案而是把成熟仓库中已被验证的配置形态作为参照系做一次照抄正确形状的收敛迁移。从时间线看这次操作是 slate-v2 迁移 tranche 2React 19.2 与低风险兼容性的配套收尾tranche 2 已将站点基线升到 Next 16.2.4而 Next 16 对 webpack 回调、eslint内嵌配置等旧形态的支持已经收紧去 webpack 化正是让站点停留在被 Next 16 官方接受的形态上的必要一步详见 docs/plans/2026-04-16-slate-v2-tranche-2-execution.md 与 docs/slate-v2/master-roadmap.md。迁移范围Scope三处收口本计划把改动面明确锁定为三块避免扩散到无关模块根级站点脚本root site scripts凡是写死--webpack的 npm/pnpm 脚本都要去掉该参数site/next.config.js移除其中只为 webpack 服务的旧分支配置被迫出现的兼容性善后forced compatibility fallout任何因去掉 webpack 而导致 Next 构建变红的地方做最小幅度的兼容修复保证不引入额外语义变更。范围收敛的原则与 slate-v2 迁移一贯的repair-drift同路径源码优先、最小强制漂移一致只修被移除 webpack 直接波及的文件不做顺手重构。三阶段执行路径计划按如下三个阶段推进每阶段都有明确交付物阶段动作产出1审查 Plate 仓库的参照配置与当前 slate-v2 的 Next 站点现状差异清单哪些脚本强制 webpack、配置里哪些分支是 webpack-only2修补脚本与配置停止强制 webpack干净的脚本、干净的 next.config3验证受影响链路的 build / typecheck / lint / test全绿验证记录这种先勘察参照物 → 再动手 → 最后全链路验证的顺序保证了迁移是对齐已验证形态而不是盲改。关键发现Findings与原理拆解计划文档记录了三条核心发现每一条都值得展开理解1. Plate 直接用next build/next devTurbopack 是主力通道Plate 仓库的根脚本与站点脚本中没有--webpack构建直接调用next build开发直接调用next dev。在 apps/www/package.json 中可以看到这种直接形态build: PLATE_WWW_ASYNC_DOCS1 pnpm build:registry PLATE_WWW_ASYNC_DOCS1 next build, dev: PLATE_WWW_DYNAMIC_DOCS1 pnpm build:source:dev PLATE_WWW_DYNAMIC_DOCS1 next dev, preview: next build next start, start: next start注意这里没有任何--webpack构建/开发/预览全部交给 Next 自身选择打包器在 Next 16 中默认通道即 Turbopack。这也印证了计划中的结论Turbopack 才是应该长期维护的活跃通道active lanewebpack 只是历史遗留的强制回退。2. 显式示例导入表就位后webpack 回调已无存在必要发现二指出一旦站点内的示例模块改用了显式导入映射表explicit example importer map就不再需要 webpack 回调来兜底示例加载。这个背景在 tranche 2 计划中有更细的说明Next 16 的路由打包曾因为模板字符串动态导入把examples/ts/custom-types.d.ts拉进路由 bundle 而报错改用显式导入映射表后Next 16 不再把该声明文件当作路由模块打包问题消失见 docs/plans/2026-04-16-slate-v2-tranche-2-execution.md 的 Findings 部分。也就是说webpack 回调当初存在的部分理由是替动态导入兜底而这个理由已经被显式导入表消除webpack-only 分支自然成为死代码。3. 移除强制 webpack 后Turbopack 的 build 与 dev 都能干净启动发现三是验证性结论去掉强制 webpack 路径后Turbopack 构建与开发服务器均能正常启动没有出现依赖 webpack 回退才能工作的隐性耦合。执行进度Progress四步落地计划文档的 Progress 记录展示了实际的执行序列启动 stop-webpack 通道确认改动边界从build:next与serve脚本中移除--webpack脚本层去强制从site/next.config.js中删除旧的 webpack-only 分支配置层清残留保留 dev-only 的 Turbopack 源码别名与 Plate 参照形态对齐不是一刀切删光别名而是保留仅开发期生效的源码别名机制——这一点正是 Plate 配置的精髓详见下一节。仓库源码佐证Plate 的 next.config 长什么样当前仓库 apps/www/next.config.ts 正是计划中Plate 参照形态的落地版本可以直接对照理解dev-only Turbopack 源码别名的含义构建时通过buildWorkspaceAliases(dist)把各 workspace 包指向dist产物开发时通过buildWorkspaceAliases(src)把platejs/*、udecode/*、platejs等导入直接指向各包的src入口实现免包重构建的源码级 HMR别名只在开发期注入turbopack.resolveAliasturbopack: isDev ? { resolveAlias: buildWorkspaceDevAliases(), } : undefined,与之配套experimental.externalDir: isDev与turbopackFileSystemCacheForDev: true也只在开发期生效后者还附带一条注释说明 OOM 的根因在文档导入图而非 Turbopack 缓存本身文件的末尾整段webpack: (config, ...) {...}回调已被注释掉见 apps/www/next.config.ts 第 276–302 行其中包含shiki/typescript的 externals、浏览器端crypto/streamfallback、process的 ProvidePlugin 等——这正是计划中删除的 webpack-only 分支在 Plate 侧的对应残留形态。此外tranche 2 计划还记录了两条 Next 16 兼容性事实与去 webpack 化直接相关Next 16 不再接受next.config.js内嵌eslint配置旧配置必须移除站点 TS 面需要按 Next 16 形态调整bundler 解析、显式 React 类型、.next/types纳入这些属于forced compatibility fallout的典型清单见 docs/plans/2026-04-16-slate-v2-tranche-2-execution.md 与 docs/slate-v2/release-file-review-ledger.md。验证四道命令确认迁移无回归计划文档给出的验证矩阵均已在 Next 16.2.4 Turbopack 下通过命令验证目标pnpm build:next生产构建走 Turbopack产物可正常产出pnpm typecheck:site站点 TypeScript 面全绿pnpm lint静态检查通过pnpm serve生产服务在 Next 16.2.4 Turbopack 下干净启动这套build / typecheck / lint / serve的组合覆盖了从编译、类型、代码规范到实际启动的全链路是可复用的迁移验收模板。在更大的 tranche 视角下它还常与pnpm install、pnpm turbo build、pnpm test等命令一起构成完整的回归证明见 docs/plans/2026-04-16-slate-v2-tranche-2-execution.md 的 Progress 部分。实践要点总结以成熟仓库为参照不自行发明构建形态对齐已验证可运行的配置形状能显著降低迁移风险脚本与配置双管齐下--webpack既会藏在脚本参数里也会藏在 next.config 的回调分支中必须同时清理保留 dev-only 源码别名去 webpack 不等于去别名机制开发期指向源码、构建期指向 dist 的差异化配置turbopack.resolveAliasisDev判断是 monorepo 站点的关键工程形态详见 apps/www/next.config.ts移除依赖要找到替代者webpack 回调之所以可删是因为显式示例导入表已经接管了它的职责——删除任何兼容层前先确认其职责已被替代用四道命令收口验证build、typecheck、lint、serve 缺一不可确保没有隐性 webpack 耦合残留在运行时才暴露。去 webpack 化在 slate-v2 迁移中属于低风险兼容性收尾但它确立了一个长期有效的站点基线Next 16.2.4 Turbopack 主力通道 dev 期源码别名这也成为后续 trancheslate 核心、slate-dom、slate-react 的逐包恢复持续运行在干净构建链路上的前提参见 docs/slate-v2/overview.md 的 tranche 2 记录。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考