Please help test the release candidate for Meteor 1.2.1!


If you’ve been following along on GitHub, we’ve been getting ready for 1.2.1, a minor release with some small new features and a collection of recent bug fixes. The idea is to release much more often than before, so that people don’t have to wait long to get new stuff.

There should be exactly 0 breaking changes in this release. We can help make this a reality if you take a few minutes out of your day to run your apps with the RC using the command below.

meteor --release 1.2.1-rc.4

Stay updated by following the issue on GitHub.

Improvements in Meteor 1.2.1

  • coll.insert() now uses a faster (but cryptographically insecure)
    algorithm to generate document IDs when called outside of a method
    and an _id field is not explicitly passed. With this change, there
    are no longer two algorithms used to generate document
    IDs. can still be used to generate cryptographically
    secure document IDs. #5161

  • The ecmascript-collections package has been renamed to
    ecmascript-runtime and now includes a more complete selection of
    ES2015 polyfills and shims from core-js.
    The complete list can be found

  • Check type of onException argument to bindEnvironment. #5271

  • WebApp’s PORT environment variable can now be a named pipe to better support
    deployment on IIS on Windows. 4413

  • Template.dynamic can be now used as a block helper:
    {{#Template.dynamic}} ... {{/Template.dynamic}} #4756

  • Collection#allow/deny now throw errors when passed falsy values. #5442

  • source-map has been updated to a newer patch version, which fixes major bugs
    in particular around loading bundles generated by Webpack. #5411

  • check now returns instead of throwing errors internally, which should make
    it much faster. check is used in many core Meteor packages, so this should
    result in small performance improvements across the framework. #4584

  • The userEmail option to Meteor.loginWithMeteorDeveloperAccount has been
    renamed to loginHint, and now supports Google accounts as well. The old
    option still works for backwards compatibility. #2422 #5313

  • The old addFiles API for adding package assets no longer throws an error,
    making it easier to share packages between pre- and post-1.2 versions of
    Meteor. #5458


When I run my app with 1.2.1-rc.1 , I get this:

 Conflict: Constraint less@2.5.0_3 is not satisfied by less 2.5.0-rc.0_4.
   Constraints on package "less":
   * less@=2.5.0-rc.0_4 <- top level
   * less@2.5.0_3 <- store-list 0.0.1

packages/store-list/package.js has this:

  Package.onUse(function(api) {
    api.use('ecmascript', 'client');
    api.use('frozeman:template-var', 'client');
    ], 'client');

  api.addFiles(['storelist.html', 'store-list.js', 'storelist.less'], 'client');

I don’t have less pinned to a specific version in .meteor/packages

Is this expected? I don’t have it pinned to specific versions anywhere.


Oh gosh. The whole interaction with “wrapped versions” and “pre-release versions” is weird. Going to ask someone how to fix that.


Filed an issue, hopefully we can fix some stuff so this never happens again.

Published 1.2.1-rc.4!


Let me know if it works for you now with 1.2.1-rc.4.


It works! Thanks. …



The new version of React does not wait?


I successfully upgraded Wekan to Meteor 1.2.1-rc.4. I’m especially happy with the corejs ES2015 polyfills, because previously I never known which functions were polyfilled or not. Now I can finally use utility functions like .includes() or .trim() with confidence :slight_smile:

I was a bit afraid that #4584 would break this kind of code try { check(a, b); } catch(e) { ... } but thankfully I’ve just misread the changelog and the check public interface hasn’t changed and still throws.


What’s the difference between ecmascript in 1.2 and ecmascript-collections / ecmascript-runtime?


Hey @benjamn is still working on documenting exactly what ecmascript features are new in 1.2, but I think it now supports basically all of the available polyfills from core-js? This means new stuff like Symbol, Object.assign, etc.

The package was renamed because before it was just a polyfill for Map, Set, etc, but now it has polyfills that aren’t related to collection classes so the previous name didn’t make sense.


Everything working here.


I needed this, so switched my project. Seems to be working fine!


So ecmascript-collections (now ecmascript-runtime) is a runtime polyfill, whereas ecmascript is transpiled?


ecmascript uses ecmascript-runtime under the hood, to create a complete ES2015 experience. If you wanted to, you could use ecmascript-runtime by itself, and have a different transpiler.

So you can use ecmascript-runtime standalone, but not the other way around.


Thanks for the explanation. Makes sense now!


@sashko - Hi, seems you dropped this message from being PINNED to the top. Does this mean you are ready to go for the release 1.2.1 or just in case of updating from discourse forum?


So when you set something to be pinned, you have to put in a certain date, and I chose today for some reason. Should have given it a few more days of buffer room.

But on an unrelated note, I do think it should be ready to ship today, just running some more QA and polishing up some docs.

The best place to track this stuff is the GitHub issue:


Yep, the QA seemed to go well.

Unless anyone runs into any problems with the RC, the 1.2.1 release is going forward today.

Cheers! You’ll know when it’s out.


1.2.1 is out! Thanks for testing, everyone!

Let’s get those PRs and bug fixes in for 1.2.2 :]