Umi.js 项目中遗留依赖包的兼容性更新探讨

Umi.js 作为一款流行的企业级前端应用框架，在其长期迭代过程中不可避免地会积累一些历史遗留问题。本文主要讨论 Umi.js 项目中一些老旧依赖包的兼容性更新问题，特别是针对 React 18 及以上版本的适配情况。

背景分析

在 Umi.js 的演进过程中，特别是从 Umi 3 升级到 Umi 4 时，框架保留了部分历史功能以保持向后兼容性。这些功能包括：

• dva 状态管理库
• ahooks 的 use-request
• dva-loading 等配套插件

这些依赖包目前存在的主要问题是其 package.json 中声明的 peerDependencies 仍然限定在较旧的 React 版本范围（如 React 15.x 或 16.x），而现代前端项目普遍已经升级到 React 17 或 18 版本。

技术细节

以 dva 为例，其当前的 peerDependencies 配置为：

"peerDependencies": {
  "react": "15.x || ^16.0.0-0",
  "react-dom": "15.x || ^16.0.0-0"
}

这种配置会导致在使用较新 React 版本时出现警告，虽然实际运行可能不会出现问题，但从工程规范角度考虑并不理想。建议的更新方案是将其扩展为：

"peerDependencies": {
  "react": "15.x-18.x",
  "react-dom": "15.x-18.x"
}

解决方案探讨

对于使用 Umi.js 的开发者，有以下几种处理方案：

1. 官方更新方案：等待 Umi 团队更新这些依赖包的 peerDependencies 声明。这种方案最为稳妥，但取决于官方维护计划。

2. 自定义插件方案：

   • 从 Umi 仓库中提取需要的插件源码
   • 修改相关依赖声明
   • 发布自定义的插件包
   • 在项目中使用自定义插件而非内置插件

3. 使用基础 Umi 而非 Max：Umi Max 内置了较多插件，而基础 Umi 更为精简，可以按需引入所需功能。

技术建议

对于新项目，建议避免使用这些历史遗留功能，转而采用更现代的替代方案：

• 状态管理：考虑使用 Redux Toolkit 或 Zustand 等现代状态管理方案
• 数据请求：直接使用 axios/fetch 配合 React Query 或 SWR
• 加载状态：自行实现或使用更现代的解决方案

对于必须维护的旧项目，可以暂时忽略这些警告，或采用上述自定义插件方案进行局部修复。

总结

Umi.js 作为成熟框架，在保持向后兼容的同时也需要逐步淘汰老旧功能。开发者应当评估项目需求，选择最适合的技术方案，平衡兼容性与技术先进性。对于 peerDependencies 这类声明性问题，虽然不影响运行时，但从工程规范角度仍值得关注和解决。