Looking for help migrating packages to Meteor 3.0

Hello guys, in an effort to reduce overlapping of work and centralize efforts. @DanielDornhardt asked me to create a list that contains at least the major packages and their current status. The major things going on so far:

We’ve created an excel sheet to track our work. It’s freely editable for anybody. You can select a package from the list and if nobody is an owner yet, you can set yourself and start working then report back your work.

For now, I’ll be taking on collection2. Looking forward to seeing some action from you guys.


Thanks for putting this together!

Thank you for your edits/comments. I’ve now enabled it for anybody to edit the document.

I’ve added some filters to make it sortable and make it “autodetect” whether the package is core or not (depending on if there’s a “:” in the name or not :slight_smile: )

1 Like

Can this be highlighted and filtered directly in Atmosphere?!

Could be but doing in it Packosphere would be faster @copleykj

There’s something that’s been bothering me and I thought it’d cleared up but it hasn’t been yet so here I am:

Meteor/@fredmaiaarantes folks said they’d bring in meteor-migrations, meteor-synced-cron, and meteor-collection-hooks yet Quave/@filipenevola are also working on it so which way to go? Did you guys sort this out between you? Are the Quave ppl going to update them to 3.0 then Meteor are going to merge them into the core? Please let us know.

  • There are 3 community packages that we want to bring to the core: meteor-migrations, meteor-synced-cron, and meteor-collection-hooks.
1 Like

Hey @harry97, we haven’t sorted that out between Meteor Software and Quave/@filipenevola. Our plan remains: we will bring those three packages to the core.

When we get there, we will look into the community packages, Quave’s, or the original packages (percolate:synced-cron, for instance, is being updated) to find out which one is more stable or well-crafted, for us to use as a base package and make the necessary changes to support Meteor 3.0, as well as adding more tests and/or covering edge cases. Perhaps Quave and community members will make the whole process easier. :slight_smile:


A not so “tiny” update: A new version of Collection2 has been released. You can try it now by updating your package to aldeed:collection2@4.0.0-beta.2. We’re eagerly awaiting your feedback here.

1 Like

I’ll be starting to mark packages that don’t need any migration work in blue. The first one is ostrio:cookies. I tried adding it to a fork of simpletasks and it works just fine.


@harry97 it’s maybe best if you put an explicit value in the status column maybe for explicitness (see zen of python: explicit is better than implicit) & sort / filterability. We can still use conditional formatting for colors & bling :slight_smile:

A not so “tiny” update: A new version of Collection2 has been released. You can try it now by updating your package to aldeed:collection2@4.0.0-beta.2 . We’re eagerly awaiting your feedback here

4.0.0-beta.6 is out which supports dynamic & static loading. And I forked meteor-schema-index which is compatible with the latest collection2. Please give it a go guys. This fork should hopefully make the leap to 3.0 a little bit easier.

I think now it’s also worth mentioning that my work on the 3.0 packages is being sponsored by Trusted Care AG/@DanielDornhardt which I wouldn’t have been able to do otherwise. They didn’t ask me to write this :stuck_out_tongue_closed_eyes:. I’m truly grateful to them and how they’re giving back to the community hopefully other companies in the Meteor space can follow suit.


Thank you @harry97 for your good work! At least I hope so, I didn’t check the PR yet! :smiley: But I have faith in you!

Thank you for helping out with the packages migration! Amazing work so far zoomer! :stuck_out_tongue:

1 Like

Another day, another update.


I am writing this comment to try to solve a package migration problem. In this regard, I started a discussion about changing the way packages are loaded, which makes some important libraries unusable for the time being. In my case: redis-oplog, lai:collection-extensions, mongo-collection-instances. In particular, all libraries that for some reason need to overload the collections constructor. The bug is tricky in that it can work in some cases, depending on when the package is loaded.

I would like to know if any of you have encountered this problem and if you have found a solution. Currently this problem makes it impossible to migrate my applications.

We had issues with a couple of monkey patches for Mongo. The patches are related to indexing, so kind of have to be used when the app starts. In our case, putting the code using the patches in Meteor.startup(...) solved the issue. But that’s only one use case.

Perhaps, with lai:collection-extensions, and mongo-collection-instances, consider loading them in a dedicated internal package, let’s call it pbeato:mongo, and export Mongo from it (those packages already load mongo by themselves). Put pbeato:mongo at the top of the packages file, and also import { Mongo } from 'meteor/pbeato:mongo' in whatever package/module you need it.

Cross posting here from Large SaaS migrated to 3.0.

We forked locally and migrated a bunch of packages:

coagmano:stylus #(Only v1, because we need cross-package imports but v2 is also relatively easy)

Some, like aumel:security-authorization, may not be everyone’s cup of tea, and unless the maintainer accepts a pull request, we’ll just keep it as a local fork.

Looking to contribute the changes to reywood:publish-composite, coagmano:stylus, and storyteller:cdn to the respective repositories, because they are still maintained.

However, what is to be done with the rest? Some, like simple:json-routes and useraccounts:* are under Meteor Compat Packages · GitHub, so I’m not sure there is anyone available to merge our pull requests there.

The kadira:* / meteorhaks:* packages - their maintainer is long gone, and these packages have been forked countless times. I am not keen on contributing further to this fragmentation, thus it is preferable that we do not put them under the illustreets namespace. So, I’m looking for ideas here. They are very useful, and like in the case of sikka, uniquely useful. Hopefully Meteor Community · GitHub would like to take at least some of them under their umbrella, and we will continue to maintain them for the foreseeable future.

1 Like

Some good news on this one. Our changes have been merged into this pull request: Update tests by StorytellerCZ · Pull Request #173 · Meteor-Community-Packages/meteor-publish-composite · GitHub. It is awaiting review and hopefully will be published soon.


A package often shunned because of performance issues with large collections (but that is just simply misuse!), otherwise very helpful in a multitude of use cases. We just submitted a pretty big pull request here: Meteor 3.0 compatibility by manueltimita · Pull Request #99 · percolatestudio/publish-counts · GitHub. The repo still looks maintained, so hopefully it will be merged soon.


Another package that seems to be still maintained (@storyteller’s pull request from 2 months ago got merged). We also submitted a pull request there, for compatibility with Meteor 3.0: Compatible with Meteor 3.0 by manueltimita · Pull Request #35 · deanrad/meteor-promise · GitHub


Unfortunately I cannot upgrade activitree:push until we get a buildable version of Meteor 3. Testing requires authorized domains and can only test it in production.
On Cordova side successful mobile builds are also required.

The alternative to activitree:push, as I noticed is using OneSignal or other 3rd parties but they are not GDPR compliant or at least they cannot guarantee confidentiality of messages.

Hopefully Beta.1 or 2 will be deployable to clouds.

This one should have now an update that should be fine with Meteor 3 beta.

Merging there is Meteor Software responsibility, so it should be able to get in.

We do have some of them under MCP. inject-initial sounds very similar to inject-data, we’ll have to look into this.