Babel 7, Cordova 7.1, Mongo 3.4, streaming server rendering, and more
Today we’re pleased to announce Meteor 1.6.1, an incremental release that’s packed with small improvements, as well as one important upgrade that requires special explanation: Babel 7
Meteor 1.6.2 is already well underway, because we didn’t get everything we wanted into Meteor 1.6.1. However, Meteor 1.6.1 was becoming quite a large release (486 commits, even more than Meteor 1.6), so we decided to shift gears, stabilize the moving parts, and release everything finished so far.
A note about versioning
If you’re not familiar with Meteor’s versioning conventions, releases like 1.5 or 1.6 are considered significant Meteor releases, meaning you should do everything in your power to upgrade your applications, because we’ve changed some very important aspects of how Meteor works.
Most software projects indicate major changes with versions like 2.0 or 16, but here at Meteor we’ve tried incredibly hard to preserve backwards compatibility ever since Meteor 1.0, so we’re saving “2.0” for a version of Meteor that requires profound changes to existing code. Until then, “minor” versions like Meteor 1.6 represent our most exciting releases.
According to this convention, Meteor 1.6.1 is an incremental release that fixes bugs and implements relatively conservative new features (relative to Meteor 1.6). Meteor 1.6.1 is a great version for starting a new application, and should be an appealing update if you’re already on the latest previous version (1.6.0.1), though it is not absolutely obligatory. Speaking of Meteor 1.6.0.1, a four-digit version represents a minimal patch release that fixes a critical problem for some set of Meteor developers, such as a security update to a bundled dependency like Node.js.
In other words, you should update to Meteor 1.6.1 if it fixes a problem for you, or you need any of the new features it provides, or just because you feel like staying up to date, after consulting the release notes or reading the rest of this blog post to get the highlights.
By the numbers
- Weeks of active development and testing: 12
- Unique pull request participants: 36
- Pull request comments: 76
- Reactions to PR comments: 61 👍, 10 🎉, 11 ❤️, 1 😄 , 0 😕, 0 👎
- Commits since Meteor 1.6.0.1: 486
- Lines of code added: 20,825
- Lines of code removed: 31,149
- Closed issues in the Release 1.6.1 milestone: 57
- Beta releases: 22
- Release candidates: 11
How to install from scratch
If this is your first time using Meteor, or you would prefer to reinstall Meteor from scratch to reclaim some disk space, the following commands will download Meteor 1.6.1 and install a system-wide meteor command.
Mac and Linux
curl https://install.meteor.com/ | sh
Windows
First install the Chocolatey package manager, then run this command using an Administrator command prompt:
choco install meteor
How to upgrade
Mac, Linux, and Windows
As usual, running meteor update in an application directory will update the application to Meteor 1.6.1. Running meteor update outside of an application directory will download Meteor 1.6.1 for later use, and meteor create new-appwill create a new Meteor 1.6.1 application.
Rolling back
In the unlikely event that the update leaves your application in a bad state, and you don’t feel like debugging it right away, please make sure your application’s .meteor directory is committed to your version control system (e.g. Git, Mercurial, etc.) before the update, so that it’s easy to revert the changes if you encounter problems.
Babel 7
By far the most noticeable change in Meteor 1.6.1 is that we’ve upgraded the version of Babel used for compiling ECMAScript package and application code from 6.24.7 to 7.0.0-beta.38. Yes, that’s a beta version, but we believe that’s acceptable for several reasons:
- We will be able to republish the babel-compiler and ecmascript packages to use a non-beta version of Babel whenever 7.0.0 is finalized, without having to publish a new Meteor release.
- Other projects, such as React, have already begun to recommend Babel plugins that depend on Babel 7, such as @babel/plugin-transform-react-jsx: https://reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html#babel
- Meteor has been using beta versions of Babel to implement the meteor command-line tool ever since Meteor 1.6, which has given us a chance to identify and fix the handful of problems we’ve encountered so far.
- By leveraging the abstractions of meteor-babel and babel-preset-meteor, as well as shrink-wrapping all of their dependencies, Meteor is able to provide a consistent core of well-tested Babel plugins, which shields Meteor developers from much of the complexity of the changing Babel plugin ecosystem.
What to expect
Although we are confident in the future of Babel 7, it would be misleading to suggest this upgrade will be seamless for all Meteor developers. Here are some of the problems you might encounter:
@babel/runtime (severity: 🌤)
The babel-runtime npm package has been required for all Meteor applications since Meteor 1.3. With Babel 7, babel-runtime has been renamed to @babel/runtime. If you update to Meteor 1.6.1 without adding @babel/runtime to your package.json dependencies, the Meteor babel-runtime package will throw a helpful error that recommends running meteor npm install @babel/runtime. You should follow this advice!
This change of names is in fact pretty convenient, because it allows @babel/runtime to be installed alongside babel-runtime, in case you need both for some reason; for example, if you rely on a custom Babel plugin that still assumes babel-runtime is installed.
Most Meteor developers should be able to remove babel-runtime after adding @babel/runtime, though there’s no harm in leaving it installed, since none of its modules will be bundled unless they’re used.
Atmosphere package version conflicts (severity: ⛈)
The major version of the Meteor babel-compiler package has been bumped to 7.0.0, which may be incompatible with existing Meteor packages that explicitly depend on an earlier version of babel-compiler. Version constraints in Meteor typically specify a minimum version, and otherwise constrain only the major version, allowing the minor and patch versions to change. In this case, however, we’ve changed the major version of babel-compiler, which is likely to produce some conflicts.
If you are the author of a Meteor package that depends on babel-compiler, and you have determined that the update is compatible with your package’s previous usage of babel-compiler (give or take any tweaks you might need to make), you can make your package compatible with either Babel 6 or Babel 7 by using the || version constraint syntax:
Package.onUse(function (api) {
...
api.use("babel-compiler@6.19.4||7.0.0");
...
});This approach has been working well for the coffeescript-compiler package, for example. Speaking of CoffeeScript, while Meteor 1.6.1 was under development, a new major version of the coffeescript and coffeescript-compiler packages were released (most recently 2.0.3_4), which is worth mentioning for the same reason as the babel-compiler@7.0.0 upgrade: packages like practicalmeteor:mocha that depended on a 1.x version of coffeescript may need to be updated or replaced. Specifically, we have found meteortesting:mocha to be a good choice.
Unfortunately, conflicting version constraints may originate from Meteor packages that are not actively maintained, in which case you may need to take matters into your own hands. Fortunately Meteor makes this possible: simply clone the package into your local packages/ directory and then modify the code as necessary, likely by relaxing version constraints in its package.js file, but also by making other necessary changes to the package. Your local copy of the package will take precedence over the Atmosphere version.
If your changes seem like they should become part of the original package, please submit a pull request to the upstream project. If the package author is not responsive, it may be time to find an alternative package that is more actively supported. However, this technique of modifying a local clone of a package is a powerful way to solve a variety of problems with Meteor packages that you didn’t write.
Outdated custom .babelrc plugins (severity: 👾)
If your team has added custom Babel plugins to a .babelrc file, now is a good time to make sure they all work with Babel 7. In particular:
- Please revisit the use of any presets like babel-preset-es2015 or babel-preset-env, as Meteor provides similar functionality via babel-preset-meteor. Redundant presets waste compilation time (at best) or introduce bugs (at worst) because not all plugins can safely run twice. Here’s a recent example of a Babel bug stemming from redundant Babel plugins. Instead, you should rely as much as possible on the defaults provided by Meteor, and carefully add individual plugins as needed, rather than blindly adding plugins or presets that you may not need. That might have worked in the past, but Babel 7 could expose hidden problems.
- If you’re using an official Babel plugin such as babel-plugin-transform-decorators, there’s a good chance it has been renamed to something like @babel/plugin-proposal-decorators. This blog post details the rationale behind this renaming, and may help you guess what the package is now called. Otherwise, you can search for the old package name here, and then look for the new package name in the current package.json file.
- Please refer to this blog post for general guidelines for upgrading to Babel 7, especially if you encounter problems after updating to Meteor 1.6.1.
We can provide assistance via GitHub issues, but please be aware that Meteor cannot guarantee the functionality of arbitrary .babelrc configurations. When you depart from the core Babel functionality provided by Meteor, you embrace the additional maintenance burden, for better or worse. We’re depending on you to appreciate the difference between a problem that Meteor can solve and a problem inherent in the complexity of your custom configuration.
Don’t panic!
However annoying it may be in the short term, updating to Babel 7 is a worthwhile investment of your time, since the Babel project has historically expected developers to be using the latest version, and does not typically back-port bug fixes to the previous version. We’ve tried to make this transition as easy as possible, and we hope that effort shows. We’re here to help, you’re not alone, and we greatly appreciate your patience with this process.
Other improvements
Instead of enumerating the many other changes in this release, we encourage you to read the release notes.
We’ve updated Cordova, Mongo, and many of the npm packages used by Meteor packages and the meteor command-line tool. Dynamic import() now uses HTTP POST requests. Thanks to James Baxley III, the server-render package now supports passing a Stream object to ServerSink methods that previously expected a string, which enables streaming server-side rendering with React 16:
import React from "react";
import { renderToNodeStream } from "react-dom/server";
import { onPageLoad } from "meteor/server-render";
import App from "/imports/Server.js";
onPageLoad(sink => {
sink.renderIntoElementById("app", renderToNodeStream(
<App location={sink.request.url} />
));
});If we missed something in the release notes, or you notice something that deserves a shout-out here, let us know in the comments below!
What’s next
Now that Meteor 1.6.1 has been finalized, it’s time to turn our attention to all the exciting work we put off until Meteor 1.6.2:
- https://github.com/meteor/meteor/milestone/47
- https://github.com/meteor/meteor-feature-requests/milestone/3
I’m especially excited about pull request #9439, which promises to reduce bundle sizes dramatically for modern browsers and Node, and enable truly native async/await (and other ECMAScript features) in the browser.
Conclusion
As long as your application is committed to version control, so that you can roll back in case of problems, there’s no harm in running meteor update to see what happens. Who knows; you might not even notice the Babel 7 update. Your application is unique among all Meteor applications.
If you run into any problems with the update, or have any questions, feel free to open an issue, comment on the Meteor 1.6.2 pull request, or start a discussion on our forums, and we will do everything in our power to help make Meteor 1.6.1 (or at least Meteor 1.6.2) work for you.
And of course, if Meteor 1.6.1 does work for you, we’d love to hear about that, too! Drop us a line in the comments below, or @meteorjs on Twitter.
Announcing Meteor 1.6.1 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.