Node.js V8 bug-fix, improved development reliability, Cordova 7, and more
With over 40 pull requests under its belt, Meteor 1.5.2 is finally here! New features, routine dependency updates and a number of bug fixes (including a sneaky garbage collection bug in Node.js V8), all come together to make Meteor 1.5.2 a worthwhile update for any Meteor user! Let’s get down to it.
How to upgrade
To update an existing app to Meteor 1.5.2, simply run meteor update in any Meteor application directory.
As a reminder, make sure your application’s .meteor directory is committed to your version-control system (e.g. Git, Subversion, etc.) so it’s easy to roll back if you encounter problems during any upgrade.
Potentially breaking changes
Though we strive to avoid breaking changes as much as possible, some can’t be avoided. These changes are relatively low-impact, so you may not even notice them, but they are worth mentioning just to be super clear. For more information on these changes, check the full version history.
Dropped support for MongoDB 2.4
In order to maintain compatibility with newer versions of MongoDB and its driver, we’ve dropped support for version 2.4. MongoDB maintains a list of supported versions and MongoDB 2.4 officially reached “End of Life” in March 2016. All major database vendors have long since discontinued 2.4, so the impact of this change should be minimal.
Re-exporting a module’s default export
If you have any wrapper modules that re-export another module’s exports using export * from "./wrapped/module", and the wrapped module has a default export that you want to be included, you should now explicitly re-export default using a second declaration:
export * from "./wrapped/module";
export { default } from "./wrapped/module";
“Bare” files are evaluated differently
Files contained by client/compatibility/ directories or added with api.addFiles(files, ..., { bare: true }), are now evaluated before importing modules with require, which may be a breaking change if you depend on the interleaving of bare files with eager module evaluation.
Updates and stability improvements
Node.js V8 garbage collection patch
In the past, we’ve occasionally shipped our own version of Node.js to include bug fixes, like this one in Node’s pre-packaged version of npm. Thankfully, for more than a year and a half (since Meteor 1.3.3), we’ve been able to ship the official tarball straight from the Node.js project.
Of course, while we enjoy not having to compile our own Node.js, an unfortunate garbage collection bug in the underlying V8 engine has created a valid reason for us to ship a patched version, as without it we’ve noticed unexpected segmentation faults in our CircleCI builds.
If you’re interested in the nitty-gritty details, you can check out the patch that we submitted to Node.js. Good news: the pull request has been merged and is slated for release in Node 4.8.5!
Thanks to the seamless integration of Node.js and Meteor versions, there is nothing additional you’ll need to do as a Meteor developer besides update to 1.5.2. As soon the new Node.js version ships (which can take a few weeks to a few months) we will resume bundling the official version of Node.js in a subsequent version of Meteor, likely 1.5.3.
The end of endless reloads
As a result of the change in Meteor 1.5.1, which drastically reduced the number of open file descriptors, we were able to home in on another problem that was less pronounced before but occasionally caused endless reloads during development for some users.
With the fix, Meteor no longer relies on file watchers to invalidate its file system cache when control files like .meteor/versions are modified by the build process.
Version bumps
The most substantial version bump award for this release goes to Cordova, which graduated from 6.x to 7.0.1. There shouldn’t be any breaking changes from the Meteor perspective, but those interested in what this means for Cordova should consult the Cordova blog post. (And thanks to skirunman for making this happen!) Looking forward, in Meteor 1.6, we will no longer bundle Cordova directly into Meteor releases (thanks to this pull request), but will instead install it automatically for those developers who use it. This should substantially reduce the download size of Meteor releases.
We’ve bumped minor versions of other dependencies to fix some more obscure bugs, but nothing that should be a cause for concern. Details can be found in the History.md for the release!
Ease for Galaxy
We’ve addressed some issues in the Galaxy deployment process that caused meteor deploy to stall for unclear reasons, especially when deploying from a continuous integration (CI) environment like Travis or Circle. The root of the problem turned out to be authentication errors that were never reported to the developer.
Furthermore, we’ve made changes which will ensure that Galaxy is ready for the major Node.js 8 and npm 5 versions bump in the upcoming Meteor 1.6.
Features
We don’t pack a lot of features into a point release like 1.5.2, but some things are too good to wait for, and we’re eager to get them into your hands!
See your package dependency tree
If you’ve ever scratched your head about some of the dependencies that you’ve seen trickle into your .meteor/versions file, then you’ll be thrilled by one of our recent community contributions. (Thanks, Stephen Darnell!)
It’s now possible to pass a --tree flag to the meteor list command to get a full, hierarchical dependency tree, much like the output of npm ls:
$ meteor list --tree
meteor-base@1.1.0
├─┬ ddp@1.3.0
│ ├─┬ ddp-client@2.1.0
│ │ ├── check@1.2.5
│ │ ├─┬ ddp-common@1.2.9
. . . . snipped . . . .
Remove more of the bits you might not need
As React developers will be sure to tell you, it’s long been possible to remove Blaze from the client bundle. However, it was still included on the server side due to a dependency from the boilerplate-generator package, which is responsible for rendering the initial HTML used to bootstrap the rest of the application. Since it was server-side only, this dependency wasn’t as important to remove, but thanks to the great work of Steven Hao, a Meteor summer intern, it’s now possible to remove it on the server as well.
For developers who are using Meteor as just a build tool, applications which don’t require the mongo package will no longer start the MongoDB server in development, resulting in faster start times and lower resource usage. (Thanks, Simon Fridlund!)
Roadmap updates and Meteor 1.6
If you haven’t already noticed, the Meteor Roadmap recently got some exciting near-term plans added to it, and we can’t wait to bring you all the new developments!
If you’re interested in helping define the future of Meteor, be sure to let us know what you’re most excited about by voting with emotes (👍) on feature requests, and adding productive conversation where applicable. And if you’ve got time to help build features, the best way to start is by reading our Development.md guide — we’d love to review your pull requests!
And of course, don’t forget to follow exciting news on Meteor 1.6 by pressing “Subscribe” on the 1.6 pull request!
Announcing Meteor 1.5.2 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.