Meteor 3.0-beta.6 is out!

We have a new release: meteor 3.0.0-beta.6


  • Node was updated to v20.11.1
  • Npm was updated to v10.2.4
  • Push to deploy works with meteor v3.0 apps.
    The push to deploy docs is here, and those who want to use the CLI to deploy your meteor v3 app can use the following command:
meteor deploy ––free ––mongo 

Bug fixes:

Known bugs:

Projects that use React can get issues with react-meteor-data. Make sure that you are using the 3.0.0-beta.1 version. Check your .meteor/versions file.
If your app is not using the correct version, you can solve it by running: meteor remove react-meteor-data, and then meteor add react-meteor-data@3.0.0-beta300.1

How to test it?

Existing projects:

meteor update --release 3.0-beta.6

Starting a project:

meteor create app-name --release 3.0-beta.6

If anyone finds any issues, please let us know! Your feedback is essential to us.


Are there still plans to backport any of these async changes to 2.x for migration purposes?


I noticed lots of packages have major version jump but still in alpha stage. I guess we will use them in 3.0 RC or later.

Newer versions of the following indirect dependencies are available:
 * babel-compiler 7.11.0-beta300.6 (8.0.0-alpha300.11 is available)
 * babel-runtime 1.5.2-beta300.6 (7.0.0-beta.30 is available)
 * base64 1.0.13-beta300.6 (2.0.0-alpha300.11 is available)
 * binary-heap 1.0.12-beta300.6 (2.0.0-alpha300.11 is available)
 * callback-hook 1.6.0-beta300.6 (2.0.0-alpha300.11 is available)
 * check 1.3.3-beta300.6 (2.0.0-alpha300.11 is available)
 * core-runtime 1.0.0-beta300.6 (2.0.0-alpha300.11 is available)
 * ddp 1.4.2-beta300.6 (2.0.0-alpha300.11 is available)
 * ddp-common 1.4.1-beta300.6 (2.0.0-alpha300.11 is available)
 * ddp-rate-limiter 1.2.1-beta300.6 (2.0.0-alpha300.11 is available)
 * diff-sequence 1.1.3-beta300.6 (2.0.0-alpha300.11 is available)
 * dynamic-import 0.7.4-beta300.6 (1.0.0-alpha300.11 is available)
 * ecmascript-runtime 0.8.2-beta300.6 (1.0.0-alpha300.11 is available)
 * ecmascript-runtime-client 0.12.2-beta300.6 (1.0.0-alpha300.11 is available)
 * ecmascript-runtime-server 0.11.1-beta300.6 (1.0.0-alpha300.11 is available)
 * ejson 1.1.4-beta300.6 (2.0.0-alpha300.11 is available)
 * facts-base 1.0.2-beta300.6 (2.0.0-alpha300.11 is available)
 * fetch 0.1.4-beta300.6 (1.0.0-alpha300.11 is available)
 * geojson-utils 1.0.12-beta300.6 (2.0.0-alpha300.11 is available)
 * hot-code-push 1.0.5-beta300.6 (2.0.0-alpha300.11 is available)
 * http 1.4.4 (2.0.0 is available)            
 * id-map 1.2.0-beta300.6 (2.0.0-alpha300.11 is available)
 * inter-process-messaging 0.1.2-beta300.6 (1.0.0-alpha300.11 is available)
 * launch-screen 1.3.1-beta300.6 (2.0.0 is available)
 * localstorage 1.2.1-beta300.6 (2.0.0-alpha300.11 is available)
 * logging 1.3.3-beta300.6 (2.0.0-alpha300.11 is available)
 * mobile-status-bar 1.1.1-beta300.6 (2.0.0-alpha300.11 is available)
 * modern-browsers 0.1.10-beta300.6 (1.0.0-alpha300.11 is available)
 * modules 0.19.1-beta300.6 (1.0.0-alpha300.11 is available)
 * modules-runtime 0.13.2-beta300.6 (1.0.0-alpha300.11 is available)
 * modules-runtime-hot 0.14.3-beta300.6 (1.0.0-alpha300.11 is available)
 * mongo-decimal 0.1.4-beta300.6 (1.0.0-alpha300.5 is available)
 * mongo-dev-server 1.1.1-beta300.6 (2.0.0-alpha300.11 is available)
 * mongo-id 1.0.9-beta300.6 (2.0.0-alpha300.11 is available)
 * npm-mongo 4.16.1-beta300.6 (5.0.0-alpha300.11 is available)
 * ordered-dict 1.2.0-beta300.6 (2.0.0-alpha300.11 is available)
 * random 1.2.2-beta300.6 (2.0.0-alpha300.11 is available)
 * rate-limit 1.1.2-beta300.6 (2.0.0-alpha300.11 is available)
 * react-fast-refresh 0.2.8-beta300.6 (1.0.0-alpha300.11 is available)
 * reload 1.3.2-beta300.6 (2.0.0-alpha300.11 is available)
 * retry 1.1.1-beta300.6 (2.0.0-alpha300.11 is available)
 * routepolicy 1.1.2-beta300.6 (2.0.0-alpha300.11 is available)
 * sha 1.0.10-beta300.6 (2.0.0-alpha300.11 is available)
 * socket-stream-client 0.5.2-beta300.6 (1.0.0-alpha300.11 is available)
 * tracker 1.3.3-beta300.6 (2.0.0-alpha300.11 is available)
 * underscore 1.0.14-beta300.6 (2.0.0-alpha300.11 is available)
 * webapp-hashing 1.1.2-beta300.6 (2.0.0-alpha300.11 is available)

