迁移到 Meteor 1.8

Meteor 1.8 中的大多数新功能要么直接在后台应用（以向后兼容的方式），要么是可选的。有关更改的完整细分，请参阅变更日志。

话虽如此，但有一个必需的迁移步骤和一些您应该注意的事项。

更新 `@babel/runtime`

将 @babel/runtime npm 包更新到 7.0.0 或更高版本

meteor npm install @babel/runtime@latest

web.browser.legacy

除了 web.browser（现代）和 web.cordova 包之外，Meteor 1.7 引入了一个名为 web.browser.legacy 的新客户端包。当然，此额外包增加了客户端（重新）构建时间。由于开发人员在开发中大部分时间都在测试现代包，而传统包主要在生产环境中提供安全回退，因此 Meteor 1.8 巧妙地将构建传统包推迟到开发服务器重新启动之后，以便开发可以在现代包构建完成后立即继续。由于传统构建发生在构建过程本来完全空闲的时间，因此传统构建对服务器性能的影响最小。尽管如此，传统包仍然会定期重建，因此任何传统构建错误都将及时显示，并且传统客户端可以通过等待比现代客户端更长的时间来测试新的传统包。使用 autoupdate 或 hot-code-push 包的应用程序将分别重新加载现代和传统客户端，一旦每个新包可用。

覆盖包版本

.meteor/packages 文件支持一种新的语法来覆盖您无法控制的包中存在问题的版本约束。

如果 .meteor/packages 中的包版本约束以 ! 字符结尾，则应用程序其他位置（非 !）对该包的任何其他约束将被弱化，以允许任何大于或等于约束的版本，即使主/次版本不匹配。

例如，由于此api.versionsFrom("1.3")语句，以前无法（或至少非常困难）同时使用 CoffeeScript 2 和 practicalmeteor:mocha，该语句不幸地将 coffeescript 包限制为 1.x 版本。在 Meteor 1.8 中，如果您想将 coffeescript 更新到 2.x，您可以通过放置以下内容来放松 practicalmeteor:mocha 约束

  [email protected]_1! # note the !

在您的 .meteor/packages 文件中。coffeescript 版本仍然需要至少为 1.x，以便 practicalmeteor:mocha 可以依赖该最低版本。但是，practicalmeteor:mocha 将不再约束 coffeescript 的主版本，因此 [email protected]_1 将可以工作。

从低于 1.7 的版本迁移？

如果您要从低于 Meteor 1.7 的 Meteor 版本迁移，则可能存在本指南中未列出的重要注意事项（本指南专门介绍 1.7 到 1.8）。请查看旧的迁移指南以获取详细信息

• 迁移到 Meteor 1.7（从 1.6）
• 迁移到 Meteor 1.6（从 1.5）
• 迁移到 Meteor 1.5（从 1.4）
• 迁移到 Meteor 1.4（从 1.3）
• 迁移到 Meteor 1.3（从 1.2）