Migration and compatibility of third-party packages

community
1

Hello everyone, in order to enable the anticipation of application migration, asynchronous versions of functions related to calls to Mongo were introduced from version 2.10 onwards. This was implemented by returning a Promise.resolve(…). However, within the Meteor core, synchronous calls to Mongo are still considered. To migrate some packages, such as cultfcoders:redis-oplog or matb33:collection-hooks, it is necessary to have an asynchronous implementation in the Meteor core. Do you think we will be able to migrate these packages only after the release of version 3.0? Does anyone see any criticality in the future migration of these packages?

Regarding the accounts package, which is often used for custom implementations, the same problem exists: the internal calls are still synchronous, but I assume that they will also have to become asynchronous.

Thakns.

2

PRs for these packages are welcome. I’m planning to actively start looking into it once Meteor 3 Alpha starts releasing, till then I just can’t justify the time due to my other engagements.

1 Like
3

Thanks @storyteller, we could certainly collaborate on these issues, the questions referred to the fact that I think it is necessary to wait for the full version 3 in order to proceed. For example, some of the changes concerning the redis package are closely related to the necessary changes to the allow-deny logic of the Meteor core that have not yet been dealt with. The same for the account management core. From a quick look at version 3.0, I see that the asynchronous component of mongo calls has not yet been fully treated.