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:
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
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 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.
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.
Use separate git branches, and merge after each successful test.
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.
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.
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.
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).
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.
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.
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.
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.
