Meteor 2.4 Release Candidate

Meteor 2.4 Release Candidate is out! You can help by testing it today and providing your feedback!

You can update by running:

meteor update --release 2.4-rc.6


  • Typescript updated to v4.3.5
  • Email package now allows setting Email.customTransport to override sending method.
  • Use createIndex instead of _ensureIndex to align with new MongoDB naming.
  • Apollo skeleton has been upgraded for Apollo server v3
  • reify has been updated to v0.22.0 leading to performance gains
  • You can now set publication strategies SERVER_MERGE, NO_MERGE and NO_MERGE_NO_HISTORY. These control the behavior of the Meteor mergebox, providing a compromise between client-server bandwidth usage and server side memory usage. Use the Server.setPublicationStrategy(collectionName, strategy) and Server.getPublicationStrategy(collectionName) See PR for more details

Meteor Version Release

  • Skeletons dependencies updated

  • meteor-tool@2.4

    • meteor show now reports if a package is deprecated
    • reify update to v0.22.0 which bring optimizations for imports, read more
    • Apollo skeleton now uses Apollo server v3 - migration guide
    • Upgraded chalk to v4.1.1
    • Typescript updated to v4.3.5
    • METEOR_SETTINGS will now be only ignored in development mode and passed on in every other circumstances
  • webapp@1.12

    • npm dependencies have been updated
    • Added option to change runtime config in your app, read more
    • @vlasky/whomst@0.1.7
  • logging@1.3.0

    • Switch from cli-color to chalk to have the same dependency as meteor-tool
    • Fix detecting eval
    • Copy over code from Meteor._debug to Log.debug which will be deprecated in the future
  • email@2.2

    • Modernized package code
    • Add alternative API function that you can hook into to utilize your own sending method: Email.customTransport
  • ddp-server@2.5.0

    • One of three different publication strategies can be selected for any Meteor publication - SERVER_MERGE, NO_MERGE and NO_MERGE_NO_HISTORY. These control the behaviour of the Meteor mergebox, providing a compromise between client-server bandwidth usage and server side memory usage. See PR for more details
  • mongo@1.13.0

    • Add createIndex as a collection function (in MongoDB since MongoDB v3). This is a new name for _ensureIndex which MongoDB has deprecated and removed in MongoDB 5.0. Use of _ensureIndex will show a deprecation warning on development.
  • accounts-base@2.1.0

    • Migrated usage of _ensureIndex to createIndex
  • accounts-password@2.1.0

    • Migrated usage of _ensureIndex to createIndex
  • oauth@2.1.0

    • Migrated usage of _ensureIndex to createIndex
  • oauth1@1.5.0

    • Migrated usage of _ensureIndex to createIndex
  • service-configuration@1.5.0

    • Migrated usage of _ensureIndex to createIndex
  • ecmascript-runtime-client@0.12.0

    • core-js@3.16.0
  • ecmascript-runtime-server@0.11.0

    • core-js@3.16.0
  • ecmascript-runtime@0.8.0

    • Version bump to ensure changes from server & client runtime get propagated.
  • tinytest@1.2.0

    • Add option to temporarily replace Tinytest.add or Tinytest.addAsync by Tinytest.only or Tinytest.onlyAsync so only the tests added using only* are going to be executed.
  • test-helpers@1.3.0

    • Support for Tinytest.only and Tinytest.onlyAsync
  • modules@0.17.0

    • Update reify to 0.22.0
  • standard-minifier-js@2.7.0

    • @babel/runtime@7.15.3
    • Code modernization
    • Improved error handling
  • minifier-js@2.7.0

    • Added tests
    • Code modernization
  • standard-minifier-css@1.7.4

    • @babel/runtime@7.15.3
  • minifier-css@1.6.0

    • Updated dependencies
      • postcss@8.3.5
      • cssnano@4.1.11
  • callback-hook@1.4.0

    • Added forEach iterator to be more in-line with the ES use for iterations. each is now deprecated, but will remain supported.

Is there a documentation on what each of the strategies mean?

Also, does this have any effect for projects using redis-oplog? My assumption is that it also work for redis-oplog but just need to be sure

I believe Vlasky is still going to write the doc, @storyteller is coordinating this.

But you can see the notes in the code explaining which one:

The default one preserves the behavior of Meteor today.

About Oplog, if it uses the Merge box in the same way (I don’t remember this part of Oplog to be honest) the other options should work as well.


You can now set publication strategies SERVER_MERGE , NO_MERGE and NO_MERGE_NO_HISTORY

Isn’t this big news for scalability? +1 for documentation.

I’m wondering what the process for version recommendation for the node bumps are. I recently updated meteor to 2.3.2 using meteor update, but then discovered there was actually 3 more minor versions in the 2.3 line up to 2.3.5 with critical nodejs security releases, but aren’t sure if they’re stable or not since they aren’t recommended.

1 Like

I am having a production build error during the terser step when upgrading from 2.2.3 to 2.4-rc.0: packages/minifyStdJS/plugin/minify-js.js:49:25: terser minification error (SyntaxError:Unexpected token: punc (.))

Yes, it’s a nice way to save resources in the server.

The documentation will come with the final version.

We usually release a new version in the same day or day after a Node.js security release but we wait a few days to get feedback before recommending it but 2.3.5 is already recommended now. And yes, you should update.


We ran our tests on our main app using the RC version and everything passed. So this looks like it will not affect those using redis-oplog. What I cannot confirm yet is if the new feature will work. There is a possibility that redis-oplog is bypassing the mergebox. At the very least, there is no effect so this is still good.

1 Like