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

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:

What’s coming in Meteor 1.6

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 History.md 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 1.5.2.2: 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 1.5.2.2 meteor-tool size: 545MB
• Known barriers to upgrading from Meteor 1.5.2.2: 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:

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 https://install.meteor.com/ | sh

Windows

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-app will create a new Meteor 1.6 application.

Windows

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 update without 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:

Know your Node.js

Notable changes

The jump from Node.js 4 in Meteor 1.5.2.2 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:

• Breaking changes between v4 and v5
• Breaking changes between v5 and v6
• Breaking changes between v6 and v7
• Changelog for v8

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.

Speeeeeeeed

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 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.

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.

NEWS: Node.js 8 Moves into Long-Term Support and Node.js 9 Becomes the New Current Release Line

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 run, test, 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:

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-inspector npm 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 Code to edit your code, you can debug your application within VS Code, using breakpoints set directly in your source files:

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:

Here’s a longer list of debugging clients known to work with Node.js 8: https://nodejs.org/en/docs/inspector/#inspector-tools-clients

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:

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.

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 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.

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 npm, meteor 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.

Windows

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 Loadable, React Router, styled-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:

• The meteor/meteor Release 1.6.1 milestone
• The meteor/meteor-feature-requests Meteor 1.6.1 milestone

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.

Conclusion

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.

Announcing Meteor 1.6 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Avoid overloading your servers while rolling out new versions

We’ve just rolled out a feature in Galaxy to allow containers to clean up resources as they are stopped, and we’ve published a package to allow Meteor apps to easily use this feature to gradually close client connections during deploy to avoid spikes of traffic to new containers. Read on for more detail on the feature who might find this useful.

Avoiding CPU usage spikes

When you deploy a new version of your Meteor app to Galaxy, we’ve always used a rolling restart to transition clients connected via Meteor’s Websocket-based DDP protocol from old containers to new containers. This means that all clients connected to a single container moved to new containers simultaneously when that container finishes shutting down and clients reconnect.

Some of our larger customers have found that this can lead to a large spike in CPU usage in their containers and database as many Livequery publications are started at once. Many of our users have found that transitioning their data layer to Apollo GraphQL from DDP/Livequery has reduced the statefulness of their servers and helped with these performance issues. But we know that many of you still enjoy using DDP/Livequery, so we built this feature to help you avoid these spikes during deploys and other container restarts.

Starting today, when Galaxy stops an app container (for example, because you’ve deployed a new version, or because we’re upgrading the underlying hardware), it will first send your container a SIGTERM signal and wait 30 seconds before killing the container. You can adjust that grace period from 10 seconds to 10 minutes on your app’s settings page.

We’ve published an npm package called @meteorjs/ddp-graceful-shutdown which you can easily add to any Meteor app (as long as you’re on at least Meteor 1.4). This package tracks incoming client connections on your server, and closes them one at a time, evenly spread out across your app’s grace period. Assuming the feedback is positive, we will likely make this be the default behavior of a future release of Meteor.

We hope this helps our larger users avoid overloading their servers when rolling out new versions!

One more thing: Improved Node 8 support for performance tuning

While we were improving our container environment to allow apps to receive signals, we’ve also updated the way that you can specify specific flags to Node in Galaxy, such as the V8 garbage collection flags that we recommend for performance. We now allow you to set these flags with the environment variable $GALAXY_NODE_OPTIONS as well as $NODE_OPTIONS, because Node 8 (which ships with Meteor 1.6) interprets the latter variable itself but exits with an error if it contains any of the V8 GC flags.

New in Galaxy: Gradual client transitions during deploys was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

A security bug affecting the Meteor APM agent (also known as “Kadira”) requires your attention

Meteor developers should be aware of a recently discovered security vulnerability. Please read this disclosure for full details and consult the Resolution section for the appropriate fix.

Description

A remotely-executable Denial-of-Service (DoS) attack has been discovered which affects applications utilizing Meteor Application Performance Monitoring (“APM”; formerly “Kadira”) through use of the mdg:meteor-apm-agent package or any similar "agent" package based on the original meteorhacks:kadira package, which transmit performance metrics to Galaxy Meteor APM, NodeChef Meteor APM, and similar services.

This vulnerability has been patched in the mdg:meteor-apm-agent package, which is maintained by Meteor Development Group, however packages maintained by other parties may need to patched. Please see the Resolution section below for an update which will prevent the attack.

Impact

While a default Meteor configuration using Meteor’s core packages is not automatically vulnerable, the attack becomes possible when certain Meteor packages are installed. Such packages include, but are not limited to:

• mdg:meteor-apm-agent
• meteorhacks:kadira
• Any package based on the meteorhacks:kadira package. Known public forks of that package are listed on the package's GitHub page, located at https://github.com/meteorhacks/kadira/network/members.

When a vulnerable version of an affected package is installed (whether or not it is configured), the attack payload can be delivered remotely. After the payload has been delivered, the application is likely to become unresponsive and will need to be restarted.

Additionally, after the attack, newly constructed JavaScript Objects might receive additional properties which would not normally have been present. These properties include: async, compute, count, db, email, errors, fetchedDocSize, http, sentMsgSize, total, and wait. Assertions or logic not expecting these additional object properties may raise errors or cause unpredictable behavior, including pollution of data and loss of APM data.

If an application does not use an affected package, we have no evidence the attack is possible.

Resolution

Any application using an affected package should update to a patched version. Two of the most common packages have already had the vulnerability patched, and their update instructions are included here for convenience.

Applications using mdg:meteor-apm-agent

The vulnerability has been fixed in version 3.1.1 of the mdg:meteor-apm-agentpackage. The command to update and patch the vulnerability is:

meteor update mdg:meteor-apm-agent

Applications using meteorhacks:kadira

We were not able to coordinate publishing of a patched version of the meteorhacks:kadira package with the package owner. Therefore, due to the popularity of this package, and with the best interest of the Meteor community in mind, Meteor Development Group has decided to publish a patched version of the meteorhacks:kadira package, without relying on the package author to do so.

Because of this action, the vulnerability has been fixed in version 2.30.4 of the meteorhacks:kadira package. The command to update and patch the vulnerability is:

meteor update meteorhacks:kadira

To review the changes we published, please consult the pull-request we submitted to the meteorhacks:kadira GitHub repository, which can be seen here.

Applications using other APM “agent” packages

Application developers should confirm that the package they are using has received the appropriate patch and update to the patched version of that package by using:

meteor update <package-name>

Maintainers of APM “agent” packages

Any package which was forked from meteorhacks:kadira should be patched. Maintainers of such packages should review the pull-request we submitted to the meteorhacks:kadira GitHub repository, which can be found here.

The changes supplied in that pull-request should be applied to the package source of the forked package, and the patched package should be republished using meteor publish. Once republished, any application using the package should be updated to the newly published version, using the above command.

Verification

After running the appropriate meteor update command, developers should verify that the latest version of the affected package was installed, either by examining the output of the command or by inspecting the application's .meteor/versions file.

Credit

Meteor believes in responsible disclosure of security vulnerabilities. We respect the hard work of security researchers who privately notify us with vulnerability details and appreciate the time they provide us time to address and resolve vulnerabilities prior to disclosing them publicly.

Credit for the discovery of this vulnerability goes to Adam Baldwin from Lift Security and Juho Hietala from Pacific Reach Advisors, Inc., who reported this issue to Meteor.

Please contact security@meteor.com to report a vulnerability in Meteor.

Denial-of-Service disclosure for Meteor APM/Kadira agent was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Babel 7, Cordova 7.1, Mongo 3.4, streaming server rendering, and more

Today we’re pleased to announce Meteor 1.6.1, an incremental release that’s packed with small improvements, as well as one important upgrade that requires special explanation: Babel 7

Meteor 1.6.2 is already well underway, because we didn’t get everything we wanted into Meteor 1.6.1. However, Meteor 1.6.1 was becoming quite a large release (486 commits, even more than Meteor 1.6), so we decided to shift gears, stabilize the moving parts, and release everything finished so far.

A note about versioning

If you’re not familiar with Meteor’s versioning conventions, releases like 1.5 or 1.6 are considered significant Meteor releases, meaning you should do everything in your power to upgrade your applications, because we’ve changed some very important aspects of how Meteor works.

Most software projects indicate major changes with versions like 2.0 or 16, but here at Meteor we’ve tried incredibly hard to preserve backwards compatibility ever since Meteor 1.0, so we’re saving “2.0” for a version of Meteor that requires profound changes to existing code. Until then, “minor” versions like Meteor 1.6 represent our most exciting releases.

According to this convention, Meteor 1.6.1 is an incremental release that fixes bugs and implements relatively conservative new features (relative to Meteor 1.6). Meteor 1.6.1 is a great version for starting a new application, and should be an appealing update if you’re already on the latest previous version (1.6.0.1), though it is not absolutely obligatory. Speaking of Meteor 1.6.0.1, a four-digit version represents a minimal patch release that fixes a critical problem for some set of Meteor developers, such as a security update to a bundled dependency like Node.js.

In other words, you should update to Meteor 1.6.1 if it fixes a problem for you, or you need any of the new features it provides, or just because you feel like staying up to date, after consulting the release notes or reading the rest of this blog post to get the highlights.

By the numbers

• Weeks of active development and testing: 12
• Unique pull request participants: 36
• Pull request comments: 76
• Reactions to PR comments: 61 👍, 10 🎉, 11 ❤️, 1 😄 , 0 😕, 0 👎
• Commits since Meteor 1.6.0.1: 486
• Lines of code added: 20,825
• Lines of code removed: 31,149
• Closed issues in the Release 1.6.1 milestone: 57
• Beta releases: 22
• Release candidates: 11

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

Mac and Linux

curl https://install.meteor.com/ | sh

Windows

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

choco install meteor

How to upgrade

Mac, Linux, and Windows

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

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.

Babel 7

By far the most noticeable change in Meteor 1.6.1 is that we’ve upgraded the version of Babel used for compiling ECMAScript package and application code from 6.24.7 to 7.0.0-beta.38. Yes, that’s a beta version, but we believe that’s acceptable for several reasons:

• We will be able to republish the babel-compiler and ecmascript packages to use a non-beta version of Babel whenever 7.0.0 is finalized, without having to publish a new Meteor release.
• Other projects, such as React, have already begun to recommend Babel plugins that depend on Babel 7, such as @babel/plugin-transform-react-jsx: https://reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html#babel
• Meteor has been using beta versions of Babel to implement the meteor command-line tool ever since Meteor 1.6, which has given us a chance to identify and fix the handful of problems we’ve encountered so far.
• By leveraging the abstractions of meteor-babel and babel-preset-meteor, as well as shrink-wrapping all of their dependencies, Meteor is able to provide a consistent core of well-tested Babel plugins, which shields Meteor developers from much of the complexity of the changing Babel plugin ecosystem.

What to expect

Although we are confident in the future of Babel 7, it would be misleading to suggest this upgrade will be seamless for all Meteor developers. Here are some of the problems you might encounter:

@babel/runtime (severity: 🌤)

The babel-runtime npm package has been required for all Meteor applications since Meteor 1.3. With Babel 7, babel-runtime has been renamed to @babel/runtime. If you update to Meteor 1.6.1 without adding @babel/runtime to your package.json dependencies, the Meteor babel-runtime package will throw a helpful error that recommends running meteor npm install @babel/runtime. You should follow this advice!

This change of names is in fact pretty convenient, because it allows @babel/runtime to be installed alongside babel-runtime, in case you need both for some reason; for example, if you rely on a custom Babel plugin that still assumes babel-runtime is installed.

Most Meteor developers should be able to remove babel-runtime after adding @babel/runtime, though there’s no harm in leaving it installed, since none of its modules will be bundled unless they’re used.

Atmosphere package version conflicts (severity: ⛈)

The major version of the Meteor babel-compiler package has been bumped to 7.0.0, which may be incompatible with existing Meteor packages that explicitly depend on an earlier version of babel-compiler. Version constraints in Meteor typically specify a minimum version, and otherwise constrain only the major version, allowing the minor and patch versions to change. In this case, however, we’ve changed the major version of babel-compiler, which is likely to produce some conflicts.

If you are the author of a Meteor package that depends on babel-compiler, and you have determined that the update is compatible with your package’s previous usage of babel-compiler (give or take any tweaks you might need to make), you can make your package compatible with either Babel 6 or Babel 7 by using the || version constraint syntax:

