TinaCMS v3 到 v4 迁移包名替换与弃用包迁移路径怎么选【免费下载链接】tinacmsTinaCMS is the leading open-source headless CMS that supports Markdown and Visual Editing. Your content is stored in your own GitHub repo ❤️项目地址: https://gitcode.com/GitHub_Trending/ti/tinacms如果你的项目还在tinacms3.x上想规划向 v4 的迁移需要回答三个问题根包的 npm 名怎么换、各个弃用包分别迁到哪里、以及tinacmsCLI 去掉dev和build之后项目怎么运行。本仓库的 v4 包地图 packages/v4/README.md 和弃用决策表 packages/v4/DEPRECATIONS.md 对这三点都给出了明确规定。开始之前注意现状v4 的tinacms/tinacms目前是预发布版4.0.0-alpha.x在仓库中为private: true尚未对外发布v4 也不发布 DEPRECATIONS 表中的任何弃用包。因此当前能执行的动作是按文档把包名和 import 的改法准备好真正的安装切换要等 alpha 发布之后。v3 与 v4 的包布局差异两个版本在仓库里并行存在v4 脚手架位于packages/v4/与顶层的 v3 包相邻以便团队在构建 v4 的同时继续发布 v3 修复Layerv3 (now)v4npm name of the root runtimetinacmstinacms/tinacmsWorkspace pathpackages/tinacmspackages/v4/tinacms/tinacmsRelease statusSupport mode. Bug fixes only.Pre-release4.0.0-alpha.xalpha 发布前保持private: trueCLItinacms/cli独立包提供tinacmsbin属于tinacms/tinacms同样提供tinacmsbin两个关键判断依据v3 的tinacms包留在原处不改名、不标记 deprecated、也不会再作为重定向包发布。v3 用户继续安装tinacms3.x从main分支持续获得安全修复和回归修复。v4 用新的 npm 名tinacms/tinacms发布有两个目的一是让 npm 用户看到团队仍在支持 v3二是允许一个项目在迁移期间同时使用两个大版本。根包替换tinacms换成tinacms/tinacmsDEPRECATIONS.md 的 The result for users 一节明确给出了升级主路径An upgrade from v3 to v4 needs one change in package.json: tinacms becomes tinacms/tinacms. Then rewrite the imports that the rows above specify.即package.json里只做一处依赖替换再按下面决策表逐行改写 import。文档特别强调这不是“一次性替换很多包”的操作。CLI 也随之合并v3 中tinacmsbin 由独立的tinacms/cli提供v4 中代码进入tinacms/tinacmsbin 随包移动tinacms命令本身不变——所以依赖tinacms/cli的项目替换对象是tinacms/tinacms脚本里的tinacms命令不用改。v4 包还声明了 peer 依赖见 packages/v4/tinacms/tinacms/package.jsonreact^19.2.0可选与vite^5.4.0 || ^6.0.0 || ^7.0.0可选。弃用包怎么选迁移路径DEPRECATIONS.md 用三种状态区分每个包的处理方式选路径时先认清项目里的包落在哪一类deprecate— 包保留在 npm 上package.json加deprecated字段停止功能开发能力迁入保留的 v4 包。源码在新包具备该能力前继续留在 monorepo。remove— 包从 monorepo 删除无替代包v3 用户永久停留在最后一个 v3 版本。fold— 能力并入保留的 v4 包npm 上不提供替代包。v3 用户会实际触碰到的行如下摘自决策表当前包状态v4 替代迁移路径tinacms/clideprecatetinacms/tinacms含tinacmsbin安装tinacms/tinacms替代tinacms/clitinacms命令不变tinacms/schema-toolsdeprecate, then foldtinacms/tinacms的thelper 与 codegen 模块把import { ... } from tinacms/schema-tools换成tinacms/tinacms的等价导出tinacms/datalayerdeprecate, then foldtinacms/tinacms的src/store/与 local-content 插件Level 适配器在独立仓库mongodb-level、sqlite-level、upstash-redis-level直接使用tinacms/datalayer的自托管应用要换成对应的 Level 适配器和tinacms/tinacms里的 local-content 插件tinacms/webpack-helpersremove无v4 只发布 ESM受支持的适配器next、astro、express、hono不需要 webpack helper 函数tinacms/vercel-previewsdeprecate, then foldtinacms/bridge接收 preview 代码改用tinacms/bridge的 preview helper 函数tinacms/metricsdeprecate, then foldv4 CLI 与运行时内部无需用户操作内部包v4 通过 CLI 提供相同 telemetrytinacms/toolkitremove无由 v4 admin shell 替代tinacms/app与tinacms/tinacms/reactreact-tinacms-editorremove无使用tinacms/tinacms的 v4 rich-text 字段tina-graphqlremovetinacms/graphql改 importtina-cloud-nextremove无由tinacms/tinacms/adapters/next提供 TinaCloud 集成选择方法很直接项目依赖的每个弃用包在表里找到对应行——状态为 deprecate/fold 的包都有目标包和 import 改法状态为 remove 的包没有替代包文档直接写明用什么承接admin shell、rich-text 字段、tinacms/graphql或框架适配器。表里还列出了一批已不在 monorepo HEAD 的包react-modals、react-screens、sharedctx、tina-graphql-gateway等处理方式同样按行查表。集成包npm 名暂不变无需立即重装packages/v4/INTEGRATIONS.md 记录了另一类迁移next-tinacms-cloudinary、next-tinacms-s3、next-tinacms-dos、next-tinacms-azure、tinacms-clerk、tinacms-authjs、tinacms-gitprovider-github这些集成包会移到 TinaCMS 各自独立维护的仓库。对使用者而言npm 名当前不变变的是仓库归属和主分支文档明确说“A user does not have to install the package again immediately”v3 安装命令继续可用。计划中的 v4 npm 名供迁移后替换参考tinacms/cloudinary、tinacms/s3、tinacms/digitalocean-spaces、tinacms/azure-blob、tinacms/clerk、tinacms/authjs、tinacms/gitprovider-github。新仓库统一采用框架无关核心加/next、/express、/astro、/hono适配器入口的布局约定与tinacms/tinacms的exportsmap 一致。CLI 变化tinacmsbin 不再包装构建流程v3 里 Tina 拥有项目流水线tinacms dev -c next dev让 Tina 成为框架的父进程tinacms build next build让 Tina 成为构建步骤。v4 反过来项目拥有自己的流水线Tina 被项目调用。文档给出的硬规则是tinacmsbin 只写一个由人提交的文件不包装进程、不打开端口、不产生构建产物。它只提供这些命令命令写入什么是否允许tinacms inittina/config.ts、插件注册、admin 路由允许tinacms codegentina/tina-lock.json允许tinacms codegen --check不写文件已提交的 lock 过期时以退出码 1 结束允许tinacms dev—不允许。运行框架自己的 dev serverVite 插件和适配器负责其余部分tinacms build—不允许。lock 已提交没有可构建的东西能力因此挂进项目自己的服务器本地数据层是项目加到自身配置里的 Vite 插件或一条适配器路由RPC handler 是(Request) PromiseResponse由框架适配器挂载为项目的一条路由admin UI 是项目在自己路由上渲染的 React 组件不再是构建步骤拷进public/的 bundle。如何验证迁移结果文档给出了几个可核对的检查点弃用提示一个 pin 住tinacms/datalayer2.x的 v3 项目执行pnpm install继续正常工作npm 会显示package.json中deprecated字段的内容——看到这个提示即说明弃用标记已生效。依赖树干净依赖tinacms/tinacms的 v4 项目pnpm install后得到一棵依赖树其中不出现任何弃用包。lock 校验tina-lock.json是提交进仓库的文件而不是构建产物ADR-016CI 和部署永远不运行tinacmsbin。tinacms codegen --check可作为漂移守卫接入 CI它不写任何东西已提交的 lock 过期时以退出码 1 结束。跑 v4 示例仓库内最小的 v4 应用在 packages/v4/examples/barebones/README.md从仓库根目录执行pnpm install pnpm --filter examples/v4-barebones dev打开打印出的 URL站点渲染在/admin 在/admin/dev codegen 一次性脚手架出public/admin/index.html由项目提交。tina/config.ts的 schema 变更会在下一次 dev 运行或pnpm codegen时刷新tina/tina-lock.json——记得提交 lock。示例 README 也标注了当前 alpha 阶段的限制两个 node 侧 import 因 alpha 直接经exports发布原始.tsADR-001而用相对路径指向包源码浏览器侧 import 已使用公开 specifiers。边界与限制v4 处于预发布阶段4.0.0-alpha.xalpha 发布前private: true且 v4 不发布任何弃用包。当前阶段可执行的是包名与 import 的替换准备不是整体切换安装。v3 处于 support mode只有 bug 与安全修复。未迁移的项目从main分支继续获得这两类修复但不会获得新功能。v4 只发布 ESM依赖tinacms/webpack-helpers的构建链需要按决策表调整到受支持的框架适配器next、astro、express、hono。v4 的完整架构规范在独立的 v4 规范仓库中不在本仓库内本仓库packages/v4/tinacms/tinacms/_docs/下有架构与字段规格的源文档可对照。【免费下载链接】tinacmsTinaCMS is the leading open-source headless CMS that supports Markdown and Visual Editing. Your content is stored in your own GitHub repo ❤️项目地址: https://gitcode.com/GitHub_Trending/ti/tinacms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考