Migrating to Meteor 1.8

How to migrate your application to Meteor 1.8.

Most of the new features in Meteor 1.8 are either applied directly behind the scenes (in a backwards compatible manner) or are opt-in. For a complete breakdown of the changes, please refer to the changelog.

The above being said, there is one required migration step and few things that you should note.

Update the `@babel/runtime`

Update the @babel/runtime npm package to version 7.0.0 or later:

meteor npm install @babel/runtime@latest


Meteor 1.7 introduced a new client bundle called web.browser.legacy in addition to the web.browser (modern) and web.cordova bundles. Naturally, this extra bundle increased client (re)build times. Since developers spend most of their time testing the modern bundle in development, and the legacy bundle mostly provides a safe fallback in production, Meteor 1.8 cleverly postpones building the legacy bundle until just after the development server restarts, so that development can continue as soon as the modern bundle has finished building. Since the legacy build happens during a time when the build process would otherwise be completely idle, the impact of the legacy build on server performance is minimal. Nevertheless, the legacy bundle still gets rebuilt regularly, so any legacy build errors will be surfaced in a timely fashion, and legacy clients can test the new legacy bundle by waiting a bit longer than modern clients. Applications using the autoupdate or hot-code-push packages will reload modern and legacy clients independently, once each new bundle becomes available.

Overriding package version

The .meteor/packages file supports a new syntax for overriding problematic version constraints from packages you do not control.

If a package version constraint in .meteor/packages ends with a ! character, any other (non-!) constraints on that package elsewhere in the application will be weakened to allow any version greater than or equal to the constraint, even if the major/minor versions do not match.

For example, using both CoffeeScript 2 and practicalmeteor:mocha used to be impossible (or at least very difficult) because of this api.versionsFrom("1.3") statement, which unfortunately constrained the coffeescript package to version 1.x. In Meteor 1.8, if you want to update coffeescript to 2.x, you can relax the practicalmeteor:mocha constraint by putting

  coffeescript@2.2.1_1! # note the !

in your .meteor/packages file. The coffeescript version still needs to be at least 1.x, so that practicalmeteor:mocha can count on that minimum. However, practicalmeteor:mocha will no longer constrain the major version of coffeescript, so coffeescript@2.2.1_1 will work.

Migrating from a version older than 1.7?

If you’re migrating from a version of Meteor older than Meteor 1.7, there may be important considerations not listed in this guide (which specifically covers 1.7 to 1.8). Please review the older migration guides for details:

Edit on GitHub
// search box