Package.onUse(function (api) {
  ...
  api.use("babel-compiler@6.19.4||7.0.0");
  ...
});

This approach has been working well for the coffeescript-compiler package, for example. Speaking of CoffeeScript, while Meteor 1.6.1 was under development, a new major version of the coffeescript and coffeescript-compiler packages were released (most recently 2.0.3_4), which is worth mentioning for the same reason as the babel-compiler@7.0.0 upgrade: packages like practicalmeteor:mocha that depended on a 1.x version of coffeescript may need to be updated or replaced. Specifically, we have found meteortesting:mocha to be a good choice.

Unfortunately, conflicting version constraints may originate from Meteor packages that are not actively maintained, in which case you may need to take matters into your own hands. Fortunately Meteor makes this possible: simply clone the package into your local packages/ directory and then modify the code as necessary, likely by relaxing version constraints in its package.js file, but also by making other necessary changes to the package. Your local copy of the package will take precedence over the Atmosphere version.

If your changes seem like they should become part of the original package, please submit a pull request to the upstream project. If the package author is not responsive, it may be time to find an alternative package that is more actively supported. However, this technique of modifying a local clone of a package is a powerful way to solve a variety of problems with Meteor packages that you didn’t write.

Outdated custom .babelrc plugins (severity: 👾)

If your team has added custom Babel plugins to a .babelrc file, now is a good time to make sure they all work with Babel 7. In particular:

• Please revisit the use of any presets like babel-preset-es2015 or babel-preset-env, as Meteor provides similar functionality via babel-preset-meteor. Redundant presets waste compilation time (at best) or introduce bugs (at worst) because not all plugins can safely run twice. Here’s a recent example of a Babel bug stemming from redundant Babel plugins. Instead, you should rely as much as possible on the defaults provided by Meteor, and carefully add individual plugins as needed, rather than blindly adding plugins or presets that you may not need. That might have worked in the past, but Babel 7 could expose hidden problems.
• If you’re using an official Babel plugin such as babel-plugin-transform-decorators, there’s a good chance it has been renamed to something like @babel/plugin-proposal-decorators. This blog post details the rationale behind this renaming, and may help you guess what the package is now called. Otherwise, you can search for the old package name here, and then look for the new package name in the current package.json file.
• Please refer to this blog post for general guidelines for upgrading to Babel 7, especially if you encounter problems after updating to Meteor 1.6.1.

We can provide assistance via GitHub issues, but please be aware that Meteor cannot guarantee the functionality of arbitrary .babelrc configurations. When you depart from the core Babel functionality provided by Meteor, you embrace the additional maintenance burden, for better or worse. We’re depending on you to appreciate the difference between a problem that Meteor can solve and a problem inherent in the complexity of your custom configuration.

Don’t panic!

However annoying it may be in the short term, updating to Babel 7 is a worthwhile investment of your time, since the Babel project has historically expected developers to be using the latest version, and does not typically back-port bug fixes to the previous version. We’ve tried to make this transition as easy as possible, and we hope that effort shows. We’re here to help, you’re not alone, and we greatly appreciate your patience with this process.

Other improvements

Instead of enumerating the many other changes in this release, we encourage you to read the release notes.

We’ve updated Cordova, Mongo, and many of the npm packages used by Meteor packages and the meteor command-line tool. Dynamic import() now uses HTTP POST requests. Thanks to James Baxley III, the server-render package now supports passing a Stream object to ServerSink methods that previously expected a string, which enables streaming server-side rendering with React 16:

import React from "react";
import { renderToNodeStream } from "react-dom/server";
import { onPageLoad } from "meteor/server-render";
import App from "/imports/Server.js";

onPageLoad(sink => {
  sink.renderIntoElementById("app", renderToNodeStream(
    <App location={sink.request.url} />
  ));
});

If we missed something in the release notes, or you notice something that deserves a shout-out here, let us know in the comments below!

What’s next

Now that Meteor 1.6.1 has been finalized, it’s time to turn our attention to all the exciting work we put off until Meteor 1.6.2:

• https://github.com/meteor/meteor/milestone/47
• https://github.com/meteor/meteor-feature-requests/milestone/3

I’m especially excited about pull request #9439, which promises to reduce bundle sizes dramatically for modern browsers and Node, and enable truly native async/await (and other ECMAScript features) in the browser.

Conclusion

As long as your application is committed to version control, so that you can roll back in case of problems, there’s no harm in running meteor update to see what happens. Who knows; you might not even notice the Babel 7 update. Your application is unique among all Meteor applications.

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.2 pull request, or start a discussion on our forums, and we will do everything in our power to help make Meteor 1.6.1 (or at least Meteor 1.6.2) work for you.

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

Announcing Meteor 1.6.1 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re excited to announce new Galaxy features and docs which provide more flexibility for our advanced users.

Run anything in your container with custom base images

Galaxy provides a zero-configuration way to deploy your Meteor apps to the cloud. But sometimes you need a little configuration. For example, you may want to call native libraries that aren’t distributed via npm, or include some large files in your container that you don’t want to upload every time you run meteor deploy.

Galaxy containers are built using the standard Docker container management platform. Every container is built by adding your uploaded app code to a “base image”. Up until now, every Galaxy app shared the same base image: a Ubuntu Linux 14.04 environment with a handful of extra packages requested by customers. Most of these popular packages were native dependencies required by npm modules, primarily for image rendering. Because every app shared the same base image, we couldn’t easily upgrade these packages without possibly breaking other customers, and so these packages have not been updated since 2016.

We’re excited to announce a better way to bring non-npm dependencies into your Galaxy app: custom base images! You can now request that Galaxy use any Docker image publicly available on Docker Hub as a base image, as long as the image contains a script that that can import your uploaded app. Full details are available in the Galaxy Guide. You can also check out the newly-released source to the default base image.

While our main goal with this feature is to enable Meteor users to deploy apps that require OS-level dependencies to install, we look forward to hearing how our customers will take advantage of this flexible feature. For example, you could use this to run non-Meteor code in your container alongside your app, or to run worker nodes built on other platforms in their own Galaxy app alongside your main Meteor app. This feature was built by Changping Chen during his internship at MDG!

Unlimited log history and flexibility with custom log storage

Galaxy lets you view and search your logs with zero configuration on the Logs tab on your app’s dashboard. However, Galaxy only retains one week of app logs, and the dashboard logs viewer only offers basic search features. Customers interested in more detailed log access can now enable custom log storage!

With custom log storage, Galaxy can stream logs to any Elasticsearch server. It’s easy to set up your own server with hosted services like Elastic Cloud or Amazon Elasticsearch Service or on your own infrastructure. Because logs are hosted on your own servers, you can use any Elasticsearch tool to investigate your logs, like Kibana, and you can set your own expiration policy. Even with custom log storage enabled, we’ll still keep track of your last week of logs on our dashboard.

Detailed docs on what’s under the hood

As part of documenting the custom base images feature, we’ve greatly expanded our documentation of exactly what happens when you typemeteor deploy, including our container image build process and health checking. Find out more about our default base image, building custom base images, and the container execution environment.

If you aren’t using Galaxy to deploy your Meteor apps yet and the features above sound exciting, give it a try today!

New in Galaxy: custom base images and custom logging! was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lessons learned after three years

This is a guest post by Philip Johnson, Professor of Information and Computer Sciences at the University of Hawaii.

I have taught software engineering at the University of Hawaii for over 25 years at both undergraduate and graduate levels. As is typical for a software engineering curriculum, my approach mixes conceptual knowledge (software quality assurance, configuration management, testing, project planning, etc.) with practical experiences doing team-based software development. For many years, the practical side of the course involved a community project and I allowed students to pick their own technology stack.

Around 2010, I realized that the “choose your own technology stack” approach meant that students, instead of spending the final part of the course learning about software engineering, were instead spending the final part of the course learning the basics of how to use their technology stack. And since different groups were picking different technology stacks, and since they were left to their own devices for learning, this made the final part of the course somewhat chaotic and most final projects were unsatisfying.

So, I redesigned the course to integrate the learning of a single software development technology stack along with basic software engineering concepts. I chose web-based application development as the focus, and initially chose the Stripes web application development framework since it was Java-based, and my students all had a background in Java. In a subsequent semester I switched to Apache Wicket, and after that to the Play Framework.

My experience with the Play Framework was generally positive, with a few caveats. First, while it is possible to develop the business logic in Java, the user interface templates required basic knowledge of Scala. And, of course, any dynamic UI behavior requires a third language: Javascript. Second, wiring up the framework to a backend relational database is cumbersome, and most of my students did not yet have any relational database experience. Third, the amount of boilerplate code seemed high relative to, say, Ruby on Rails, which was extremely popular at that time. I didn’t want to switch to Ruby on Rails because I didn’t want my course to degenerate into a class on learning a new programming language (Ruby) and framework (Rails) which would swamp the true purpose of the course (software engineering).

In 2015, I discovered Meteor (then at version 1.0) while attending a Hackathon, and switched to it the very next semester. At that time, Meteor seemed to me to provide several compelling advantages as a technology stack for teaching software engineering:

• Just one language. Rather than Java+Scala+Javascript, or Python+Javascript, or YourFavoriteLanguage + Javascript, Meteor was just Javascript. I would have to spend a couple of weeks introducing JS at the beginning of the semester, but that seemed like time well spent for the students.
• Mongo, not MySQL. For students who haven’t yet had a database class, Mongo is way easier to get started with than a standard RDBMS. For example, there is no object-relational impedance mismatch, which bedevils students trying to build apps in Java and MySQL.
• Built-in accounts management. Getting accounts management “for free” eliminates a significant amount of boilerplate that students recreated (badly) every semester in every project.
• Simple, free deployment. In 2015, you could deploy your app to MDG’s servers with a single command, for free. This was significantly more simple than the Heroku-based deployments students used for Play applications.
• Discover Meteor. In 2015, there was an excellent, up to date, book-length introduction to Meteor that provided significantly more detail for novices than the short To-Do app tutorials now provided by MDG.
• Pub/Sub, not Request/Response. OK, to be honest, I was not sure that Pub/Sub would be any simpler to teach than Request/Response, but I thought it was a super cool idea and could be the future of web application client-server communication.

It’s now 2018, and I’ve taught the Meteor version of my class about six times to over 200 students. Here are five lessons I’ve learned from the first three years.

(1) Modern Javascript is a great language for teaching software engineering. Who would have thought that would be true 5 or 10 years ago? I even created a somewhat tongue-in-cheek screencast called 7 reasons why Javascript is better than Java and C++ to help my students (who came from one of those two backgrounds) better understand why Javascript is now more than just a “scripting language for web pages.”

(2) Meteor’s evolution since 2015 has made it a better framework for application development, but harder for novices to learn. In 2015, things were relatively simple: you put your code into the client/, server/, or lib/ directories; you used Blaze for your UI; and you went to Atmosphere for all your third-party needs. In 2018, you should use the imports/ directory, you need to choose between Blaze, Angular, and React, and NPM is preferred over (but does not replace) Atmosphere. Note that this velocity of evolution makes it much harder for novices to use Google to solve problems they encounter with Meteor; often the “solutions” presented do not reflect current best practices, even if they are only a couple of years old, and the Meteor Guide cannot cover every single problem a novice will encounter.

(3) The demise of Discover Meteor makes it harder for novices to get up to speed. I don’t know of any resource for current novices that provides the same detail about best practices as Discover Meteor did in 2015. Making Discover Meteor free, while admirable, does not solve the problem; too much of the book is out-of-date. If it could be made a community resource that complements the Meteor Guide and that could be kept up to date with current best practices, that would be a huge win for novices.

(4) Windows is not great for teaching Meteor. And most of my students use Windows. To be fair, Meteor is not alone with respect to this issue: Ruby on Rails is also somewhat Windows-unfriendly. But I have a few students every semester who come to hate Meteor simply because it is so slow and/or error-prone on their Windows laptop.

(5) React might be easier to teach novices than Blaze. After five semesters of teaching Meteor using Blaze, I switched to React this semester. Although I assumed React would be more complicated for students to learn, I felt that the ubiquity of React made it an important skill for students to acquire and worth the extra investment of time. To my great surprise, I am finding that React is potentially easier for students to learn than Blaze! To understand why, consider that when teaching Meteor using Blaze, the sequence of modules looks like this:

