Node.js 8, npm 5, native debugging, 64-bit Windows binaries, and more

Five months of active development on one massive GitHub pull request

Today we’re thrilled to announce the final release of Meteor 1.6, which brings the latest stable version of Node.js, an amazing new debugging experience, npm 5, 64-bit Windows support, and countless other improvements to the Meteor platform — all without wavering from our commitment to backwards compatibility and a smooth meteor update experience.

Much of what’s included in Meteor 1.6 was foretold in our preview blog post:

Now that we’ve finalized the release, it’s worth reviewing which features made the cut, and which have been postponed until Meteor 1.6.1. As always, you can find the full release notes in the file in the main Meteor repository. Before we get into those details, though, we’d like to reiterate something we said in that earlier post, because it still rings true:

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.

Making past versions of your own software obsolete is one of the great joys of iterative software development. We hope your upgrades go smoothly, and that you soon find out for yourself what’s so exciting about Meteor 1.6.

By the numbers

  • Months of active development and testing: 5
  • Unique pull request participants: 79
  • Pull request comments: 263
  • Reactions to PR comments: 490 👍, 264 🎉, 136 ❤️, 43 😄 , 0 😕, 0 👎
  • Commits since Meteor 435
  • Lines of code added: 6,052
  • Lines of code removed: 2,743
  • Closed issues in the Release 1.6 milestone: 38
  • Alpha releases: 8
  • Beta releases: 33
  • Release candidates: 19
  • Prerelease versions that were completely broken: hey now
  • Different versions of Node.js 8 tested: 15
  • On-disk size of the meteor-tool package: 219MB
  • Meteor meteor-tool size: 545MB
  • Known barriers to upgrading from Meteor 0

Though we don’t usually talk about things like this, behind the scenes, the reliability, speed, and success rate of our test infrastructure has improved significantly in the last few months:

Our integration test suite: healthier than ever!

Thanks to weekly triage meetings and the heroic diligence of reviewers like Hugh Willson, the meteor/meteor repository now has just 171 open issues, and 12 open pull requests. At the risk of revealing too much about past Meteor releases, we’ve honestly never been this on top of things before, and we hope you feel the benefits of that stability in your own development experience.

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 and install a system-wide meteor command.

Mac and Linux

curl | sh


First install the Chocolatey package manager, then run this command using an Administrator command prompt:

choco install meteor

How to upgrade

Mac and Linux

As usual, running meteor update in an application directory will update the application to Meteor 1.6. Running meteor update outside of an application directory will download Meteor 1.6 for later use, and meteor create new-appwill create a new Meteor 1.6 application.


All Windows developers should follow the instructions above to reinstall Meteor 1.6 from scratch. The old InstallMeteor.exe installer is no longer supported, and the choco install meteor command is the only way to get a native 64-bit version of Meteor on Windows. If you run meteor updatewithout reinstalling Meteor with Chocolatey, the download will take much longer, and you’ll end up with a 32-bit version of Meteor. Once you’ve installed the 64-bit version of Meteor using choco install meteor, you can then use meteor update for future Meteor updates.

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.

Node.js 8.8.1

If you’ve ever wondered why we talk about specific versions of Node.js when we talk about Meteor releases, Jesse Rosenberger wrote a recent post explaining the value of shipping Node.js with Meteor:

Notable changes

The jump from Node.js 4 in Meteor to Node.js 8 in Meteor 1.6 is not to be taken lightly, and it’s a testament to the care of the Node.js team that so few breaking changes were introduced in four major versions.

That said, there have been a number of notable changes that are worth reviewing as you update to Meteor 1.6:

While Meteor’s core implementation and many Atmosphere packages have had time to accommodate all these changes, or at least to verify that they don’t cause any problems, you should definitely use these change lists to audit your own applications, or to help debug any strange problems after updating. For example, if you use new Buffer(string, "utf8") in your code, you should now use Buffer.from(string, "utf8") instead.


Node.js 8.3.0 was the first version to use V8 6.0, which includes an all-new JavaScript interpreter and optimizing compiler, code-named Ignition and TurboFan, respectively.

