Migrating 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`
@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
addition to the
web.browser (modern) and
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
hot-code-push packages will reload modern and legacy
clients independently, once each new bundle becomes available.
Overriding package version
.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
to be impossible (or at least very difficult) because of this
statement, which unfortunately constrained the
coffeescript package to
version 1.x. In Meteor 1.8, if you want to update
2.x, you can relax the
practicalmeteor:mocha constraint by putting
firstname.lastname@example.org_1! # note the !
.meteor/packages file. The
coffeescript version still needs
to be at least 1.x, so that
practicalmeteor:mocha can count on that
practicalmeteor:mocha will no longer constrain the
major version of
email@example.com_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: