Upgrade to Meteor 1.5 for easier app development
On the heels of the Meteor 1.5 release, which introduced the dynamic import(…) statement and exact code-splitting (with no special configuration), many Meteor developers have been slashing their bundle sizes and reaping the benefits of faster client load times thanks to smaller initial client bundles.
As alluring as it is, shedding precious bytes isn’t the only motivating factor for upgrading, and the jump from 1.4 to 1.5 is a big deal in Meteorland. If you’re still running 1.4, 1.3, or something more ancient, it’s a good time to think about actually pressing that <Enter> key the next time you hesitantly type out meteor update.
Major release or not, Meteor strives hard to be backward-compatible. If you haven’t revisited it or are overwhelmed by all the amazing changes in the History file, fire up your development server and give it a shot!
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 ever encounter problems during any upgrade.
To update, simply run:
meteor update
C’mon. Do it! Press <Enter>!
“Why me? Why upgrade?”
For starters, if you’re using any Meteor version before 1.4 I’d encourage you to take a long, hard look at your project. Whether you want to believe it or not, your application is in need of an update and it’s not just because of Meteor that I’m recommending it!
For example, Meteor 1.3.5.1 shipped with Node.js 0.10.46. As scheduled, the 0.10.x-series was “end of lifed” by the Node.js Foundation in October of 2016. This means that it’s not receiving security updates anymore, including any which have arisen from Node.js dependencies like openssl, tls, and libuv! From a security standpoint, you should make the jump to at least Meteor 1.4 which ships with Node.js 4 and is actively under Node Foundation Long Term Support (LTS) coverage.
There are true gems spread throughout 1.4…
The Meteor 1.4 series brought a lot of fun improvements. 1.4.2.7? 1.4.1.2? 1.4.4.3? These quadruples were serious version numbers!
Let’s recap what developed! (And try to guilt you into updating.)
Modern language, zero config.
Meteor 1.4.x kept bringing newer ECMAScript syntax out-of-the-box, without the need to make custom configurations to support them. To name a few:
- Array.prototype.includes
- String.prototype.padStart / String.prototype.padEnd
- Object.entries / Object.values
- export * as namespace from "./module"
- export def from "./module"
React? Blaze? jQuery? Bring what you want, ditch what you don’t.
While Blaze and jQuery are still friends with Meteor, great strides were taken to allow their removal, providing freedom to explore other options.
React and Meteor also play nicely together, but previously it was hard to avoid shipping the overhead of Blaze and jQuery to the client if you didn’t need them.
Thanks to work started last October and wrapping up with amazing work by the community (particularly Hugh Willson and Wexpo Lyu) to de-couple Meteor Accounts packages from Blaze, it’s now possible to achieve this setup.
To remove both Blaze and jQuery from a new Meteor 1.5 project, simply run:
meteor remove blaze-html-templates
meteor add static-html
Don’t forget, React and Blaze can co-exist, so if you like taking small bites it may ease your way through a transition if you choose to embark on that journey.
Speed & stability
Apps keep getting larger and their dependencies more complicated (Targeted advertising: Putting your app on a diet). Developers, however, sang praise when Meteor 1.4.2 cut down their rebuild times. (Thankfully, since that was its goal!)
Many improvements in this department are made directly to Meteor and plenty more are thanks to a constant stream of updates to its dependencies — and there were plenty.
For example, 1.4.x went through nine iterations on the Node.js 4.x-series, and also brought in the (then) newer npm 4 — which came with more friendly messaging (like reminding you when you’ve installed something in both devDependencies and dependencies), an awesome CLI search, shrinkwrapping of devDependencies and plenty of speed and bug fixes.
As the next step, our sights are set on Node 8 and npm 5 for Meteor 1.6. That’s right, we’re skipping Node 6 entirely.
Other dependencies with major updates included:
- MongoDB (and improved connectivity from the Mongo Node Driver)
- Cordova
- CoffeeScript (now supports import and export)
Microsoft Windows users also received a number of benefits including many filesystem improvements and further tweaks to allow running the Unix meteor through Bash On Windows (via the Windows Creators Update).
Pre-scaffolded applications
If you are meteor create-ing new applications on a regular basis you’ll likely find the new --full and --bare scaffolding flags very helpful! While the default option maintains the “classic” method you’re used to, the “full” option will produce a more structured application using the module-driven import approach, as recommended by the Meteor Guide’s Application Structure. On the other hand, the “bare” option will give you no starter files and a completely fresh slate to build your own.
Meteor maintainability
A number of improvements to the underlying architecture in Meteor have made it possible for Meteor to release updates with a higher velocity than ever before.
With 1.4 came the ability for Meteor to handle recompiling binary-dependencies from Atmosphere packages on its own. Developers need a compiler toolchain to do this (and many will already have it installed), but this allows Meteor to upgrade to newer versions of Node.js more quickly without potentially breaking existing binaries and necessitating package developers to re-release their packages with each major version upgrade.
To further allow Meteor to move more quickly, versions of core packages are no longer strictly constrained to core releases. This means that an important feature for say, email, doesn’t need to wait for another major version of Meteor itself. Despite this, there were more releases than ever before in 2016.
Meteor in 2017 is looking great!
Easy goes it
I’m confident that applications that have inched along the upgrade path as new releases came out will have little to no problems making the update to Meteor 1.5.
However, if you’re updating older applications, I’m happy to report that I’ve recently updated a half-dozen Meteor applications directly from pre-1.3 to Meteor 1.4 in about an hour each, with little struggle.
Check out the Meteor 1.5 migration guide if you’re looking for a place to start. However, it’s relatively straightforward, so get with the latest Meteor!
The improvements you missed since Meteor 1.4! was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.