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.
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 )
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.
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.
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.
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
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 . 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.
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.
We forked locally and migrated a bunch of packages:
aumel:security-authorization
storyteller:cdn
reywood:publish-composite
meteorhacks:meteorx
meteorhacks:sikka
meteorhacks:inject-initial
simple:json-routes
meteorhacks:ssr
coagmano:stylus #(Only v1, because we need cross-package imports but v2 is also relatively easy)
useraccounts:*
kadira:blaze-layout
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.
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.
)
. 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.
But I have faith in you!