Basic HTML/CSS > Semantic UI > Basic Meteor + Semantic UI + Blaze

In other words, students have to intermix the learning of Blaze with the learning of Meteor, because Blaze does not exist outside of Meteor. Furthermore, using Semantic UI with Blaze creates additional complications (mostly around the need for JQuery for certain constructs).

Here’s how I teach it this semester:

Basic HTML/CSS > Semantic UI > Semantic UI/React > Basic Meteor

For a novice, this progression is easier to learn, because it’s possible to learn both basic React as well as the excellent Semantic UI/React framework before ever touching Meteor. Just as importantly, the Semantic UI/React framework not only eliminates the complications of Semantic UI with Blaze, it actually simplifies the use of React itself in many situations!

In summary, after three years of teaching Meteor, I still believe that it offers an excellent technology stack with which to introduce students to software engineering. I am quite hopeful that the rapid and sometimes disruptive evolution in design and architecture that Meteor experienced over the past three years will abate during the next three years, enabling the documentation of best practices to catch up. This, in turn, will make it easier to “on-board” novice developers such as those in my software engineering classes.

Teaching software engineering with Meteor was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hear about Meteor 1.7, cutting-edge Meteor tooling, and production stories

It’s been a minute, but Meteor Night is back! Huge thanks to Lucas Hansen and Qualia, who are going to start hosting the event regularly. The first one is coming up next week, and Ben Newman from the Meteor team and prolific package developer Theodor Diaconu will be flying into San Francisco to speak at the event!

Here’s what you’ll hear about:

• Lucas Hansen, CTO of Qualia: “10,000 Hours Into Meteor”. You’ll hear about Qualia’s extensive experience running Meteor in production, and some of the awesome tooling they’ve built for it in-house.
• Theodor Diaconu, CEO of Cult of Coders: “Redis Oplog, Grapher, and Apollo Live”. Theodor and Cult of Coders have built some of the coolest new tools for the Meteor community, and you’ll get to hear all about them!
• Ben Newman, Tech Lead of the Meteor: “Meteor 1.7”. Meteor 1.7 is one of the most exciting releases ever, with a new system that eliminates some of the tradeoffs between compatibility and performance that developers have had to make in their apps for years. Hear all about it at Meteor Night!

As always, there will be food, drinks, and hanging out! The event is at Heavybit at 325 9th Street in San Francisco.

Sign up on Meetup if you’re going:

Meteor Night

You don’t want to miss this meetup to learn more about what’s going on in the Meteor community, and what cool new stuff is coming up. I’ll be there, and hope to see you and talk about Meteor!

Come to Meteor Night on May 30 in San Francisco! was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Differential modern/legacy browser bundling, selective compilation of node_modules, and more

The future is already here — it’s just not very evenly distributed.
– William Gibson (c. 1993)

If you’ve spent any time developing web applications with JavaScript in recent years, you’ve been promised a future that never seems to arrive.

More than 80% of Internet users worldwide have access to an “evergreen” web browser that natively supports almost all the latest ECMAScript features and keeps itself updated automatically, which means new language features become available almost as soon as they are standardized. Take a moment to appreciate this new reality, since it has profound consequences for web development. Now that so many ECMAScript features are natively supported in the overwhelming majority of web browsers (and Node), it is increasingly a shame that you can’t just execute modern JavaScript directly, without first compiling it to JavaScript of yesteryear.

If you’ve ever dreamed of using native async functions in modern browsers, but the thought of abandoning support for older browsers made you (rightly!) uncomfortable, Meteor 1.7 has exactly the solution you’ve been looking for.

Going evergreen without leaving nevergreen users behind

The future we envisioned when we first began compiling code with Babel is finally here, or at least almost finally here, and yet most web frameworks and applications still compile a single client-side JavaScript bundle that must work simultaneously in the oldest and the newest browsers the application developer cares to support, holding the vast majority of users hostage to the needs of ancient Internet Explorer and Safari versions.

Though the market share of legacy browsers is shrinking, it is not yet anywhere near zero, and those users who cannot or will not update have already resisted years of recommendations, scolding, and pleading. Like it or not, these users are equal members of the World Wide Web, and we web developers must accommodate their needs. However, we do not have to let legacy limitations dictate how our websites work in modern browsers.

The Slow Death of Internet Explorer and the Future of Progressive Enhancement

Delivering both modern and legacy assets poses a daunting challenge: not only must you build multiple JavaScript and CSS asset bundles for different browsers—with different dependency graphs and compilation rules and webpack configurations—but your server must also be able to detect the capabilities of each visiting client, so that it can deliver appropriate assets at runtime. Testing a matrix of different browsers and application versions gets cumbersome quickly, so it’s no surprise that responsible web developers would rather ship a single, well-tested set of static assets, and forget about taking advantage of modern JavaScript features until legacy browsers have disappeared completely.

Make let not var #javascript #es2015 #es6

 — @ireaderinokun

If you resign yourself to this gloomy way of thinking, and you run the same code in Chrome 68 as you do Internet Explorer 8, not only will the latest technologies remain always just beyond your reach, but you will miss out on some basic quality-of-life improvements that are nearly universally supported, such as const and let declarations that raise warnings (unlike var) when you use a variable before it has been initialized. You’ll also be shipping many more kilobytes of code to modern browsers than they need, slowing down initial page load times, which has well documented negative effects on user behavior.

To our knowledge, Meteor 1.7 is the first full-stack JavaScript application framework to offer a solution for the problem of differential compilation and asset delivery, so you may not have realized any of this was feasible until reading this blog post. If you did have an inkling that such a system was possible, or you think you have a better solution than the one we will describe below, we welcome your feedback! We fully anticipate that other frameworks will take their own approach to solving these problems, and we’re eager to see how they do it.

Meteor 1.7: The best of both bundles

With Meteor 1.7, the awkward balancing act of building a single bundle for both the newest and the oldest web browsers is no longer necessary. Meteor now automatically builds two sets of client-side assets, one tailored to the capabilities of modern browsers, and the other designed to work equally well in all supported browsers, so that legacy browsers can continue working exactly as they did before. This “legacy” bundle is equivalent to what Meteor 1.5 and 1.6 delivered to every browser, so the crucial difference in Meteor 1.7 is simply that modern browsers will begin receiving code that is much closer to what you originally wrote.

Best of all, the entire Meteor community relies on the same system, so any bugs or differences in behavior between the bundles can be identified and fixed quickly, and everyone will benefit from those refinements.

In this system, a “modern” browser can be loosely defined as one with full native support for async functions, which includes more than 80% of the world market, and 85% of the US market (source). This standard may seem hopelessly optimistic, since async/await was only recently finalized in ECMAScript 2017, but the statistics clearly justify it. And just in case you’re wondering what that percentage looks like for less ambitious ECMAScript features, a mere 87% of browsers support native class syntax. The lesson here: you cannot aim low enough to make Internet Explorer happy, so you might as well aim high.

The precise boundary between modern and legacy browsers is designed to be tuned over time, not only by the Meteor framework itself but also by each individual Meteor application. For example, here’s how Meteor currently guarantees that every modern browser supports native ECMAScript class syntax, so the babel-compiler package can avoid compiling class syntax when targeting the modern bundle:

import {
  setMinimumBrowserVersions,
} from "meteor/modern-browsers";

setMinimumBrowserVersions({
  chrome: 49,
  firefox: 45,
  edge: 12,
  ie: Infinity,
  mobile_safari: [9, 2],
  opera: 36,
  safari: 9,
  electron: 1,
}, "minimum versions for ECMAScript 2015 classes");

The minimum modern version for each browser is simply the maximum of all versions passed to setMinimumBrowserVersions for that browser. The Meteor development server decides which assets to deliver to each client based on the User-Agent string of the HTTP request. In production, different bundles are named with unique hashes, which eliminates the possibility of cache collisions, though Meteor also sets the Vary: User-Agent HTTP response header to let well-behaved clients know they should cache modern and legacy resources separately.

Managing modern/legacy code in Meteor packages and applications

Although you reap many of the benefits of the modern/legacy system just by updating to Meteor 1.7, you can also create your own Meteor packages and application modules that take advantage of differential bundling.

If you’ve written a Meteor package before, the following package.js code should be familiar:

Package.onUse(api => {
  api.mainModule("client.js", "client");
  api.mainModule("server.js", "server");
});

This code still works in Meteor 1.7, though it means the client.js module will be loaded by both the modern and the legacy bundle. If you need to load different code in the different client bundles, you can split the client.js module into a modern.js and a legacy.js module, and then add them to the web.browser and legacy targets, respectively:

Package.onUse(api => {
  api.mainModule("modern.js", "web.browser");
  api.mainModule("legacy.js", "legacy");
  api.mainModule("server.js", "server");
});

The same targeting rules also apply to api.addFiles and api.addAssets.

🆕 In Meteor 1.7 applications, it’s now possible to specify custom entry point modules in the "meteor" section of your package.json file:

{
  "name": "your-app",
  "dependencies": {...},
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    }
  }
}

This meteor.mainModule configuration allows you to override Meteor’s default rules for eagerly loading modules. Whereas previously you would have to put modules in an imports/ directory in order to prevent them from being eagerly evaluated, when you use meteor.mainModule to specify entry points, all other modules besides the entry points will be loaded lazily. In other words, you no longer need an imports/ directory, and Meteor’s module loading behavior will work more like non-Meteor Node projects.

The same technique we used with api.mainModule in package.js to specify different client entry points for modern and legacy bundles also works for meteor.mainModule:

{
  "name": "your-app",
  "dependencies": {...},
  "meteor": {
    "mainModule": {
      "web.browser": "client/modern.js",
      "legacy": "client/legacy.js",
      "server": "server/main.js"
    }
  }
}

If you decide to use a modern JavaScript feature that is not supported natively by all browsers that support async/await, such as Service Workers, please remember to call setMinimumBrowserVersions to enforce your personal assumptions about which browser versions should be considered modern:

import {
  setMinimumBrowserVersions,
} from "meteor/modern-browsers";

setMinimumBrowserVersions({
  chrome: 45,
  firefox: 44,
  edge: 17,
  ie: Infinity,
  mobileSafari: [10, 3],
  opera: 32,
  safari: [11, 1],
  electron: [0, 36],
}, "service workers");

Although these new minimum versions may prevent some recent versions of Safari from receiving the modern bundle, they will ensure that every modern browser has a native implementation of Service Workers. Useful resources for determining appropriate minimum versions include caniuse.com, Mozilla’s MDN documentation, and the electron-to-chromium npm package.

If you include a particular module in both the modern and the legacy bundle, but it contains some code that should run in only one of these bundles, you can dynamically detect which bundle is active by referring to the Meteor.isModern boolean flag:

if (Meteor.isModern) {
  // Do something that's only safe in modern browsers
} else {
  // Do something that's safe in all browsers
}

However, you should avoid Meteor.isModern if possible, since modern syntax can't be guarded with conditional statements, and both code paths will appear in both bundles, which defeats the purpose of differential bundling.

Impact on bundle sizes

Because the modern bundle is compiled by the babel-compiler package with far fewer Babel plugins than the legacy bundle, and needs far fewer polyfills from the ecmascript-runtime-client package, the modern bundle should benefit from improved performance of native JavaScript features, and will also be considerably smaller than the legacy bundle.

🆕 Beginning with Meteor 1.7, when you create a new Meteor application, you can pass the --minimal option to meteor create to produce an application that uses as few Meteor packages as possible, so the modern client bundle will be as small as possible:

Minimal Meteor app

If you use the bundle-visualizer package (introduced with Meteor 1.5) with this minimal application, you will see both bundles represented in the same sunburst chart. Notice that the modern bundle is approximately 1/3 the size of the legacy bundle, or about 16KB after gzip. Smooshing both bundles into the same sunburst may not be the best way to display this data, but it certainly drives home how much smaller the modern bundle tends to be:

To get a better sense for the breakdown of the bundles, visit https://meteor-night-bundle-visualization.meteorapp.com/ and hover your cursor over the various segments.

Please note that your immediate savings may not be quite this dramatic. For example, when we updated https://engine.apollographql.com to Meteor 1.7, we saw only an 8% reduction in bundle size, since much of the code used by that application comes from node_modules, which Meteor does not (re)compile by default.

