Node 8, npm 5, Mongo 3.4.5, lazy modules anywhere, advanced React features
Now that Meteor 1.5.2 has been released, it’s time to look forward to our next major release: Meteor 1.6. Given all the improvements that are coming, it was tempting to stamp this release as “Meteor 2.0,” but that would suggest there must be lots of breaking changes, and that upgrading is likely to be a difficult chore. Nothing could be further from the truth, as we remain firmly committed to backwards compatibility and a smooth meteor update experience. And yet, Meteor 1.6 will be an enormous leap forward.
Does this mean we’re only now turning our full attention to Meteor 1.6? Lol, no. In fact, we’ve been working on 1.6 in parallel with 1.5.x releases for about three months now, and we began exploring the possibility of shipping Meteor with Node 6 all the way back in April 2016, even before Meteor 1.5 was released. We’ve published 26 beta releases of Meteor 1.6 so far, and the pull request has more than 250 commits, with 41 community participants.
In other words, Meteor 1.6 is already remarkably stable, thoroughly tested, and well on its way to shipping. A number of Meteor developers have successfully deployed Meteor 1.6 apps to production, despite our disclaimers and caveats, which are steadily dwindling in number and seriousness. That choice is not hard to understand: the benefits already outweigh the risks.
How excited are we about Meteor 1.6? Whatever else we may say, the basic truth is that we’ve been using it ourselves for everything we possibly can, except for rare cases when we need to debug problems specific to a certain Node or npm version. After spending so much quality time with Meteor 1.6 and Node 8, it’s getting harder and harder to switch back to Meteor 1.5.
If you’re willing to help test these shiny new tools, you can run
meteor update --release 1.6-beta.26
in any existing application directory, or run
meteor create --release 1.6-beta.26 new-app
to create a new application using Meteor 1.6.
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.
Node 8.4.0
Status: available since 1.6-beta.22.
The headline feature of Meteor 1.6 is a seamless upgrade from Node 4.8.4 to Node 8.4.0, the very latest version of Node. Although Node 8 will not officially attain LTS status until October, a full-stack framework like Meteor is uniquely equipped to deliver the experience as soon as possible, because we can smooth over any rough edges along the way. We were initially wary of skipping Node 6 entirely, but we couldn’t find any good reason to remain a step behind the times, and working with Node 8 has been thoroughly dreamy so far.
Ignition and TurboFan
Status: implemented by Node 8.3.0.
Node 8.3.0 was the first version of Node to use V8 6.0, which includes an all-new JavaScript interpreter (Ignition) and optimizing compiler (TurboFan).
Among many other performance benefits, this new JavaScript engine no longer penalizes “optimization killers” like try-catch blocks or certain usages of the arguments object. In other words, everything you thought you knew about V8 micro-optimizations is probably worth revisiting.
I’ll let Myles Borins introduce Node 8.3.0:
Node.js 8.3.0 is now available shipping with the Ignition + TurboFan execution pipeline
And I’ll let the V8 team explain Ignition and TurboFan in more detail:
Launching Ignition and TurboFan
Here are two reactions from actual Meteor developers who have been testing the latest Meteor 1.6 betas:
Fewer Babel plugins on the server
Status: implemented since 1.6-beta.11.
Node 8 natively supports almost the entire ECMAScript 2017 standard, with the notable exception of module syntax (import and export). That means Meteor no longer needs to use nearly as many Babel plugins to compile your server-side code, so rebuild times should be that much faster.
Of course, we still have to compile module syntax, and you can read all about how we do that in our previous blog post:
Reify: Meteor’s evolving JavaScript module compiler
Among the most exciting new native features, async functions and await expressions no longer have to be compiled using Regenerator. As the original author of Regenerator, nothing could make me happier than to see it become obsolete.
Native debugging
Status: implemented since 1.6-beta.0.
I wasn’t kidding when I tweeted:
This commit implements what I predict will be the most exciting new feature in @MeteorJS 1.6: https://t.co/gXMTKz1LiU
— @benjamn
I was talking about a new implementation of the meteor debug command using Node 8’s Inspector, which allows debugging Node applications using a variety of debugger clients, including Chrome DevTools:
Debugging Node.js with Chrome DevTools
When you run meteor debug in an application directory, your application builds and starts up, and your server code is parsed and evaluated by Node. However, just before your server code begins executing, the debugger pauses at a convenient breakpoint, so you have time to connect your debugging client of choice and set breakpoints anywhere you like. This is much better than using the node --inspect-brk flag, since that stops too soon to set any useful breakpoints.
The most amazing benefit of the Node 8 inspector is that your code runs at full speed, so you don’t have to wait forever to hit that all-important breakpoint, and you don’t lose nearly as much time if you accidentally continue past the line of code where the trouble is occurring. This also means you can finally do realistic performance and memory profiling of your server-side code through the Chrome DevTools UI.
Even if your application is stuck in an infinite loop, you can still attach a debugger, pause execution, and debug the loop. This makes me very excited about the possibility of remotely debugging Galaxy containers that get stuck at 100% CPU usage.
HTTP/2
Status: wishlist.
Node 8.4.0 added a new built-in module called http2, which can be enabled by passing the --enable-http2 flag to node. This was a minor breaking change because there is already a widely-used package called http2 on npm.
Meteor will need some time to make the most of HTTP/2, but we are very excited to see it land among the Node core libraries.
Node v8.4.0 (Current) | Node.js
npm 5
Status: implemented since 1.6-beta.4.
It’s been an interesting year for npm clients. Once unrivaled as the tool of choice for installing npm packages, the npm command-line tool faced some serious competition starting last September from an innovative tool called yarn, which promised fast, reproducible installs based on yarn.lock files.
The popularity of yarn led Meteor to support meteor yarn in addition to meteor npm (though you had to meteor npm install --global yarn first, so npm still had an advantage). Our own Galaxy Server and Optics apps, which are built with Meteor, switched over to yarn soon after its release. The appeal was undeniable.
This competition was a good thing for JavaScript developers, first because yarn solved some long-standing problems with npm, and later because npm@5 responded by shipping its own implementation of some similar features, with package-lock.json files and automatic addition of npm install-ed packages to package.json.
Another interesting command-line tool called npx ships with npm@5, and just as Meteor supports meteor npm ... as a shorthand for running npm with the right version of node and appropriate environment variables, so too will Meteor 1.6 support meteor npx ... as a way of running Node scripts installed in node_modules/.bin directories.
Meteor is careful to remain agnostic about how you choose to populate your node_modules directories, so we fully expect that meteor npm and meteor yarn will remain equally good alternatives for that purpose.
As with bleeding-edge versions of Node, there have been a few hiccups as we’ve updated npm. For example, with npm@5.4.0, we noticed that executable file permissions were being stripped after npm package installation, due to a bug in the pacote@6.0.1 package. This bug was caught by our own regression tests, and already had an open pull request that seemed to fix the problem.
Meteor was able to validate the pull request by rebuilding our dev bundle with a custom version of pacote, which allowed us to continue using npm@5.4.0 without waiting for the next release of pacote:
Love how @meteorjs can validate and ship cross-package fixes while other projects must merely chmod the symptoms: https://t.co/hdNPm2i0HB
— @benjamn
Mongo 3.4.5
Status: planned.
What seemed at first like a routine upgrade to Mongo turned out to have a subtle gotcha: Mongo 3.4 no longer supports 32-bit platforms, which means Meteor will need to drop official support for 32-bit Linux, and add support for 64-bit Windows.
Although it is now possible to remove Mongo entirely from a Meteor application, Meteor apps still depend heavily on Mongo by default, and so we think it makes sense for us to follow the lead of Mongo’s system requirements.
If you are an active user of Meteor on 32-bit systems, now would be a great time to let us know how you feel about this transition.
Lazy modules without imports directories
Status: planned.
When Meteor 1.3 first introduced a module system based on CommonJS and ECMAScript module syntax, we had to provide a way for developers to migrate their apps from the old ways of loading code, whereby all files were evaluated eagerly during application startup.
The best solution at the time was to introduce a special imports directory to contain modules that should be loaded lazily (rather than eagerly), when first imported.
Most other Node applications work this way by default: every module is lazy, and therefore must be imported by another module, and evaluation starts with one “entry point” module (typically specified by the "main" field in package.json).
It should be possible for Meteor apps to opt into this behavior, and optionally get rid of their special imports directories. The mechanism for opting in will very likely involve putting something in your package.json file that specifies entry point modules for both client and server.
Support for advanced React features
Status: partially completed.
React is the most popular way to build UIs in JavaScript today, and a great companion to the rest of the features provided by Meteor. Meteor’s zero-configuration environment provides a great opportunity to make features which React apps depend on work out of the box. This includes features like:
- Automatic selection of development vs. production build of React modules (completed).
- Easy abstraction for isomorphic server-side rendering (ongoing).
To get you excited, check the awesome example app built by James Baxley III, which was recently demoed at the ReactNYC Meetup: https://reactnyc.meteorapp.com/ - Integration of dynamic imports with server-side rendering (planned).
- Full support for optimized CSS-in-JS features of libraries like styled-components (completed).
- Easy creation of zero-configuration React-based Meteor apps via
meteor create --react my-react-app (planned).
We think Meteor has a clear set of benefits compared to other popular React frameworks like Create React App (which does not support server-side rendering) and Next.js (which is much more opinionated about design choices like routing).
How to get involved
The best way to get involved in the development of Meteor 1.6 is to try updating an existing app, or creating a new one:
meteor update --release 1.6-beta.26 # in an existing app directory
meteor create --release 1.6-beta.26 new-app
If you have questions, feel free to ask them on the pull request, or file an issue on our issue tracker, and we will gladly help you triage your problems. Just remember to indicate clearly that you are using Meteor 1.6.
The more usage of Meteor 1.6 we can get during the beta testing process, the sooner we’ll have enough confidence to ship a release candidate, and then ultimately a final release.
Please bear in mind that meteor node ... and meteor npm ... can help ensure you’re using the right version of node and npm for your current application (according to .meteor/release)—a subtlety that is especially important when you’re working with multiple beta versions of Meteor, which may use slightly different versions of node and npm.
You can keep track of the latest release versions on our Releases page, and stay abreast of our longer-term vision by consulting our Roadmap.md document.
Once you give Meteor 1.6 a try, we think you’ll understand what we mean when we say it’s hard to switch back to earlier versions of Meteor.
What’s coming in Meteor 1.6 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.