Meteor 3.0 迁移指南

外观

Meteor 2.x 中迁移到 Async ​

在 Meteor 3.0 中，我们正在从使用 Fibers 转换到异步方法和操作，以符合社区标准。虽然 Fibers（我们的 Promise 解决方案）在 2.x 版本中使用，但从 Node 16 开始不再支持。我们现在采用 async 和 await 以获得更好的兼容性。

先决条件 ​

使用至少 Meteor 2.8 版本 ​

我们建议您通过将应用程序更新到 2.8 或更高版本来开始异步迁移，因为您可以逐步执行此操作。与 3.0 不同，您可以同时使用新的异步和旧的同步行为维护相同的代码库。理想情况下，您应该更新到最新版本的 Meteor 2.x 并仔细阅读每个更改日志。在您将所有代码重构为 2.x 版本中的异步代码后，您可以更轻松地将其更新到 3.0 版本。

要检查您正在使用的版本，您可以运行

bash
meteor --version

您应该会看到类似以下内容

bash
meteor --version
Meteor <version>

API 更改 ​

如果在服务器端，您应该专注于迁移和更改您的 API 以使用 async 和 await 模式。

以下列出了您应该更改的最常见的 API

Mongo.Collection

  • findOneAsync
  • insertAsync
  • removeAsync
  • updateAsync
  • upsertAsync

Collection.Cursor

  • countAsync
  • fetchAsync
  • forEachAsync
  • mapAsync

accounts-base

  • Meteor.userAsync()

callback-hook:forEachAsync

  • forEachAsync

ddp-server

  • Meteor.callAsync()

Jscodeshift/codemod ​

我们社区的一位成员 minhna 为您创建了这个很棒的 repo 以帮助您将代码库迁移到异步。它使用 jscodeshift/codemod 来帮助您将代码库迁移到异步。

该项目提供了文档，解释了如何运行脚本。此 codemod 应该只影响应用程序的服务器端。从前端或后端开始更新是个人选择。虽然从服务器端开始是一种有效的方法，但必须评估逐个迁移功能是否可能是一种更好的策略。这样，您可以逐步解决错误，并避免遇到可能破坏整个应用程序的多个客户端问题。

脚本的一个有用功能是它将一些方法重构为异步，例如 findOne、count 和 accounts-base 包中的其他方法，例如 Meteor.user()，以及通过在它们之前添加 async 来调用这些方法的函数。

边缘情况 ​

根据您的代码库，codemod 在某些特定情况下可能无法正常工作。我们将列出一些边缘情况示例，如果您的代码库也出现这种情况，则需要手动进行更改或重构 codemod。

外部包中的 MongoDB 方法 ​

一个可能的边缘情况是，如果您使用 meteor/quave:collections 包定义 MongoDB 集合，则 codemod 将通过检查导入的形式来检查它是否为 MongoDB 集合 - 这意味着当脚本读取来自 quave 的导入时，它不会将其视为 MongoDB 集合。

出现此问题可能需要您手动重构代码或调整 codemod 以考虑此特定情况。

如何识别边缘情况 ​

由于它现在仅影响服务器端，因此重构后，您可以运行您的应用程序，观察终端中出现的错误，并逐步修复它们。在将服务器端重构为异步后，您的应用程序将能够运行而不会出现错误，然后您可以迁移到客户端。

建议您在每次重构后运行测试，以确保一切按预期工作。

如果可能，还可以一次迁移应用程序的一个模块，这样您可以测试并确保一切按预期工作。

前端 ​

要迁移前端，您可以根据您的框架遵循指南

包 ​

如果您在应用程序中使用了某些包，则应检查它们是否与 Meteor 3.0 兼容。

如果您拥有包，则可以查看我们的包迁移指南 此处。