Announcing Meteor 1.4.3

Better core package versioning, upgrade to npm 4, and more

Meteor 1.4.2 was a landmark release that brought dramatically better incremental rebuild times for larger apps. Meteor 1.4.3 includes a number of incremental improvements in diverse parts of the platform, setting the stage for significant new features in 1.5.

This release, with the first stable version being 1.4.3.1 , stands out as one of the most community-driven releases ever, with over 250 commits from 26 different contributors.

Update now by typing the following in your console!

meteor update --release 1.4.3.1

Now, let’s go over some of the more exciting improvements in this version.

Stricter version constraints on core packages

From the early days of Meteor until 1.4, a Meteor release pinned a specific set of exact versions of all of the core packages. This meant that you could be completely confident that using that release would give you the same package versions in every app, but made it impossible to ship incremental improvements to core packages without shipping a new release of the entire platform.



In Meteor 1.4, to enable faster bug fixes and community contributions, this constraint was relaxed, allowing potentially incompatible core packages to be installed at the developer’s discretion. One consequence of this change was that merely running meteor update might give you significantly newer package versions than originally shipped with the release your app is using. Another drawback of relaxing version constraints was that updating to a new version of Meteor would not force any of your packages to be upgraded, even if those upgrades were important. While this change enabled much faster incremental improvements to core packages, it made it much harder to ensure Meteor's core packages would work well together.



In Meteor 1.4.3, this approach is refined so that core package versions in an app must now be patch-compatible with the versions specified by its Meteor release. That means you'll never get a different minor version of, say, the http package than the version that originally shipped with a release. This policy makes it much easier to be sure you're getting a reasonable combination of core packages when you update to a different Meteor release.

Upgrade to npm 4 and better ergonomics

Meteor comes with an internal specific version of npm. It’s used to install dependencies of Atmosphere packages and also makes it easy for everyone developing your project to use exactly the same version of npm. You can use meteor npm ... to invoke this version of npm. For example, running meteor npm install in any project will install node_modules using this version of npm.



In 1.4.3, this npm has been updated to version 4.1.2. Learn the details about this npm release on GitHub.

As a bonus, you now have to type meteor npm install one less time — when you first type meteor create to initialize an app, we pre-install the dependencies so that you can meteor run right away.

Decoupling Accounts from Blaze

In Meteor 1.4, the Blaze UI system was decoupled from the core so that it could be community driven and move more quickly. Meteor developers now commonly use a diverse set of UI technologies, including Blaze, React, Angular, Vue, and others. This decoupling means it’s possible now to use all the features of Meteor without including the Blaze library in your client bundle.



Until this release, various accounts integration packages, for example the facebook package, had a dependency on Blaze so that they could provide an initial configuration UI on top of accounts-ui . Through a great community effort and multiple PRs, these packages were split into two parts each. Instead of facebook there are now two packages: facebook-oauth , which implements authentication logic, and facebook-config-ui , which contains the Blaze-specific configuration interface. If you were previously using the facebook package (or github , twitter , etc.), it will be automatically replaced with the new packages when you run meteor update .



These new packages should make it easier for developers using UI layers other than Blaze to build Meteor apps with smaller bundle sizes while still using the built-in authentication provider integrations.

This improvement particularly highlighted a collaboration between many community members, with lots of people stepping up to convert the different authentication packages provided by Meteor core. Check out the details below:

The full release notes and roadmap

As always, you can find the full release notes in History.md in the Meteor repository on GitHub. If you’re interested in the current goals of the project, we have also been maintaining a Roadmap.md which is updated at least once a month to keep track of medium-term priorities.

What’s next in Meteor 1.5?