Node.js and npm updates, Cordova Google Sign-In, and hybrid minification
Today we’re excited to announce Meteor 1.4.4, a routine incremental release to update core dependencies, fix bugs, improve stability, and address a critical Google authentication change for Cordova apps. Read on for details on upgrading, release improvements, and what’s coming next.
How to upgrade
To update an existing app to Meteor 1.4.4, 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 ever encounter problems during any upgrade.
Node.js, npm, and node-gyp
As usual with new Meteor releases, underlying dependencies of the framework have been updated to their latest versions in Meteor 1.4.4, with Node.js at 4.8.1 and npm at 4.4.4. Additionally, Windows developers using Visual Studio 2017 will benefit from improved support for binary npm packages thanks to the update of node-gyp to 3.6.0.
See the Node.js 4.8.1 release notes for the full details, including numerous bug fixes and performance benefits.
Critical Cordova updates for Google OAuth
Meteor developers with mobile apps based on Cordova, who let their users authenticate with Google OAuth (via the accounts-google, google, or google-oauth packages): please pay close attention to this section!
Google announced in August 2016 that they would be blocking OAuth logins from embedded web-views (such as the WebView UI element on Android and UIWebView/WKWebView on iOS), and started displaying the following message on the iOS and Android consent pages late last year:
Notice for developers: authorization requests in embedded browsers will be blocked on April 20, 2017.
If this describes your Cordova application, be sure to update accounts-google to version 1.1.2 to enable the new login process which internally utilizes the Google Sign-In API (thanks to Eddy Verbruggen’s cordova-plugin-googleplus Cordova package).
Please let us know if you have any trouble with this transition, and soon!
Minifier improvements for ES6
“Minification” is a common optimization to reduce the amount of code that has to be downloaded by clients in production. By removing comments and whitespace, transforming superLongVerboseAndDescriptive variable names into single-character equivalents, eliminating certain kinds of unreachable code, and restructuring syntax to save a few characters here and there, the minifier can easily reduce client bundle sizes by 80% or more.
Minification usually takes place after a tool like Babel has compiled modern JavaScript syntax to older, more widely supported syntax, so the minifier generally does not need to handle bleeding-edge syntax. Over time, however, the bleeding-edge becomes the commonplace, and we eventually stop needing to compile it into something else. That’s progress, but the minifier has to keep up. Lately, we’ve seen an increase in complaints that our minifier (based on UglifyJS) was failing to handle common syntax.
While it was tempting to replace UglifyJS with a different minifier, none of the other options were nearly as fast, so we adopted a hybrid solution: when UglifyJS fails to minify a given file, we now catch the exception and fall back to the slower (but more future-friendly) Babili minifier. With this simple strategy, Meteor developers automatically benefit whenever UglifyJS improves its ECMAScript support or whenever Babili improves its performance.
Best of all, this Babili integration was driven almost entirely by the hard work of community contributor @sethmurphy18. Thank you, Seth!
New export-from syntax
Speaking of bleeding-edge ECMAScript features, Meteor 1.4.4 introduces support for two new kinds of export ... from "./module" declarations:
As in previous Meteor releases, the module.importSync API is provided by the Reify module compiler, though it used to be called module.import.
The complete ECMAScript proposals with additional explanation can be found here and here. In short, these two new styles of export declaration make it slightly easier to re-export symbols from other modules without having to import those symbols with temporary names and then export them in a separate declaration.
And much more!
Many other changes and bug-fixes made it into Meteor 1.4.4, including better support for custom .babelrc plugins that modify import declarations and improved Galaxy deployments for Windows users. Check out the full release notes in the Meteor repository.
What’s next?
As the version number suggests, Meteor 1.4.4 is an incremental release in the Meteor 1.4 line.
We are simultaneously working on a more significant and exciting Meteor 1.5 release, which you can follow here. To try the new features of Meteor 1.5, run meteor update --release 1.5-beta.14 in any application directory, though please make sure your .meteor directory is committed to version control so you can roll back easily. Though Meteor 1.5 is still in “beta,” we consider it relatively stable, so please report any bugs you encounter.
Longer term goals along with periodic status updates are outlined in Roadmap.md. Worth noting here is that the effort to upgrade Meteor to Node 6 and beyond has recently made substantial progress. There’s even a very early preview release you can try, though please keep in mind that no version of Meteor 1.6 is ready for production yet.
Announcing Meteor 1.4.4 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.