As you might have seen in this post in this topic(current state of Blaze), we have launched a how to be ready for meteor v3.x guide. In this guide, we cover the methods that were updated to have an Async counterpart.
It’s also a bit of a tough nut because it’s a mix between a moving target (everything isn’t final yet, see blaze / tracker / autoruns / methods / packages), and b) I’m not even sure all scenarios are actually fully covered yet.
I think this could become more of a community thing, where everybody who has something to contribute could add his current experience.
I have some things we’ve tried so far & could give an intermediate experience report, unfortunately it all takes time…
Is there maybe someone in the community who’d like to help out to gather & organize the information maybe? Somebody who enjoys doing some technical writing?
I could help setting up the writing environment & help to organize the information, for example.
And then everybody who is working on and / or had some success preparing their apps for 3.0 would be invited to share and contribute his experience?
So if you have migrated you app successfully to 2.13 and/or Meteor 3, maybe let yourselves be known & maybe we can all work together on this?
Could we maybe merge these two threads & maybe make a workgroup-thread for those willing to contribute to it can organize themselves?
Great stuff @xet7 ! Very nice. We should add this to a general migration document…
It’s still kind of rough and not for the faint hearted yet I’d say… can I ask whether you’re finished yet / did you get it to run yet actually, given that there still were issues with Simpl-Schema in the end?
Yesterday I did not yet have time to try those fixes in Meteor 3 Async PR, can they fix Simp-Schema errors. I will continue fixing and adding remaining dependencies, or changing to compatible dependencies. It is kind of, when I fix one error, then it shows next error, so there is not too much to fix at one step, it’s quite clear what to do.
Good thing is, that there is already all WeKan code for server and client, and those do not show errors when running with Node.js 18, so it’s just about adding remaining dependencies, sometime I will look when web UI becomes visible.
I have a small project that I migrate now. I think I am close to success. Maximum another 2 weeks and I think I can see my home page :).
Grapher is a bi*** and Push with Firebase (didn’t get it yet to install NPMs in Node 18).
For Meteor.bindEnvironment(...) we just remove the binding?
I think it depends. Meteor Environment Variables are now built on top of async local storage, which preserves the value automatically in many cases, but not all. If you were using bindEnvironment to run the callback in a fiber, then it is no longer needed. If you were using it to preserve the environment (for example, for Meteor.userId() to work), then it might not hurt to keep using it.
There are different topics (forum/slack/GitHub) asking related questions. Deprecated information is, unfortunately, challenging to go back to and correct. Worse, there are instances that different people are giving conflicting information.
In an ideal scenario, when someone asks about migrating from Meteor 2 to Meteor 3, we link them to the centralized documentation. Even if the information changes in the future, at least anyone who lands on the same question and follows the link will get the updated information. When a new question is asked that the migration document does not cover, update the document and answer with a link to the updated documentation.
Unfortunately, the current “Guide” page is not ideal for this as it is not “current enough” for the questions being raised and requires answers centralized into a “live” documentation.
