Thank you Jan, really useful to get updated on the challenges on community packages.
meteor-mocha & meteor-mocha-core
The Mocha packages are part of Meteor Testing. Both packages will get releases during Hacktoberfest in preparation for Meteor 3.0 release. In the meantime you can help with fixing bugs and for example working on better integration with VS Code.
As mentioned here, I already expeirmented with test packages for Meteor 3.0 by removing the fibers. I am not sure if I should proceed there with a PR since I don’t know if those changes are already covered or assigned. The post you wrote reflect that it will get releases and I assume someone is in charge since you ask help for other issues.
My change is a minor change to remove a single point using fibers and have compatibility with latest Meteor versions.
Regarding meteor-browser-tests, I use it on my projects but I had to adapt a bit the driver I use “puppeteer”. However, I saw the issue you mentioned and found the github issue of having problems with chromedriver too and surely it happens through all drivers since newer selenium 4,x changed the API and produces breaking changes. I will be reviewing them as I have time to dedicate to OS,
Hi @storyteller, at first glance, in the community packages I do not find zodern:types widely used as a dependency. Will this be included or will it have to be handled solely by @zodern?
The same applies to raix:eventemitter used by collection2.
@storyteller thank you for the clarification. In your article you mention the style of the code, do we use the ‘@quave/quave’ library or is there some document that describes the details?
We’ve had a fork of tabular for a long long time. It’s got some fixes for a memory leak and we recently added the ability to plug your own search into it so we could use atlas search. I’m guessing the thrust of this will be to get everything ready for 3.0 though or are you interested in getting updates as well as 3.0 compat?
We also have an npm simple schema 2.0 fork with a fix working on nested schemas. What’s the reasoning on moving it back to a meteor package? 2.0 is a little annoying in that you have to wrap the schema with tracker to get reactivity on the client but now that’s it done it’s possibly better to keep it like that than moving it back? Or are there some other benefits?
In general each package needs to have Standard.js, TS Types via zodern:types or re-written into TS, GitHubActions to run lint test and any migrate any existing tests to GitHub Actions.
@marklynch we’ll take everything, but Meteor 3 compat is going to get priority.
For simple-schema @jkuester is managing that. The idea to move back is to have everything in the same package, especially since for the latest simpl-schema you need to do a wrap for Meteor
The packages list is a bit large and I think it can do better with priority/strategy, in my opinion. I don’t use most of them and I’ve a large Meteor project, since I use mostly npm packages and the frontend ecosystem package (ReactJS in my case) which how it should be, why stretching us thin?
The key ones for me are the ones unique to Meteor backend and would break in 3.0 (e.g. roles). There are other infrastructure, such as packosphere, ideally these are merged with Atmosphere so it doesn’t stretch the community thin. I think the energy should be spend on things like meteor awosome, dev-tools etc that enhances the overall community with unique value add (as oppose to duplication).
I’d put low priority to blaze packages, and put in a separate section. The strategy should be to focus on packages unique to Meteor backend/collections etc that can’t be replaced with npm or another UI frontend ecosystem (react, svelte etc), why the Meteor community is still taking the load of many UI packages when it has been decoupled few years back?
Just my opinion, either-way thanks for putting this together
Everyone is going to prioritize different packages. That is not point of the list. The idea there is to give the grand overview with basic directions of what needs to be done in each, so that people can choose to work on packages that interest them or find a niche where they can have significant impact during Hacktoberfest.
Hi @alawi, Blaze is still widely used and is the only one of those listed that has been supported and developed since its origin by the Meteor team. I too have large applications that originated with Meteor version 0.x in which only Blaze was supported. I don’t think it is a good idea not to include it in the list. I agree that we can prioritise but certain packages are widely used and should be supported by the community anyway, e.g. collection2, redis-oplog, collection-hooks, roles, …
Will you please merge/push the changes you made to tabular to the community repository? I think tabular is an amazing package and since you went through the troubles of fixing things why not share your great work??
I personally wanted to help out with meteor-desktop and have already started to replace spectron with wdio-electron-service. The good thing that it shares quite similar API to spectron and meteor-desktop was built around it, even the testing APIs.
I didn’t want to bring it up initially because it’s still in the works and I don’t have much time. Plus, I’m having problems with making wdio take note of the integration testing files for some reason it can’t run them so I’d appreciate any help I can get.
Hello @grubba, @storyteller, I’m trying to complete the migration of the packages: collection2, redis-oplog and collection-hooks, but I can’t get clarification on issues concerning the new handling of remote collections and method calls. Is the right channel the forum, slack or github issues? Thank you.
Thanks @storyteller, I list the threads to which I have had no reply:
here, dealing with the problem of client-side use of mongo calls on remote collections
here, this is about support for asyncIterator supported in 2.13.3 but not in 3.0
In asynchronous calls to remote collections, the subscription works differently from previous versions:
Meteor.subscribe('subscribtionToCollectionA')
collectionA.insert({}, (err,id) => {
// the callback call happens after the subscription has been updated and all the documents are in the client
})
await collectionA.insert({})
// Here the subscription has not yet been completed and there is no way to tell when the data is on the client