Test deployment and selenium UI tests passing.

Meteor V3 is real.

Note that for this version of the beta, there is an issue configuring emails that looks like it’s already been resolved in a merged pull request.

I just came across this bug myself, hopefully Beta 7 includes this fix, kind of need it for auth :sweat_smile:

For sure! The PR is already merged and it’ll be in the next Beta.


When is the next beta? @grubba is working on the docs, @nachocodoner and you are fixing bugs here and there and pushing things but no clear estimate yet nor we know the hurdles left to be cleared.


Just wrote this quick update about this.

To summarize, we plan to release our last beta between this week and the next one.

After that, we’ll start working on our first RC.


Just finished migrating this big app to 3.0-beta.6, and it works a charm, bar a few already known issues, such as the email problem already mentioned above.

We will be testing it thoroughly in the next few days, so I will keep posting if we find anything.

It is amazing that many of the community packages are already compatible, thanks to the effort of a handful of community maintainers. Some packages, like aldeed:autoform@8.0.0-rc.0 had to be forked locally, as they are not yet published, but that is a minor inconvenience while we are at beta stage.

My understanding is that some packages will be added to the core. One of them is matb33:collection-hooks. Would be good if there was clear messaging when and how that would happen. There is ongoing work to migrate this package, but it is not clear if this is coordinated with either the community or Meteor Software as part of the envisaged integration into the core.


great to hear that!

Do you have any tips that you find out that might be helpful for others?

I would love to hear that as I’m working in a migration guide to meteor v3


With a delay, here are some tips. Mind you, we use a package-based architecture, in which the packages themselves have low or at least manageable coupling, which in turn helps to an extent with the problem of async bubbling up everywhere.

  1. Use separate git branches, and merge after each successful test.
  2. If using a package-based, or any kind of modular application architecture, load the minimum of modules, and modify as needed, to ensure a first successful boot. Then work your way up, adding the rest of packages/modules progressively.
  3. Start with a well defined, and relatively well-contained problem that requires switching to async/await. For instance, replacing the deprecated http package with fetch. Move through your entire codebase, and one by one, modify each function, then follow up wherever this function is called, and so on. This will help you keep the bubbling under control.
  4. Find another similarly well-contained problem, like perhaps instances of using Meteor.wrapAsync. Replace all these with async/await, or if you have callbacks, promisify them. Trace them across the entire codebase. Same goes if you ever used the Future option available with fibers. By the time you finish with these problems and their limited scope, a good chunk of your higher level APIs and Meteor methods and/or publications should have been upgraded to async/await, then your job becomes easier later.
  5. If you have isomorphic usages of Mongo APIs within synchronous functions that are not yet possible to change, like MongoDB queries inside SimplSchema functions, consider changing your approach. One such example can be seen in this post. This is a tough nut to crack and my advice is to use an approach like I describe here. This kind of refactoring should be performed on a stable version of your app & Meteor, then merged to your async branch(es).
  6. Heavy (isomorphic) usage of a particular package and its APIs, like alanning:roles and Roles.userIsInRole. In our case, we were already maintaining a forked version. So we ended up simply having a sync version of Roles.userIsInRole for the client. I know this may not be to everyone’s liking, but we do not really use isomorphism beyond schemas and collection declarations. So, oh boy, we would not start rewriting the entire frontend for the sake of some APIs that must be async for the sake of isomorphism. Then, on the server, we went and refactored all its usage to async, which meant we had to update all our internal authorisation APIs, which then caused another async bubbling, though still manageable.
  7. I am assuming you are working on an async-friendly Meteor version that is pre 3.0.0. So, work on all Mongo API related code and leave all changes that are only possible in 3.0.0 for the final step (like Accounts.<something>.) If you really are in a bind because of collection-hooks, like we were, you’d be happy to hear that there is a PR (see my previous reply) you can fork locally, at least while working on upgrading your app. Obviously, caveats apply; you may want to contribute to the fork, or wait for signs from Meteor Software as to what is going to happen with this package. In our case, given the minimal usage, yet essential, of this package, the fork does the job just fine while we are in testing phase.
  8. Once all your HTTP calls, Mongo API queries, Roles and other function have been refactored, and you are happy with the result, time to upgrade to Meteor 3.0.0. Change the usage of WebApp, Accounts APIs that need to be async.

This sounds way too simple, as it is indeed simplified. But our experience was that the workload was less dramatic in practice than what looked like in theory. Of course it depends on whether you inherited a codebase or it was yours to begin with. It depends on how well it is modularised, tested, and so on.

Also, it matters how many external packages you depend on. If I have to pinpoint to the single most important hiccup, this was it. I am not thinking of packages that really are essential, but we did use this opportunity to get rid of some that we only used very lightly.

[UPDATE] There we go, at least with respect to alanning:roles, the community approach is going to be the same as what we did: What's left until an official Meteor 3.0? - #27 by storyteller


We had it tested thoroughly and I can happily report that, in our context, we did not find anything worth reporting. :partying_face:

1 Like

Your feedback is important. I appreciated delving deeper into your explanation here. It’s inspiring to witness a big Meteor application, with a complex structure of packages and modules, successfully migrated to the new version. The “divide and conquer” approach you outlined offers helpful insights for anyone tackling similar migrations.

I plan to perform similar steps soon. Thank you!