Selective compilation of node_modules

Speaking of compiling node_modules, one of the fundamental reasons why differential compilation and bundling is so difficult in the npm ecosystem is that npm packages are precompiled before they are published to npm, so consumers of npm packages typically have to settle for whatever compilation strategy the package author decided to use. Even if the package author publishes multiple builds of their package, the compilation strategy might not be exactly what you want.

More and more npm package authors are publishing their source code along with ready-to-use, precompiled code, and that’s great news for application developers who want to take matters into their own hands. However, a blanket policy of recompiling every package in node_modules is dangerous because it’s not uncommon for a node_modules directory to contain hundreds of megabytes of data. Instead, most bundling tools require the application developer to configure which npm packages should be recompiled. The ideal configuration API for this task is an extremely contentious unsolved problem in the JS community. Meteor 1.7 gamely joins this ongoing conversation with an answer of its own.

In Meteor 1.7, if you want to control how an npm package is compiled, or if you just want Meteor to compile the package for modern/legacy browsers and Node, here’s what you should do:

• Clone the package repository into your application’s imports directory (that is, if you’re still using an imports directory)
• Make any modifications necessary to compile the package to your liking, such as adding/modifying a .babelrc file or altering the "main" field of package.json to point to src/index.js instead of lib/index.js
• Use meteor npm install imports/the-package to link the package into node_modules

For ease of updating the package in the future, we recommend using a Git submodule to manage the cloned package repository:

# Clone the package as a git submodule
git submodule add \
    git@github.com:visionmedia/superagent.git \
    imports/superagent

# Tweak imports/superagent, and commit any changes locally

# Creates a symbolic link at node_modules/superagent
meteor npm install imports/superagent

This works by exposing the package source code as part of your Meteor application, outside node_modules, so that Meteor’s compiler plugins can process the code. Often no modifications will be necessary, since the recompilation performed by Meteor takes care of everything for you. If you really need complete control, though, you’ve got it. 👩‍🔬🔬💪

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

Mac and Linux

curl https://install.meteor.com/ | sh

Windows

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

choco install meteor

How to upgrade to Meteor 1.7

Mac, Linux, and Windows

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

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.

Release notes

As usual, the full release notes for Meteor 1.7 (and now Meteor 1.7.0.1) can be found in our History.md document.

In addition to running meteor update, you will almost certainly want to install the latest versions of the @babel/runtime and meteor-node-stubs npm packages:

meteor npm install @babel/runtime@latest
meteor npm install meteor-node-stubs@latest

If you’re using Mongo, note that Meteor 1.7 now ships with Mongo 3.6.4, which may require migrating your Mongo 3.2 development database. In general, if you’re comfortable just deleting and recreating your development database, you can use meteor reset to avoid migration headaches.

We are still working on a more complete upgrade guide. Please feel free to ask questions in the comments below, or consult the Meteor forums, or open an issue on GitHub. We’re here to help!

Further reading

If you prefer a slideshow to a blog post, check out this talk I (Ben Newman) gave at Heavybit Industries on May 30th:

Meteor 1.7 by benjamn

We will update this blog post once the video from this talk becomes available, though that may take another week or so.

In summary

We think this modern/legacy bundling system is one of the most powerful features we've added to the Meteor framework since we first introduced the ecmascript package in Meteor 1.2 in September 2015, and we wish other frameworks and bundling tools the best of luck finding their own ways to deliver different assets to modern and legacy browsers, without burdening their developers with the tremendous technical debt that would come from building a system like this from scratch. In the spirit of community and collaboration, we genuinely hope our implementation provides some essential clues to developers who aren’t using Meteor.

Based on recent conversations with Yehuda Katz, we anticipate Ember will be the next framework to provide this kind of functionality. As a highly opinionated full-stack web framework, Ember shares many of Meteor’s super-powers, and we fully expect them to teach us a lesson or two about the right way to do differential bundling.

In the meantime, if you’ve ever been tempted to give Meteor a try, there’s never been a better time to get started. 💫

Meteor 1.7 and the evergreen dream was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a guest post by Timo Horstschaefer, co-founder of Ledgy.com, the missing accounting software for your cap table—built with Meteor.

At Ledgy, we deeply care about our customer’s security and privacy. This is why we implemented a new two-factor authentication (2FA) system for Meteor.

This two-factor authentication system is based on the Time-based One-Time Password algorithm (TOTP), which is supported by a number of popular mobile apps like Google Authenticator, Duo and Authy.

Our implementation uses the fairly new otplib and adds a new login method to Meteor in order to pass the TOTP token along with the username and password.

This tutorial covers only the backend-code, meaning the methods for Meteor in order to activate 2FA and perform the login. The front-end is highly custom for each application and thus not covered by this tutorial.

The workflow for two-factor authentication goes as follows:

Setup

1. Generate a secret key on the server, store it in the user’s profile and send it to the client.
2. The user has to scan a QR code containing the secret with their 2FA app.
3. The user enters a token generated by their 2FA app to confirm the setup.

Login

1. The client calls the login method with a username and password.
2. If the login is successful, but 2FA is enabled, the server returns 'two-factor-required', indicating that it needs further information.
3. The client calls the login method again, now with username, password, and the time-dependent token from their 2FA app.

The Code

The first method we need to implement handles generating the secret and storing it in the user’s profile as services.twoFactorSecret:

In the next step, using their 2FA app, the user scans the QR code which contains the secret key along with some metadata generated by otplib. If you use React, qrcode.react might be a good choice for generating the QR code on the client and prevent the browser from keeping the generated image in the cache. This isn’t a fully functional example, but on the front-end, this could look something like:

import otplib from 'otplib';
import QRCode from 'qrcode.react';

const render = () => {
  const otpauth =            // String must be URI-encoded
    otplib.authenticator.keyuri('Elon%20Must', 'Ledgy', secret);

  return (
    <QRCode value={otpauth} level="H" size={256} />
  );
}

In order to finalize 2FA activation, we’ll create a new server method that accepts a six-digit code from the user’s newly-activated 2FA app and, if correct when checked by the server, marks the account as “two-factor enabled”. This last verification step is important to ensure that the user has a functioning 2FA application, otherwise we’d end up locking them out of their account! We’ll store the fact that their account is two-factor enabled using a read-only boolean on the user’s record called twoFactorEnabled (i.e. Meteor.user().twoFactorEnabled).

We will never send the actual secret back to a client after the initial setup, so once the QR code is gone, it should never be shown to the user again.

We strongly recommend, that the actual image is generated on the client side to prevent potentially dangerous caching by the browser.

Logging In

Now that the setup part is done, let’s look at the login. Since Meteor doesn’t support a login method which accepts a TOTP code along with the password, we need to register our own. This is the centerpiece and most critical part of the two-factor authentication:

Note: For simplicity, this method only allows login by email. It currently does not support login by username or userId.

The only missing piece now is to call our new login method on the client. For this, we use the function Accounts.callLoginMethod(). The code will look somewhat like this (but again, it depends on your front-end):

Well, that’s it! Now you have modern, two-factor authentication using TOTP.

If you manage a startup company and want to use an online cap table tool, then you can see this code in a real application. Just visit our website Ledgy.com and sign up. I hope you enjoyed the tutorial!

The missing accounting software for your cap table

Tutorial: Two-factor authentication with Meteor and TOTP was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Delayed legacy builds, lazy plugins, meteor create --react, Babel 7, Mongo 4, and more

It’s no secret that rebuild times increased with Meteor 1.7. Building an entirely new client bundle for legacy browsers takes time, after all. We were fully aware of this performance regression when we released Meteor 1.7, yet the promise of liberating modern browsers from the oppressive constraints of legacy compatibility seemed worth incurring some technical debt, as long as we had a plan for paying down those debts in the future.

Well, it’s the future now, and Meteor 1.8 is the culmination of that plan.

Not only have we eliminated many of the performance problems specific to Meteor 1.7, we also dug deep into the historical internals of Meteor’s compiler plugin system, as far back as version 1.2 (September 2015!) to reap some pretty impressive build time improvements, all without compromising our fundamental design constraints.

Build performance

Delayed legacy builds

Meteor 1.7 introduced a new client bundle called web.browser.legacy in addition to the web.browser (modern) and web.cordova bundles, so that modern evergreen browsers are no longer forced to run code compiled for browsers that stopped receiving software updates years ago.

This development remains a significant competitive advantage for Meteor, since no other framework has successfully copied this functionality, though there is some confusion over what counts as success. In this talk, I predicted that it would be difficult for other frameworks to follow suit, and my claim still stands:

Naturally, this extra bundle increased client build (and rebuild) times. We were comfortable with this performance regression at the time, because it felt like the cost of progress, but also because we figured we could improve build times across the board in a follow-up release, rather than taking drastic measures like disabling the legacy build in development.

However, since developers spend most of their time testing the modern bundle in development, and the legacy bundle mostly provides a safe fallback in production, Meteor 1.8 cleverly postpones building the legacy bundle until just after the development server restarts, so that development can continue as soon as the modern bundle has finished building.

Since the legacy build now happens during a time when the build process would otherwise be completely idle, the impact of the legacy build on development server performance is minimal. Nevertheless, the legacy bundle still gets rebuilt regularly, so any legacy build errors will be surfaced in a timely fashion, and legacy clients can test the new legacy bundle by waiting just a little longer than modern clients. Applications using the autoupdate or hot-code-push packages will reload modern and legacy clients independently, once each new bundle becomes available.

In other words, we have all but erased the technical debt of compiling an additional client bundle, which was one of the biggest reasons for slower build times in Meteor 1.7. And we did it without imposing any additional configuration burden on Meteor developers. 🚫 🏗✨

Lazy compiler plugins

Even if we had not figured out how to delay the legacy build, Meteor 1.8 would still be faster than Meteor 1.7 by a wide margin, because we made a number of other substantial performance improvements, slashing build times across the board for the modern, legacy, Cordova, and server bundles. In fact, erasing the cost of the legacy bundle was really just icing on the cake, compared to what we’re about to describe.

A fantasy we can never indulge

When you’re designing a compiler system, it’s tempting to assume that individual files can be compiled one at a time, because that assumption greatly simplifies incremental recompilation, dependency tracking, and caching. Babel, for example, never needs to look at other JavaScript modules to determine how to compile the current module.

This assumption breaks down for languages like TypeScript, many compile-to-CSS dialects such as LESS and SASS, and indeed any programming language that needs to perform static analysis across multiple files at build time. If one TypeScript module imports an enum from another module, for example, the compiler needs to know not only that the export was an enum, but also whether it was a const enum or not, because that affects whether the enum values can be compiled down to integer constants elsewhere in the program. LESS mixins imported from other files are useless without access to the contents of the file where the mixin was defined.

For these reasons, Meteor’s compiler plugin system was designed from the beginning to provide a complete list of files that might need to be compiled to any compiler plugin that registers an interest in handling a particular file extension such as .js or .ts or .less, rather than invoking the compiler plugin once for each individual file. This was absolutely the right decision, and we have no intention of ever abandoning it.

The cost of sticking to our principles

Though we remain committed to this design, we must also acknowledge that it encourages compiler plugins to compile every file they receive, regardless of whether the file will ever actually be imported, and even if the compiled code appears nowhere in the final build.

This unnecessary compilation accounts for a substantial share of build time in many large Meteor applications, and so we are thrilled to announce that Meteor 1.8 finally introduces a simple mechanism for avoiding compilation of unused files.

If you are not a maintainer of any compiler plugins, you can safely skip the rest of this section, and simply enjoy the benefits of this new feature, automatically!

Here’s how it works. Compiler plugins that call inputFile.addJavaScript or inputFile.addStylesheet may now delay expensive compilation work by passing partial options ({ path, hash }) as the first argument, followed by a callback function as the second argument, which will be called by the build system once it knows the module will be included in the bundle. For example, here's the old implementation of BabelCompiler#processFilesForTarget:

and here’s the new version:

The compiler plugin still processes every possible file, and must specify how each file should be compiled (using the callback function), but any unused files will now be ignored by the build system, and their uncalled callbacks will be discarded after the bundle is built. ☎️ 🚮 👋

If you are a maintainer of a compiler plugin, we strongly recommend migrating to this new API, since the performance benefits for your users are potentially massive. Although this new API is only available in Meteor 1.8, you can use inputFile.supportsLazyCompilation to determine dynamically whether the API is available, so you can support older versions of Meteor without having to maintain multiple versions of your plugin.