Among many other performance benefits, this new JavaScript engine no longer penalizes “optimization killers” like trycatch blocks or certain usages of the arguments object. In other words, everything you thought you knew about V8 micro-optimizations is probably worth revisiting.

Some speak in numbers, others in doge

Long-term support

Node.js 8 entered long-term support coverage on 31 October 2017 🎃 😱 👻, and will enjoy that status through December 2019. Updating to Node.js 8 is a huge leap forward for Meteor, since Meteor 1.5 was still using Node.js 4, which is now in maintenance mode. Now that Meteor is up-to-date with Node.js versions, future Meteor releases will benefit directly from the latest development of Node.js and V8.

While Node.js 9 is now the “current” release, please note that odd-numbered Node.js releases are regarded as experimental. Meteor will likely update directly to Node.js 10 as soon as it reaches LTS status in October 2018.

Native debugging

Since we last wrote about the Meteor 1.6 debugging experience, the meteor debug command has been replaced by the more flexible --inspect and --inspect-brk command-line flags, which work for any runtest, or test-packages command. For more information on the syntax of the flags, run meteor help debug.

To give the new debugging experience a try after updating to Meteor 1.6, just run meteor --inspect-brk in any Meteor application directory. Then follow the instructions printed in the terminal to connect a debugging client like Chrome DevTools:

Paused at a breakpoint in Chrome’s native DevTools

Note that this is the actual, native Chrome DevTools UI, built right into the Chrome browser, not the old web-based UI provided by the node-inspectornpm package. That tool was impressive and indispensable in its day, but has become very much obsolete with Node.js 8. Progress!

Chrome DevTools isn’t the only option, though. If you use Visual Studio Codeto edit your code, you can debug your application within VS Code, using breakpoints set directly in your source files:

Paused at a breakpoint in Visual Studio Code

Note that you must configure a .vscode/launch.json file in order to make VS Code work with meteor --inspect-brk.

For that matter, you can even use the built-in Node.js command-line inspector, if you’re into that kind of thing:

Paused on a debugger keyword in the Node.js command-line inspector

Here’s a longer list of debugging clients known to work with Node.js 8:

Perhaps the most amazing benefit of the Node.js 8 inspector is that your code runs with no noticeable performance penalty, 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 means you can finally do realistic performance and memory profiling of your server-side code through the Chrome DevTools UI.

Far fewer Babel plugins

Node.js 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:

Among the most exciting new native features, async functions and awaitexpressions 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.

npm 5

The version of npm that ships with Meteor has been upgraded to version 5.4.2, a major upgrade from 4.6.1. While this update should be backwards-compatible for existing Meteor apps and packages, if you are the maintainer of any Meteor packages, pay close attention to your npm-shrinkwrap.json files when first using this version of npm.

For normal Meteor application development, this upgrade primarily affects the version of npm used by meteor npm ... commands.

Reproducible installs thanks to package-lock.json

It’s been an interesting year-and-a-half for npm clients. Once unrivaled as the tool of choice for installing npm packages, the npm tool faced some serious competition in late 2016 from an innovative tool called yarn, which promised fast, reproducible installs based on yarn.lock files.

This competition was a good thing for JavaScript developers, first because yarn solved some long-standing problems with npm, and later because [email protected] 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.

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.

meteor npx

In addition to meteor node and meteor npm, which are convenient shorthands for node and npmmeteor npx <command> can be used to execute commands from a local node_modules/.bin directory or from the npm cache. Any packages necessary to run the command will be automatically downloaded. Read more about npx, or just try some commands:

meteor npx cowsay mooooo
meteor npx uuid
meteor npx nyancat
meteor npx yarn

git required

Please note that a functional installation of git may be required to support installing npm packages from GitHub repositories and/or tarball URLs.


choco install meteor

On Windows, Meteor can now be installed or reinstalled from scratch using the command choco install meteor, using the Chocolatey package manager. This method of installation replaces the old InstallMeteor.exe installer, which had a number of shortcomings, and will no longer be supported.

