Looking for help migrating packages to Meteor 3.0

I will repro from source code early next week (away for the weekend) - I suspect it’s just a matter of wrapping the main callback sent to dart with a Meteor.bindEnvironment.

Great, enjoy your weekend! Thanks

OK so this should be made more visible in the documentation somewhere, or maybe even considered a bug:

Compilers that rely on the meteor caching-compiler package cannot be dual-published for Meteor 2 and 3.

The details are a bit hairy, but I learnt from zodern that when publishing a compiler plugin (isobuild), the package will include copies of processed (reify+babel) meteor dependencies that are then used instead of using code from the installed meteor version. This ONLY applies to build plugins.

The caching-compiler code as emitted when publishing for Meteor 3 is incompatible with Meteor 2 and vice versa.

1 Like

It would likely be possible to modify the code in the Meteor 3 version of caching-compiler to work in both Meteor 2 and 3 by removing all usages of the async and await keywords and use raw Promises instead since Promises in Meteor 2 are backed by fibers.

Apologies if this was covered, but what is the state of redis-oplog? Two quick notes:

  1. I see it listed on row 53 on the original spreadsheet:
    Meteor 3.0 Packages Compatibility - Google Sheets

  2. I also found a migration here: meteor-packages/redis-oplog at main · quavedev/meteor-packages · GitHub

I also feel like I read a post that it’s potentially going to be pulled into Meteor core?

Thanks for clarifying!

Seems to be a misunderstanding of which repository the package is using

I’ll be happy to merge PRs and publish new versions. I’m currently unable to contribute more than that.

As for it being pulled into core that is something being considered for Meteor 3.1 and discussion is ongoing. Most likely is going to happen, the bigger question is how to make that happen properly. There is also now DDP-router that can change the game a bit:

That sounded like a Galaxy thing. I hope Meteor is not going with 3.1 into the … Galaxy direction ending 2-3 years down the line like … Meteor Pro and Meteor Community.

Just wanted to point out that a new version of collection hooks got released thanks to the great efforts of Berislav Hunjadi / @bhunjadi .

5 Likes

This is amazing news! Thank you, @bhunjadi!

2 Likes

any updates on the package littledata:synced-cron?
seems like its not being being maintained and its holding me back from updating to meteor 3.
there are PR and issue on github that seems like people did help on updating it but no one is reviewing or approving.

if anyone has a better solution and a different package that does synced cron which is compatible with meteor 3, please let me know

synced-cron has been ready for Meteor 3 for a while now. It is maintained here:

2 Likes

what about universe:18n

When i install meteor 3.0.2 beta.4, its installing the 2.1.1 but now there is version 3 which support meteor 3 and im not able to download it or update it
any solution on this matter?

I have just tried universe:i18n@3.0.0 and it is working perfectly with METEOR@3.0.2-beta.4

2 Likes

Any updates on swydo:ddp-apollo? It’s helpful for people who want to use postGres and/or other databases. I was able to get my Apollo GraphQL code working in Meteor v3 without it, but it was quite a lot of work.

swydo:ddp-apollo is outdated in the Apollo world as well. I think, given that the other Swydo projects aren’t being updated, we will have to do a fork.

I have code now that connects ApolloGraphQL to Meteor resolvers, with support for queries, mutations and subscriptions, and which puts the Meteor user object, and userId into context. I would be happy to contribute this code to the package.

2 Likes

Yes, let’s figure out the best way we should have Apollo in Meteor. Probably best to build a new package or expand the official one.

I don’t know anything about building a Meteor package, but I can contribute this code.

Shouid we do a video call/programming session?