Dependency upgrades

Babel 7

When Meteor 1.7 was released, Babel 7 was still in beta (beta 49, specifically). Meteor has kept pace with Babel prereleases very closely, shipping a new version of our babel-compiler package for almost every beta release (all 56 of them) and release candidate.

Though shipping beta software has risks, we were confident we could work around any breaking changes or bugs using our meteor-babel abstraction, thus shielding Meteor developers from those disruptions. Still, it’s a huge relief that Babel 7 has been finalized, and we can go back to normal semantic versioning for future releases.

Because of a specific breaking change in @babel/runtime@7.0.0-beta.56 (the removal of the @babel/runtime/helpers/builtin directory), we will not be updating Meteor 1.7.0.x and earlier to the final version of Babel 7. Those versions of Meteor will remain on version 7.0.0-beta.55. In other words, updating to Meteor 1.8 is necessary to get the benefits of non-beta Babel 7, and you will definitely want to install the latest version of @babel/runtime by running the following command:

meteor npm install @babel/runtime@latest

If you have been using custom Babel plugins in a .babelrc file, now might be a good time to make sure they are fully compatible with Babel 7.

Mongo 4

Meteor 1.8 ships with MongoDB 4.0.2, a major upgrade from version 3.6.4 in Meteor 1.7. This means your local development database will now use version 4.0, though the mongodb@3.1.6 driver will happily connect to production databases going all the way back to Mongo 2.6:

Driver Compatibility - MongoDB Ecosystem

The key benefit of MongoDB 4.0 is its support for multi-document transactions, which are now supported by Meteor’s oplog tailing system thanks to this pull request. Of course, if you decide to take advantage of transactions in development, you’ll also want to be using MongoDB 4.0 in production. Your database provider should be able to help with that.

Making the most of this version of MongoDB will be an ongoing process, but we are confident the update should be mostly seamless for apps that were previously using MongoDB 3.x.

Node.js 8.12.0*

* Actually still 8.11.4, for now.

We originally intended to ship Node.js 8.12.0 with Meteor 1.8, but those plans were interrupted by credible reports of high CPU usage in production, apparently due to excessive garbage collection. These reports began while Meteor 1.8 was in the final release candidate phase of testing, so we did not feel comfortable moving forward with the 8.12.0 update. Instead, Meteor 1.8 ships with the previous version, 8.11.4.

If you are eager to start using Node.js 8.12.0 (perhaps because of performance improvements related to Meteor’s use of Fibers), we encourage you to get involved in the Meteor 1.8.1 prerelease process. Just run the command

meteor update --release 1.8.1-beta.n

where the n in beta.n refers to whatever the most recent beta version is in our Release 1.8.1 pull request. The first release that includes Node.js 8.12.0 is also the first beta release, 1.8.1-beta.0. If you deploy an app to Galaxy with this version of Meteor, it will automatically be executed using Node.js 8.12.0. Please report your findings (good, bad, or interesting) in this issue.

We hope to ship Meteor 1.8.1 as soon as we can diagnose and fix these performance problems, and that will happen sooner if you can reproduce the problem, or otherwise help us figure out what’s going on! 🐌 🔜

Features you’ve always wanted

meteor create --react

Meteor has been a great way to use React for almost as long as React has existed. In fact, my own personal interest in Meteor was rekindled while I was working at Facebook on the JavaScript Infrastructure team, which was responsible for maintaining the React open source project.

React is famously unopinionated about where your app’s data comes from, and I thought Meteor could provide a compelling answer, with its advanced real-time data system, so I cooked up an internal demo to show the team. It worked incredibly well, which will come as no surprise to anyone familiar with both Meteor and React. Now, obviously React was not about to start depending on Meteor, or even tailoring itself to Meteor, but the ease of setting up that demo went to show how flexible both technologies are.

Much has changed since then, but Meteor’s commitment to the React developer experience is as strong as ever. That’s why Meteor 1.8 is finally introducing an easy way to create new Meteor apps with React instead of Blaze (though you can certainly use the two side-by-side, if you like):

meteor create --react my-new-react-app

Though relatively simple, this application template reflects the ideas of many contributors, especially @dmihal and @alexsicart, and it will no doubt continue to evolve in future Meteor releases. ⚛️💫

Overruling the constraint solver

If you’ve ever struggled to get Meteor’s constraint solver to untangle complicated package version conflicts, or cursed a no-longer-maintained package for accidentally constraining the version of a package you wanted to upgrade, Meteor 1.8 introduces an incredibly powerful escape valve that you can use to give better guidance to the solver.

Specifically, the .meteor/packages file (where you list the desired versions of all your top-level packages) supports a new syntax for overriding problematic version constraints from packages that you do not control.

If a package version constraint in .meteor/packages ends with a ! character, then any other (non-!) constraints imposed on that package anywhere else in the application will be weakened to allow any version greater than or equal to the constraint, even if the major/minor versions do not match. Note: this syntax only works in .meteor/packages, so there is no risk of abuse by anyone but the application developer.

For example, using both CoffeeScript 2 and practicalmeteor:mocha used to be very difficult because of this api.versionsFrom("1.3") statement, which unfortunately (and unnecessarily!) constrains the coffeescript package to version 1.x.

In Meteor 1.8, if you want to update coffeescript to 2.x, you can simply relax the practicalmeteor:mocha constraint by putting

coffeescript@2.2.1_1! # note the !

in your .meteor/packages file. Again, this means that all other version constraints imposed by other packages on the coffeescript package will lose their power to hold back the coffeescript version, though they will continue to require a minimum version. In other words, the coffeescript version still needs to be at least 1.x, so that practicalmeteor:mocha can count on that minimum. However, practicalmeteor:mocha will no longer constrain the major version of coffeescript to 1.x, so coffeescript@2.2.1_1 will work.

Shout-out to Geoffrey Booth, lead CoffeeScript maintainer, who originally got this conversation started, after much frustration with the exact problem described above.

Intuitively, this makes sense because most accidental version constraints are right about the minimum version they require, but wrong about the maximum version they will accept. And if they’re right about both, well, then there’s no accident.

When you need this syntax—if you need it—we think you’ll find it’s exactly the trick you’ve been missing. 👌🧙‍♀️

What’s next

Node.js 8.12.0, but actually

As discussed above, we will be tracking progress on the Node.js 8.12.0 garbage collection mystery in this issue, and we plan to release Meteor 1.8.1 as soon as those problems are solved.

An officially supported typescript package

Now that Meteor supports lazy compiler plugins, we anticipate two important developments for TypeScript in Meteor:

1. The widely used barbatus:typescript plugin will begin using lazy compilation, which should improve performance dramatically.
2. We will finally be able to share the typescript plugin we’ve been dog-fooding with our Engine app for the past few months.

To stay abreast of these developments, hop on over to this feature request.

More flexible meteor create options, e.g. --apollo

The new meteor create --react command is just the beginning. If you can believe it, we have even more opinions about the best way to set up an Apollo-based Meteor app, an app that uses TypeScript alongside ECMAScript, and many other different templates for new Meteor projects.

One drawback of the current meteor create --argument system is that the templates are tied to the current Meteor release, so it’s tricky to ship updates without releasing a new version of Meteor. We think we can overcome this barrier through a combination of doing more frequent Meteor releases, and fetching the app templates from an evolving Git repository, instead of baking them into the meteor-tool package.

Compiling compiler plugins after installation

Compared to the rest of the JavaScript ecosystem, one of Meteor’s selling points is that package and application code is compiled and bundled when the application is built, using whatever package versions the application developer chooses, instead of relying on past publishing choices of package authors who cannot anticipate the needs of the individual application.

The one exception to this rule is that Meteor compiler plugins are compiled and bundled before they are published to Atmosphere, which means they can end up using outdated versions of certain dependencies, unless the plugin author diligently releases new versions of the plugin. See this issue for an example of such a problem, and how it was fixed.

If you are the maintainer of a Meteor compiler plugin that uses ecmascript, we recommend taking this opportunity to bump the minor version of your plugin, add the latest @babel/runtime to its private npm dependencies, and republish the plugin (and its parent package) using Meteor 1.8. Bumping the minor version is important so that you can continue releasing patch updates for older versions of Meteor.

If you are an application developer who is struggling to use a compiler plugin that has not been updated for Meteor 1.8, you can always take matters into your own hands by cloning the plugin repository into your local packages/ directory, so that it will be rebuilt along with your app.

Rebuilding plugins at application build time is the general direction in which we want to move, though we hope to make that behavior the default, without requiring application developers to make local clones of plugins.

A slimmer version of the autoupdate package for minimal Meteor apps

Thanks to recent work by Christian Klaussner, the autoupdate package will soon cease to depend on the mongo and minimongo packages, which will save 60KB+ of bundle size (minified, before gzip), making it much more tolerable to use autoupdate and/or hot-code-push in an app that was created with the meteor create --minimal command.

Installing Meteor packages from npm?

Since Meteor packages can be cloned into a local packages/ directory instead of being installed from Atmosphere, there’s no fundamental reason why they couldn’t also be installed into a node_modules directory using npm or yarn. To a first approximation, the trick is simply to teach Meteor to scan top-level node_modules packages for package.json files with a meteor section that refers to the relevant package.js configuration file.

Imagine being able to npm install packages that have the ability to run eager initialization code on both the client and the server; can be recompiled differently for modern, legacy, Cordova, and server bundles; and work just like normal npm packages when installed in a non-Meteor application!

We’re still in the early stages of implementing this idea, but we find it appealing because it points to a future in which Meteor applications are built on top of enhanced npm packages that benefit (and benefit from) the wider npm ecosystem, without giving up their Meteoric super-powers.

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

Mac and Linux

curl https://install.meteor.com/ | sh

Windows

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

choco install meteor

How to upgrade

Mac, Linux, and Windows

Though we try very hard to make each Meteor release as backwards-compatible as we reasonably can, even the smallest differences in behavior (intended or unintended) could prove significant for existing applications. To document noteworthy changes, we have begun highlighting Breaking changes and Migration steps in our History.md release notes.

In Meteor 1.8, the only absolutely essential migration step is to install the latest version of the @babel/runtime npm package, since a number of breaking changes were introduced during the long Babel 7 beta period:

meteor npm install @babel/runtime@latest

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

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.

In summary

This has been a pretty long release announcement already, so we’ll keep this section brief.

With 453 commits over five months of development, Meteor 1.8 preserves, extends, and patches the groundbreaking features of Meteor 1.7, with vastly better build performance. If you’re already using 1.7, you should definitely run meteor update at your earliest convenience. If you’re still running Meteor 1.6 because 1.7 was too slow, or you had trouble updating for any reason, feel free to skip directly to Meteor 1.8. If you’re coming from an even older version of Meteor, see the migration guide.

As always, please have a look at the full release notes for details that may be particularly relevant to your applications.

If you get stuck, please feel free to ask questions in the comments on this post, or file a GitHub issue, or check the forums to see if other Meteor developers are facing the same challenges.

Now go forth and meteor update! 💫

Meteor 1.8 erases the debts of 1.7 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This guest post is by longtime Meteor community member Pete Corey, who is an independent consultant, web developer, and writer.

For the past three years I’ve been living and breathing Meteor security, and I’m excited to say I’ve managed to compile everything I’ve learned into a single comprehensive guide to securing your Meteor application. To celebrate the newly released Secure Meteor, I thought we could talk about one of the most prevalent and dangerous vulnerabilities that developers commonly introduce into their Meteor applications.

Let’s talk about NoSQL Injection!

To set the scene, let’s pretend that we’re building a Meteor-powered online storefront. Within our application, we’ve built a shopping cart system to let our users track and save the items they’re interested in purchasing. Like any other shopping cart system, we give our users the ability to empty their cart.

When a user clicks the “empty cart” button, their client makes a call to the emptyCart Meteor method, passing up the shopping cart’s MongoDB identifier. The emptyCart method simply removes the items (or “line items”) in that cart from the database, effectively leaving the cart empty:

Meteor.methods({
  emptyCart(cartId) {
    LineItems.remove({ cartId });
  }
});

It’s important to realize that while our Meteor method assumes that cartId is a string, it’s never explicitly stating that assumption or making any assertion about cartId’s type.