Native 64-bit binaries

Fresh installs of Meteor 1.6 on 64-bit Windows machines will now use native 64-bit Node.js binaries, rather than a 32-bit version of Node.js. In addition to being faster, native 64-bit support will enable Windows developers to debug asynchronous stack traces more easily in the new Node.js inspector, which is only fully supported by native 64-bit architectures.

Note that merely running meteor update from a 32-bit version of Meteor will still install a 32-bit version of Meteor 1.6, so you should use choco install meteor to get a fresh 64-bit version.

Native file change notifications

After several reliability improvements, native file watching has been un-disabled on Windows. Though native file change notifications will probably never work with network or shared virtual file systems (e.g., NTFS or Vagrant-mounted disks), Meteor uses an efficient prioritized polling system as a fallback for those file systems.

What’s next

Although we decided to ship Meteor 1.6 before implementing all the new features we mentioned in the preview post, don’t worry: there will most definitely be a Meteor 1.6.1, 1.6.2, and so on. “What’s coming in Meteor 1.6” refers to the whole series of Meteor 1.6.x releases, if you will.

Docs, Guide, and website updates

We know that we have fallen behind on updating our docs, the Meteor Guide, and the tutorials on our website to reflect everything new in Meteor 1.6.

In addition to updating these information sources in the coming weeks, we plan to provide additional starter applications, such as one that uses React 16 with easy server-side rendering, dynamic import()React LoadableReact Routerstyled-components, and more. These things are all possible with Meteor today, we just haven’t put them together in one place yet.

Meteor 1.6.1

Even though Meteor 1.6 seems to be working well for most Meteor developers so far, we have already started a pull request for Meteor 1.6.1. We will keep that PR open until there is a compelling reason to cut a new release, at which point we’ll move on to 1.6.2. How often we release depends on how much of a need there is, so please communicate your needs to us!

As explained in the PR, there are several ways to keep track of what’s planned for Meteor 1.6.1, and how far along we are. Most notably:

If you think we’ve missed anything in these milestones (spoiler alert: we certainly have), please feel free to comment on issues that you believe should be included.

Beyond Meteor 1.6.x

It’s no secret that Meteor Development Group is deeply committed to the advancement of GraphQL as a next-generation data management technology, with all the resources we’ve invested into Apollo, the community we’re building, the conferences we’ve hosted, and the articles we’ve written.

The operative word in the previous paragraph is we. The Meteor framework and the Apollo libraries are two components of the same whole, bound together by the goal of improving developer productivity by an order (if not orders) of magnitude. This isn’t the first time we’ve talked about unifying Meteor and Apollo, but now that we’ve addressed some of the most critical blockers to Meteor adoption (for example, updating Node.js to the latest version), we can now focus on providing a coherent set of tools for building reactive, data store-agnostic web and mobile applications with GraphQL, without the typical headaches of modern JavaScript development.

While we have no plans to force existing Meteor applications to be rewritten to use Apollo and/or GraphQL, we believe that migrating away from Mongo and Livedata is the right path forward for most applications, and certainly the right place to start for newcomers to the Meteor platform.

We’ll be working with projects like Vulcan.js and soliciting feedback from our community at every step along the way. By the end of this process, Meteor may look less like a framework and more like a library of middleware that can be used in any existing application, JavaScript or otherwise. This vision deserves a whole series of blog posts, and keeping up with these changes may occasionally require a bit more effort than simply running meteor update. We promise that effort, and the results it brings, will be worth your while.


Today, however, there’s a remarkably good chance that meteor update is the only command you’ll need to run—that is, unless you’re a Windows developer, in which case you really should reinstall Meteor from scratch with choco install meteor, as described above.

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.1 pull request, or start a discussion on our forums, and we will do everything in our power to help make Meteor 1.6 work for you.

And of course, if Meteor 1.6 does work for you, we’d love to hear about that, too! Drop us a line in the comments below, or @meteorjs on Twitter.