With Meteor 2.8 has started migration towards removal of Fibers. This includes a major changes in Meteor core itself, not to mention the impact it is going to have on the entire package ecosystem. To make this easier for everyone after Meteor 2.8 new API endpoints started emerging mirroring the existing one, but having Async added to their name. So meteor.call() can also now be used as meteor.callAsync(). This new API though is not synchronous like the original, but instead is, as the name suggests, asynchronous and requires the use of async and await. More and more API endpoints will be converted to this method so that Fibers can be finally removed from Meteor and Meteor can upgrade to the latest Node version. You can read more about it on the Meteor Guide and in documentation. Also keep an eye out on the changelog to see which new APIs have been added. There is also a GitHub project to see the current progress.
With Meteor 3.0 being scheduled to be released no later than in April the time has come to start preparing the Meteor Community Packages for this big step in similar manner.
This has been a debate on our MCP monthly planning meetings and a discussion has been started on our organizational repository. Stuff like versioning, common approaches, priorities etc. will be decided there.
We have a GitHub project to track the overall progress.
The first step is to determine priority (there just isn't enough maintainers to do work on all of them at the same time). We'll start with those that will either be super quick (so that we can practice what needs to be done) or those that are the most popular and widely used.
The second step will be to determine if the package is affected and will require the any changes related to async/await.
Third will be listing all the changes and assigning a maintainer who will oversee the efforts.
Then finally work will be able to start. This will take a priority over any other features.
There are two APIs that need to be taken into account in packages.
First the one calling Meteor API and other packages. Where possible, without breaking established pattern, migration towards the new API should occur. This will require bumping up minimum Meteor version so a discussion will still have to happen if there should be a feature or breaking version release happen.
Second API of the package. Same like Meteor is doing with its API so should the packages. Same concerns with versioning like above apply here.
In both cases a breaking version release will then happen after Meteor 3 release due to the changes in code.
Now that you know what is the plan I would like to invite you to join the discussion and, even better, to contribute in this huge endeavor.
If you would like to contribute you don't even have to write to me (though that is welcomed as well), just pick a repository, analyze it (or if you feel like it start coding already) and then submit you findings in a new issue on the repository. I will then link it to the board so that others can join in as well.
Hope to see you out there!
If you like my work, please support me on GitHub Sponsors ❤️.
Top comments (0)