A potentially malicious user could easily violate our assumption by manually calling the emptyCart method from their browser’s console and passing in any JSON-serializable value for cartId:

Meteor.call("emptyCart", { $gte: "" });

In this example, our malicious user has called the emptyCart method and specified a cartId of { $gte: ""}. Placing this value of cartId into our LineItems.remove query results in the following expression being executed on our server:

LineItems.remove({ cartId: { $gte: "" } });

Rather than deleting a single user’s items from their shopping cart, this removes every item from every shopping cart in the database, whether they belong to the user calling the method or not.

The object the malicious user passed into the emptyCart method is a MongoDB query operator. Specifically, a “greater than or equal to an empty string” query operator. When dropped into our LineItems.remove query, it’s essentially telling the database to remove all line items in the database whose _id is “greater than or equal to an empty string.” Every line item’s _id will be greater than an empty string, so every line item will be removed.

Devastating.

This type of attack is known as a “NoSQL Injection” attack. NoSQL Injection vulnerabilities are incredibly dangerous and are particularly prevalent and relevant in Meteor applications, due to Meteor’s tight coupling to MongoDB and its seamless communication of disparate types through its DDP protocol.

Ultimately, NoSQL Injection attacks make their way into your application through missing, incomplete, or incorrect checking of user-provided data.

In this example, we could have easily prevented this NoSQL Injection attack by explicitly voicing the assumption we’re making about the cartId argument of the emptyCart method. Let’s add a check that asserts that cartId is, in fact, the string we’re assuming it to be:

Meteor.methods({
  emptyCart(cartId) {
    check(cartId, String);
    LineItems.remove({ cartId });
  }
});

By making an assertion about the type of cartId, we’ve completely prevented the possibility of a NoSQL Injection attack. If our malicious user tries to pass in their MongoDB query operator, they’ll receive a match error in response.

Let’s consider another example.

Imagine that we’ve decided to implement a user profile system in our shopping application. Letting our users tell us more about themselves might give us some valuable insights into their shopping habits!

We decided that the easiest route for implementing this feature was to add a set of “profile fields” to each user document, which they can freely edit to better express themselves. However, it’s important to remember that some fields on the user document are sensitive, and should only be updated by administrators.

Our first attempt at implementing this feature was with an editProfile Meteor method that accepts an update from the client, asserts that the client is able to perform the update, and then makes the modification to the current user’s document:

Meteor.methods({
  editProfile(edit) {
    if (edit.$set.isAdmin && !Meteor.user().isAdmin) {
      throw new Meteor.Error("Not authorized.");
    }
    return Meteor.users.update(
      {
        _id: this.userId
      },
      edit
    );
  }
});

We’re making the assertion that only administrators are allowed to $set the isAdmin field on their user document. We wouldn’t want non-administrators escalating their privileges.

At first glance, this seems like a fine home-rolled solution.

Unfortunately, or fortunately, depending on your perspective, MongoDB gives us many ways of accomplishing the same task. While a malicious user might be forbidden from setting their isAdmin field to true directly, they can achieve the same result through other means.

Imagine our malicious user runs the following query from their browser’s console:

Meteor.call("editProfile", { $inc: { isAdmin: 1 } });

Our $set guard is bypassed because the malicious user is passing up an $inc update operator, so our editProfile method happily runs their query. Rather than setting their isAdmin field to a specific value, this query increments their isAdmin field, essentially turning it into a truthy value.

Our malicious user has succeeded in elevating their privileges to the administrator level with a simple NoSQL Injection attack.

There are many ways of fixing this vulnerability, and they all boil down to making assertions about the type and shape of our user-provided inputs. For example, we could check that edit is an object with a $set field, and $set is an object that optionally contains some known set of editable fields:

Meteor.methods({
  editProfile(edit) {
    check(edit, {
      $set: {
        phone: Match.Optional(String),
        address: Match.Optional(String)
      }
    });
    return Meteor.users.update(
      {
        _id: this.userId
      },
      edit
    );
  }
});

Now if anyone tries to use our editProfile to modify some unexpected fields, or pass up an unexpected MongoDB update operator, they’ll receive a match error and their method call will fail.

I hope that these examples have demonstrated that NoSQL Inject vulnerabilities can be both incredibly diverse in their effects, and incredibly devastating on your application.

At the end of the day, the root cause of NoSQL Injection attacks is always improperly validating user-provided input. It’s incredibly important to make strong assertions about the shape and type of any data provided by the client, especially if that data is going to be used to construct queries against your database. Failure to do so can result in data breaches, privilege escalations, and even full-scale Denial of Service attacks against your application!

If you’re eager to learn more about NoSQL Injection and other vulnerabilities that might be lurking inside your Meteor application, be sure to check out Secure Meteor.

I wrote Secure Meteor with the intention of sharing everything I’ve learned about Meteor security from my time spent working with amazing teams to better secure their Meteor applications. If this article, or Secure Meteor in its entirety helps you squash even one vulnerability in your application, I’ll chalk that up as a win.

Putting the Brakes on NoSQL Injection with Secure Meteor was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

A New Chapter For Meteor

I have exciting news today to share with the Meteor community: new investment in Meteor, and a transition in project leadership including a new CEO.

The first version of Meteor was released in 2012 but it’s still the fastest and easiest way to build richly interactive full-stack web applications in pure JavaScript. No other set of libraries can offer an integrated experience like Meteor’s, and Meteor’s advanced technology, like live database queries that “just work”, is still unmatched by any other platform.

Meteor deserves to have a full-time team behind it: a team that invests in its growth and helps bring it to a wider audience. With most of the original Meteor Development Group team having moved on to Apollo GraphQL, it’s time to pass the torch to a new corporate sponsor that will make the promotion and growth of Meteor their full-time business.

After an extensive search we’ve found that new sponsor: an incredible group of people that modestly call themselves Tiny. Tiny was started by the founders of MetaLab, the design agency famous for creating the interfaces of some of the world’s top products, from Slack to Uber Eats. Their mission is to acquire, and then scale, “wonderful internet businesses”, especially businesses at the intersection of community and design. And their model works. If you’ve witnessed the growth of Dribbble in recent years, you’ve seen Tiny’s handiwork.

As part of the deal we’ve worked out with Tiny, MDG is transferring to Tiny our IP interest in Meteor (such as the trademarks and copyrights), and passing on responsibility for the cloud services such as the package server and Meteor Accounts. We’re also selling them the Galaxy business.

Tiny, in turn, has big plans to invest in Meteor’s growth. We will be working closely with the Tiny team to ensure a smooth handoff. But don’t expect dramatic overnight changes. They will need some time to build their team and to listen to the community. Please give them some space and help them in any way you can.

I’m super excited for Meteor’s next chapter. I expect Tiny’s involvement to accelerate Meteor development and to bring a lot of new blood into the community. The need for a framework like Meteor is greater than ever, and with your support, the years ahead will be some of Meteor’s best.

A New Chapter for Meteor was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Official TypeScript package included in new applications and a reference for how to make TypeScript and Meteor work together

We’re pleased to announce Meteor 1.8.2, an incremental release that’s packed with improvements as well as TypeScript integration 📣

