After the release of Meteor 1.7 in June this year, the Meteor community released Meteor 1.8 yesterday. This version eliminates many of the performance problems in Meteor 1.7. They have addressed the technical debt of compiling an additional client bundle which had led to slow build times in Meteor 1.7.
Here’s what all has been added and improved in this latest release.
Improved build time
In addition to the web.browser and web.cordova bundles, Meteor 1.7 introduced a new client bundle called web.browser.legacy. This addition of an extra bundle resulted in increased client build and rebuild times.
Usually, developers spend most of their time testing the bundle in development and the legacy bundle provides a safe fallback in production. Meteor 1.8 takes advantage of this fact and cleverly postpones building the legacy bundle until just after the development server restarts. Development can continue as soon as the modern bundle has finished building.
As 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. Still, the legacy bundle gets rebuilt regularly, so any legacy build errors will be surfaced in a timely fashion.
A new mechanism for compiling unused files
Meteor’s compiler plugins compile every file they receive, regardless of whether the file will ever actually be imported. To avoid this unnecessary compilation of unused files Meteor 1.8 has finally introduced a simple mechanism.
Though the compiler plugin will process every possible file, any unused files will now be ignored by the build system, and their uncalled callbacks will be discarded after the bundle is built.
Create Meteor apps with a simple command
You can now easily create new Meteor apps with React instead of Blaze using the following command:
meteor create --react new-react-app
Overriding problematic version constraints from packages
A new syntax is introduced for the .meteor/packages file for overriding problematic version constraints from packages you do not control. If a top-level package version constraint in .meteor/packages ends with a ‘!’ character, any other (non-!) constraints on that package elsewhere in the application will be weakened. Which means, any version of the package that is not less than the constraint will be accepted, regardless of whether the major/minor versions actually match.
For instance, using both CoffeeScript 2 and practicalmeteor:mocha used to be difficult because of the api.versionsFrom(“1.3”) statement. This statement 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 email@example.com_1! in the .meteor/packages file.
Upgraded to Babel 7
You can get the benefits of non-beta Babel 7 by updating to Meteor 1.8. Install the latest version of @babel/runtime by running the following command:
meteor npm install @babel/runtime@latest
Upgraded to Mongo 4
Meteor 1.8 comes with MongoDB 4.0.2, a major upgrade from version 3.6.4 in Meteor 1.7. Your local development database will now use version 4.0, though the firstname.lastname@example.org driver will connect to production databases going all the way back to Mongo 2.6.
The major advantage of MongoDB 4.0 is its support for multi-document transactions, which are now supported by Meteor’s oplog tailing system.
Node.js 8.11.4 for now
Although Node 8.12.0 has been released, Meteor 1.8 still supports Node 8.11.4, due to concerns about excessive garbage collection and CPU usage in production. If you want to start using Node.js 8.12.0, you can contribute to the Meteor 1.8.1 pre-release process. In order to update to Meteor 1.8.1, run the following command:
meteor update --release 1.8.1-beta.n