This release was made possible thanks to 38 participants involved in its development (#10522).

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

Mac and Linux

curl https://install.meteor.com/ | sh

Windows

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

choco install meteor

How to upgrade

Mac, Linux, and Windows

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

2 — Execute the following commands to update @babel/runtime and meteor-node-stubs:
If you use npm to manage your npm packages:

meteor npm install @babel/runtime@latest
meteor npm install meteor-node-stubs@next

Or if you use yarn:

meteor yarn add @babel/runtime@latest
meteor yarn add meteor-node-stubs@next

For more information check out the History.

3 — Make sure your packages are up-to-date:

meteor update —-all-packages

See the updated packages and read each package release notes carefully.

4 — You are ready to run your Meteor project as usual.

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.

TypeScript

TypeScript is growing in popularity and Meteor integrates very well with it and now every new Meteor application include the official typescript package, supporting TypeScript compilation of .ts and .tsx modules, which can be added to existing apps by running meteor add typescript.

If you want to try TypeScript with Meteor you can create a new project by running

meteor create --typescript new-typescript-app

This project will be already configured and using TypeScript then it is a great reference for how to use TypeScript with Meteor.

Other highlights

• The Meteor build process is now able (again) to detect whether files changed in development were actually used by the server bundle, so that a full server restart can be avoided when no files used by the server bundle have changed. Client-only refreshes are typically much faster than server restarts. Run meteor add autoupdate to enable client refreshes, if you are not already using the autoupdate package. (#10686)
• Dynamic modules are great to speed up your app load time in the client and Meteor implements this in a very smart way, only delivering each module a single time and also caching these modules in the client. In some edge cases modules were not found resulting in Cannot find module errors. This was also fixed in this release and then you can use dynamic modules everywhere in your apps. This issue was only affecting projects with many local packages and using nested and dynamic imports but as Meteor is used in many large projects it is great to have dynamic imports working on every case. (#10730)
• Added the ability to run multiple Cordova apps that are built from the same application source code at the same time on iOS, this is now possible because we added a new build and deploy option called --cordova-server-port where you can specify in which port your app should run. (#10577)
• Import code from node_modules that uses modern syntax beyond module syntax, it is now possible to enable recompilation for specific npm packages using the meteor.nodeModules.recompile option in your application’s package.json file. (#10603)
• In addition to the .js and .jsx file extensions, the ecmascript compiler plugin now automatically handles JavaScript modules with the .mjs file extension.
• Check the full list of improvements here

Meteor 1.9 is already under development and we will update the Node.js version used by Meteor from 8.16.1 (in Meteor 1.8.2) to 12.10.0 (the most recent current version).

Package updates

We have also updated some Meteor packages:

• accounts-password@1.5.2: underscore was removed (thanks to sebakerckhof)
• mdg:camera@1.4.2: fixed deprecated createObjectURL method (thanks to rafahoro)
• mdg:camera@1.4.3: added localization (thanks to mertyildiran)
• react-meteor-data@2.0.0: added useTracker hook (thanks to CaptainN and many other community members)

Community

Meteor community is very active and you could join our Meteor forums and Community Slack to exchange experiences with other developers and also to be aware of everything that is happening around Meteor.

For example, the React version of “Todos” example app was updated thanks to cvolant and now it uses function components instead of classes, this is a great resource if you want to use Meteor with React using the latest best practices.

Also, I recently joined Meteor as Developer Evangelist and this is just my first post here. I’m very happy and excited about the future of Meteor!

Now go forth and meteor update! 💫

Announcing Meteor 1.8.2 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Node.js 12, Meteor and Galaxy roadmaps, and more

Today we’re thrilled to announce the final release of Meteor 1.9, which brings the stable and in long-term support Node.js 12. We also have a new version of Meteor roadmap and the first Galaxy public roadmap. Please check those out when you can so you know what’s to come! We’re very excited, and we hope you are too.

Node.js 12

The major change with 1.9 release is Node.js 12 support. In April of 2019 we started to publish alpha versions of Meteor 1.9 updating to Node 12; with continual feedback from the community members, we are now ready with a final version.

The upgrade from Node 8 to Node 12 required a number of changes and updates behind the scenes to ensure the compatibility of npm packages. As always, Meteor updates are backward compatible as possible and you can enjoy the benefits of new features without any hassle!

The new version of the V8 JavaScript engine used by Node 12 brings performance improvements and tweaks that should improve the performance of your code as a whole. Meteor uses Fibers to avoid async callbacks and now you should see less garbage collection as node-fibers is no longer asking for adjustments of external allocated memory what should result in less pressure in CPU usage what is always good.

It is worth to note that 32-bit Linux support was dropped in Node.js 10, and we also dropped the support for it. In other words: Meteor 1.9 supports 64-bit Mac, Windows, and Linux, as well as 32-bit Windows. As always you can check all the changes in History.

We are also excited about new Node features that will be beneficial for the future of Meteor. Worker Threads that can help to parallelize build process and other intensive processes and also native source map support for Node stack traces.

Before you update to Meteor 1.9 we recommend you check your npm dependencies to be sure they are compatible with Node 12.

Meteor Roadmap

We’ve updated the Meteor roadmap to reflect our goals for Meteor, and we hope you will review and share your thoughts. We will continue to update every quarter. There are many different areas for contributions for those interested: Core, Cordova, DB, Documentation, as well as new content for Technologies that we consider first-class citizens in the platform.

We would love to have you involved! Meteor has and will continue to rely on our community in order for us to grow into the platform we all know it can be. We hope that you will help us make Meteor better by assigning yourself a task.

Everybody is qualified to work on Meteor, if you need help deciding the best item for you to be involved leave a comment here or ask in the Meteor Community Slack.

You can also get involved in Meteor 1.10 which includes Cordova updates and also the ability to disable web.browser.legacy build, we already have published beta versions of it and you can help trying it in your apps today.

Galaxy Roadmap

Galaxy is the hosting platform specially designed for Meteor apps. It’s the fastest way for you to publish your Meteor apps: One command deploys, free Automatic SSL certificates, built-in SEO prerendering, integrated APM, etc.

Galaxy already provides many features to make your experience running Meteor apps in production as easy as possible; in the next few months it will receive new features such as: notifications about your app activities, auto-scale options, ability to apply new settings without a new deploy and much more.

If you have special needs or want support feel free to send us a message (support@meteor.com) and we will be glad to help.

Packages updates

Every week we have package updates and since Meteor 1.8.2 we had many updates, a few highlights:

meteor-apm-agent@3.2.5: fixes error logs not providing useful information [object Object] .

mdg:seo@3.2.2: removes deprecated tag and updates prerender-node.

modern-browsers@0.1.5: fixes Capacitor (and possibly others) user agents detection.

react-meteor-data@2.0.1: makes main module lazy.

By the way, Kevin Newman published a great post about version 2 of react-meteor-data package where he explains how useTracker (new React hook!) works and how to use it.

Bonus Tip

To conclude this post I would like to ask you a question: Did you know you can use optional chaining since Meteor 1.8.2? 😮

Yes, you can! Thanks to the great integration between Meteor and Babel you can already use optional chaining without any extra configuration. Optional chaining is great to avoid explicit undefined checks in your code. See one simple example:

// author / coauthor (optional) / title
const blogPost = {
  author: {
    firstName: 'Filipe',
  }  
  title: 'Meteor 1.9 and Node.js 12',
}

// get coauthor first name without optional chaining
if (blogPost.coauthor) {
  console.log(blogPost.coauthor.firstName);
}

// get coauthor first name with optional chaining
console.log(blogPost.coauthor?.firstName);
// output: undefined

You can check all the proposals available for you in babel-preset-meteor and don’t forget to update your apps to Meteor 1.9. Enjoy!

Meteor 1.9 (Node.js 12) and new Roadmaps was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The next phase of Meteor has begun, starting with a site overhaul and key Galaxy Hosting changes. We couldn’t be happier about it. Let’s dig into what we’ve done and why:

Site Design

First and foremost, the site needed an upgrade. We felt the existing site no longer represented the brand and where we want to take the product in the future, so the folks at Z1 Digital came by to give us a hand at improving it. This new look encompasses the next stage of both Meteor.js and Galaxy Hosting platforms. Z1 did a great job, and we’re proud of where things ended up. We hope you like it.

Also — shout out to our new showcase features: lemlist, Chatra.io, Maestro, Pathable. Find more here.

How we’ve improved:

Galaxy Hosting Pricing

Our pricing model for Galaxy Hosting was a key area of focus with this new site release. One of the things that we’ve heard from our community is it would be great for users to be able to experience Galaxy before committing for the long term, and that there should be a plan for hobby or community projects and individuals running smaller apps.

We think we’ve solved that initial need with a new, more transparent pricing structure and new container options. Here’s what we came up with:

To start — we’re implementing a Free Trial option for all new accounts on Galaxy Hosting. For 30 days, you can try any container size, up to 4GB (meaning you could run 1 Quad container, or 4 Standard ones) in order to make sure you know Galaxy is right for you.

Test all of the functionality, scalability of Galaxy and run large scale apps completely free for 30 days. Not a good fit? No problem, you can migrate your app away at any time before the 30 days is up at no cost.

We’re even offering previous Galaxy users with inactive accounts the ability to take advantage of this 4GB 30 day free trial. Not sure if you qualify? You can either check your Meteor Developer Account Dashboard by signing in here, or reach out to us at support@meteor.com and we’d be happy to help.

Secondly, we’ve built another container option we’re calling “Tiny” (we couldn’t help ourselves). This option will let you play around with the service, host a hobby project and otherwise test smaller apps using Galaxy Hosting.

Can you run high traffic, enterprise apps through the Tiny Container? No. Is it a good place to start for someone running smaller apps on Galaxy at a very low cost (9/mo)? We certainly think so.

Already a Galaxy user with apps running? Fantastic. Nothing changes for. We won’t bump anyone up to a $9 plan or force you into a new pricing structure that you didn’t sign up for. Keep on keepin’ on (but also make sure to check out our roadmap for future feature releases).

Also, if you have consistent usage rates on Galaxy, you can save 20% by prepaying annually. Reach out to support@meteor.com and we’d be happy to help you there also : -)

Site Navigation:

The navigation of meteor.com was not as intuitive as it should have been. The relationship between Meteor.com, Galaxy Hosting and Meteor Developer Accounts (MDA) was not obvious for anyone visiting the site for the first time (or even for returning users). We’re now in a much better spot.

Users can login centrally to the main MDA dashboard, then access the regions for their Galaxy Hosting accounts. No more searching where to login to Galaxy — access everything centrally from your MDA Dashboard.

As usual, Galaxy Hosting customers can always visit the regional URL directly to login to Galaxy account (we recommend bookmarking these). For those with multiple region accounts, you can access all of them easily from the MDA dashboard.

This is only the first of many upgrades we’re planning for Meteor and Galaxy Hosting. Interested in learning more about what we’re up to? Check out the Roadmaps for Galaxy Hosting and Meteor.js.

Want to try Galaxy Hosting absolutely free for 30 days? Get started here.

Happy Building!

— Your friends at Meteor HQ

Welcome to the New Meteor.com! was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Meteor 1.10 is a release full of exciting updates such as Cordova, MongoDB, option to exclude architectures, new Meteor DevTools and more

We started working on Meteor 1.10 last December by updating Cordova and MongoDB to the latest versions. Since then, we have included the ability to exclude specific architectures in development, new Meteor DevTools and much more.

During this release, we were able to close 27 PRs and issues. All this was possible because of our community, more than 40 people have helped in 1.10. Thank you all! 😉

Let's dive into a few highlights.

Cordova Update

Meteor is now up-to-date with Cordova; we have updated from cordova-lib 7 to 9 and also cordova-ios and cordova-android to latest versions. Also, we’ve upgraded every Cordova plugin that is a direct dependency of Meteor.

As a result of these updates, the problems reported by XCode due to old Swift versions are gone and also the warnings after the submission to the App Store about using UIWebView. As always you can check everything that was updated in History.

The Cordova integration is very important for many Meteor developers that are delivering their apps or their client’s app to App Store and Google Play. We are now able again to provide a smooth experience for developers creating a native application only using Javascript.

You can create a new Meteor application with native support via Cordova by running:

meteor create my-mobile-app
cd my-mobile-app
meteor add-platform ios
meteor run ios

meteor run ios will open the iOS Simulator with your app running on it. You can also run Android by running:

meteor add-platform android
meteor run android

meteor run android will run your app in the Android Simulator as well.

If you don’t have iOS or Android development kits setup yet, follow the steps from our guide before adding the platforms to your Meteor app.

Cordova still has a lot of presence on App Store and Google Play, and Meteor can help a lot with the native experience by providing a Cordova project already configured properly for you.

In my opinion, Cordova deliveries the best cost-benefit for companies that want to have their apps on Web, iOS, and Android. We will continue to provide support for Cordova and we are also going to enhance the documentation and include more code examples on how to build great native apps. 📱

MongoDB Update

As you probably know Meteor has a long story with MongoDB — Meteor even provides a MongoDB ready to be used by your application without requiring that you install MongoDB yourself. This embedded MongoDB for development is now using the version 4.2.1.

We have also updated the MongoDB driver used by core Meteor packages so we are up-to-date with MongoDB as well. 🎉

Thanks Christian Klaussner for this work!

Skeleton Updates

You can create a new Meteor project choosing from a few skeleton options, but the React skeleton was still using class components and withTracker HOC, these two patterns are still valid but we believe there are better ways to create React apps today. It was time for an update here. Now, it usesfunction components and the new hook for tracker called useTracker .

If this hook is new to you, check our recent blog post introducing it. See below how it is used in the updated skeleton — useTracker makes it very simple to have reactive data in your React components!

You can use this new skeleton running meteor create --react . The TypeScript skeleton (meteor create --typescript) also uses React, and therefore it is also updated with function components and useTracker hook.

On the subject of skeletons, a new skeleton is coming soon: the new skeleton (not published yet) will help you to create a native app with Cordova, Push Notification, PWA settings, Service Worker and much more. Sign-up to our newsletter to know when the mobile skeleton is available! 💀

Vue.js Tutorial

If you are not using React as your view layer, there is a good chance that you are using Vue.js. We are glad to announce our Vue.js Tutorial!

In the tutorial, you are going to learn how to create a simple app to manage a “to do” list and collaborate with others on those tasks. By the end, you should have a basic understanding of Meteor and how to use Vue.js with Meteor. Feedback is welcome!

Thanks to Brian Mulhall who wrote this tutorial and also Guillaume Chau who implemented Meteor akryum:vue-component package.

Exclude Architectures

Meteor 1.7 introduced a new client bundle called web.browser.legacy in addition to the web.browser (modern) and web.cordova bundles. Naturally, this extra bundle increased client (re)build times. Since developers spend most of their time testing the modern bundle in development, and the legacy bundle mostly provides a safe fallback in production, Meteor 1.8 cleverly postpones building the legacy bundle until just after the development server restarts, so that development can continue as soon as the modern bundle has finished building. This was nice, but not enough, as theweb.browser.legacy is still using machine resources even if it’s not blocking the modern bundle to be used but now this is solved.

You can now pass an --exclude-archs option to the meteor run and meteor test commands to temporarily disable building certain web architectures saving machine resources. For example, meteor run --exclude-archs web.browser.legacy. Multiple architectures should be separated by commas. This option can be used to improve (re)build times if you’re not actively testing the excluded architectures during development.

As you can see below you can optimize your development excluding architectures that are not important for you in a specific moment.

Thanks Seba Kerckhof 😃

If you want to update an existing Meteor project you can update to 1.10.1 running meteor updateon your app directory. Enjoy!

Meteor DevTools Evolved

Leonardo Venturini published a new version of the Meteor DevTools that he called Meteor DevTools Evolved, an incredible tool for Meteor developers to debug and understand Meteor methods and publications. Also, it provides a view of your MiniMongo collections.

This new DevTools is capable of handling a lot of DDP messages per second without freezing or breaking, and also offers new features like save messages to analyze later (bookmarks), MiniMongo documents filter, etc. If you would like to contribute or if you found a problem feel free to open an issue or PR. ⚙️

Galaxy News

Galaxy also received a new feature today! One of the most requested features on Galaxy was the ability to edit the Meteor settings without requiring a new code deploy. We are glad to announce that now you can edit the settings from the current version of your app deployed to Galaxy.

It's very simple — go to Versions tab in your Galaxy app dashboard, expand your current version and click in the Edit button below your current settings then a text input will appear for you to edit the settings. Click save when you are ready and a new version will be created with your changed settings. ✏️

In case you have missed, Galaxy is offering a free trial of 30 days! You can use up to 4 GBs of RAM, which is the same as 4 standard containers, 2 double containers or 1 quad, so you can try all the Galaxy container sizes for free. Sign-up for Galaxy now! 🆓

Wow, many things to cover in this post, I hope you liked it. Check the Meteor and Galaxy roadmaps to know what is coming next! 😉

Announcing Meteor 1.10 was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We have some exciting improvements to Galaxy that we’re releasing today. In line with our public Galaxy Roadmap, we’re releasing two major features that have been highly requested.

As of today, all Galaxy Professional users have access to:

Autoscaling — Make sure your app is running smoothly, automatically. Autoscaling spins up or spins down capacity for your application based on usage. No more paying for unused capacity or manually checking and upgrading your Galaxy account to support influxes in traffic.

To enable autoscaling for professional Galaxy apps, please go to your settings tab on the app dashboard, and scroll down to “Triggers”

From here, you can customize exactly the configuration you need, specifically for your app. Click save, and you’re done! No more stressing over scaling your app for unforeseen traffic/usage spikes.

For more information on autoscaling and how to enable, please see our docs. Then, check out our video tutorial (created by the one and only Filipe Névola!):

API — Control your Galaxy account from afar with our new API. Extend features and functionality to your own internal dashboards or admin interfaces for more seamless maintenance of your Galaxy account.

Want to learn more? We’ve got you covered here also! Check out the guide for more information.

These two features are only available to our Galaxy Professional apps. If you’re app is currently on the Essentials plan, you can upgrade by going to the settings tab on your app, and choosing the “Upgrade to Professional” option, found here:

Notifications — The information you need, when you need it. Easy set up allows you to receive notifications via Slack or Email in seconds for events related to your app. You have complete control! Assign who receives different notifications and what channel they are sent through.

To enable notifications on your existing apps, please visit the settings tab and choose which notifications you’d like to enable:

For full notes on the notifications and how to enable them, please see the guide.

Improving the functionality and experience of Galaxy Hosting has been key for us, as it is the main way we support the growth and improvement of the core Meteor Platform.

Autoscaling, API functionality and notifications are huge steps in improving both Galaxy Hosting and Meteor as a whole. We think Galaxy is already a superior offering, and it will continue to improve (see roadmap).

We’re so confident that you’ll enjoy the ease of Galaxy that we are continuing our free trial offering for all apps hosted on Galaxy. The free trial is a great way to test out which plan is suitable for your Meteor app, before committing fully!

Interested in the free trial? Get started here.

Thanks for being a Galaxy customer and a valued part of the Meteor ecosystem!

Introducing Autoscaling, API, and Notifications to Galaxy Hosting! was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

How lemlist Grew to +10,000 Paying Customers with Meteor.

Okay, we’re not here to toot our own horn. But we have to share the story of how lemlist catapulted their cold emailing platform to greatness with Meteor’s help.

In less than three years of launching, lemlist has become the first cold emailing platform to crack the deliverability code and reached $2M ARR without raising any money. They now have over 10k customers including high-profile names like Uber, shapr, and zendesk.

So in this case study, we’ll highlight exactly how lemlist:

1. Grew their customer base to over 10,000 global paying users
2. Captures 23% month over month growth
3. Built the largest sales automation community in the world

Impressive, right?

Now, despite our help, stats like these start with a stellar product.

So if you’ve never heard of lemlist, let’s begin with a rundown of what this company has been pioneering.

Meet lemlist: A Dream Come True for Cold Email Campaigns

Cold emails, or messages sent to receivers without prior contact, often go unnoticed. And they very rarely make it to their intended recipient’s primary inbox.

But the team at lemlist wanted to change this.

So they built an incredible tool that helps sales teams, agencies, and B2B businesses personalize and automate cold emails to boost deliverability and generate more replies.

We think lemlist is awesome because it lets users:

Personalize Cold Emails on a Large Scale

Fact: Personalized messages have a higher likelihood of engagement. Bad news? Prospecting on a 1-to-1 level takes a ton of time, effort, and resources.

And no one’s down for that.

So lemlist’s unique tool helps you add a personal touch to your cold emails to reach and connect with prospects sooner.

Send personalized emails without the hassle of sending messages one-on-one

Your contacts on the receiving end will see a personalized message that looks hand-delivered specifically for them with personalized images and landing pages. Little will they know their message came from a batch of cold emails you quickly sent with lemlist.

Optimize Emails to Reach the Elusive Main Inbox

Tired of your cold emails getting the cold shoulder?

The lemlist tool helps your cold emails bypass spam filters and random inbox tab sorting so they actually make it to their primary destination (i.e., the main inbox).

Emails show up prominently instead of getting weeded out and ignored.

Create Professional Emails Faster with Email Templates

You can stop wasting time building killer emails each time you have something to send.

The lemlist tool comes preloaded with drag-and-drop cold email templates that you can use to build stunning, on-brand emails that look entirely your own in a flash.

You’ll find email template options for sales, follow-ups, sourcing, backlink generation, and much more, saving you loads of time and effort.

Spend less time creating emails and more time connecting with prospects

Keep Improving Your Process

The lemlist team offers users educational guides and access to the largest sales automation community in the world.

Join the largest sales automation family in the world

Users are encouraged to tap into this support team to better understand how to find and engage with potential prospects.

So as you can see, lemlist has several coals in the fire between creating and maintaining code for their tool and keeping up with their community.

To better help customers turn cold prospects into warm leads, the team decided to find out whether Meteor could do some of the heavy lifting for them.

Why lemlist Chose Meteor

Meteor is an open-source platform for web, mobile, and desktop that makes shipping Javascript applications simple, efficient, and scalable.

Because it helps you accomplish in 10 lines what would otherwise take 1,000, Meteor’s used by over half a million developers worldwide.

And Vianney and Francois Lecroart, the 2 tech co-founders who already used Meteor for years, immediately understood how Meteor could help them build a more incredible product in less time. Their decision to go with Meteor came down to three features:

Meteor’s Framework

The co-founders of lemlist were early adopters of our framework since version 0.5. As Meteor Paris ambassadors, they created the biggest non-english speaking Meteor community with more than 2500 Meteor fans and organized more than 30 meetups.

They were used to coding days, nights, and weekends to get builds up and running as soon as possible. But once they started working with our beta version, they realized they could build much faster using Meteor’s built-in features.

The lemlist team continues to use Blaze as the view layer because of its simplicity. Originally, they were attracted to Meteor because of its ease of use and its similarities to monolithic frameworks like Rails. They still love it today!

Speed of Development

Rather than manually and painstakingly writing each line of code to build from scratch, all the lemlist co-founders had to do was simply build onto our existing foundations quickly and efficiently.

And since you can compile, build, and deploy in a single tool — no configurations required — they spent less time setting up and more time building.

From the founders: “Having an idea is cool, but being able to test it quickly with real users is essential for a rapid growth. Meteor is so helpful that they were able to create a first working version in a few weeks so they were able to validate their ideas immediately with potential customers. Thanks to the modularity of Meteor, months after months they improved and extended this first version to handle more features and hundreds of simultaneous users.”

The co-founders of lemlist finished so soon that they were able to create their product, test it, and launch within a couple of days.

Discover how easy it easy to build with Meteor

Flexibility and Agility

Most platforms for developing Javascript applications don’t have much flexibility. But with Meteor, the control is entirely in the hands of the developer.

Coders can use out of the box defaults or configure their own setup to meet their specific needs.

The lemlist co-founders say they continue to be impressed by how swiftly they can push out updates, new features, and customer requests without users experiencing downtime or being forced to download a new version.

And these features all made a huge difference in lemlist’s success story.

How Meteor Helped lemlist Grow Exponentially

Getting off the ground ASAP was just the start of how Meteor contributed to lemlist’s impressive growth.

We also helped lemlist achieve:

A Global Customer Base of 10,000+

Thanks to Meteor, lemlist scaled its customer base and continues to earn 23% growth month over month.

In just two and a half years since launching, Meteor helped lemlist grow its customer base to over 10,000 paying users around the world.

Imagine what your business would look like with that kind of growth.

Envy-Inducing Email Performance Rates

Customers who signed up for lemlist over a year ago are shocked to see how much this easy-to-use tool has improved in such a short amount of time.

Now users earn 10x better email performance rates than lemlist’s competitors. Users send tens of millions of emails — the fastest on the market.

These faster deliveries and higher open rates translate to higher customer acquisition, satisfaction, and retention rates.

Imagine what your team could do with higher email engagement rates

This type of performance is so outstanding that the lemlist team has been successfully stealing customers from their competitors. Despite being around longer than lemlist, their clunkier platforms just can’t compete.

Higher Customer Satisfaction

Customer satisfaction is a top priority for lemlist. So with the help of Meteor, lemlist has been able to provide a high-quality product and top-notch service.

Meteor’s frameworks and real-time updates allow developers to stay agile, adapt, and improve the lemlist platform at the speed of business.

Once the team gathers information and feedback from their customers, they can promptly make changes to the framework rather than starting over.

It’s easy to update or add key features — including those their customers request — much faster than their competitors.

Thanks to Meteor, lemlist’s features are created, tested, and pushed live sooner, so customers don’t have to wait weeks or months.

Customer satisfaction surveys prove time and again that lemlist users value this convenience and prioritization. And having their requests fulfilled almost instantly makes for happy customers.

lemlist in 2020 and Beyond

The team at lemlist plans to build on their positive momentum and push their platform to new heights. Their goals for the future include:

Focusing On User Success

The recent COVID-19 pandemic forced more people to start working remotely. This prompted businesses to invest in sales to help their brands grow via email outreach.

lemlist wants to become a go-to tool for companies to reach and surpass their business goals in these trying economic times.

And to do that requires focusing on their users’ success.

They want B2B sales (which they jokingly refer to as “boring-to-boring”) to be more about relationship-building and helping people than about the ABCs (“always be closing”).

So they’re currently testing lemlist 3.0 with a private onboarding, and they say users are loving this new version.

Encouraging Female Empowerment Efforts

The lemlist platform skews 60% male users and just 40% female users.

So the team is actively working on targeting efforts to include and connect with more women. They’re also striving to empower women in sales through their platform.

From experience, lemlist learned that women easily outperform men in sales thanks to their empathetic and well-organized nature. They make excellent leaders who also know how to nurture and build relationships to encourage conversions.

That’s why the lemlist team is pushing for more women in higher-up positions within their own company also (they are hiring, by the way).

Meteor + lemlist = Greatness

Our Meteor crew couldn’t be more stoked to see lemlist take flight and spread their wings. And we can’t wait to see what the future has in store for them.

We’ve worked with their incredible team since inception, and we’re so fortunate to be part of their growth. We couldn’t be happier to partner with a company helping so many people work smarter.

Haven’t seen lemlist in action yet? Go check out the platform and see why we’re such big fans!

See our showcase page for more successful companies building with Meteor.

Curious about how Meteor can help your brand write their own success story? Visit our website to learn what our platform can do for your business now. Or, download Meteor now.

How lemlist grew to +10,000 paying customers with Meteor. was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your Galaxy applications just got more secure thanks to Two-Factor Authentication on all Meteor Developer Accounts (MDA) and App Protection on Galaxy Hosting.

You can rest easier knowing that you have additional layers of security protecting you from hackers and malicious attacks.

Let’s go into how we’ve made things more secure:

App Protection

App Protection on Galaxy Hosting is a new feature in our proxy server layer that sits in front of every request to your application. This means that all requests across servers are analyzed and measured against expected limits. This will help protect against DoS and DDoS attacks that aimed to overload servers and make your app unavailable for legitimate requests.

If a type of request is classified as abusive (we’re not going to go into the specifics as to how we determine this), we will stop sending these requests to your app, and we start to return HTTP 429 (Too Many Requests).*

Although not all attacks are preventable, our App Protection functionality, along with standard AWS protection in front of our servers, will provide a greater level of security for all applications deployed to Galaxy moving forward.

For additional security, it is best to configure your app to limit the messages received via WebSockets, as our proxy servers are only acting in the first connection and not in the WebSocket messages after the connection is established. Meteor has the DDP Rate Limiter configuration already available, find out more here.

Two-Factor Authentication

The benefits of Two-Factor Authentication are obvious to all. Now it’s available for all Meteor Developer Accounts, and therefore all applications deployed to Galaxy.

To enable Two-Factor Authentication on your Meteor Developer Account, please login, then click on Security on the left hand side, then “enable”

These two security additions to Galaxy are part of an on-going effort to make Galaxy the world-class cloud hosting platform for Meteor applications.

If you missed our last Galaxy release of Autoscaling, API and Notifications, you can learn more about that here. Or, see our full Galaxy Roadmap here for all of our future updates to the platform.

Try all Galaxy Hosting absolutely free for 30 days! Pay for only what you use after that.

Have a question? Reach out to us at support@meteor.com, or check out the forum.

Thanks for being part of the community!

The Meteor Team

*Owners of apps that incur potential attacks will be contacted until August 5th 2020. If you want to disable app protection you can do so — you still have full control. Reach out to us at support@meteor.com for additional details.

Security Where You Need It: Introducing Two-Factor Authentication + App Protection was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.