Vote for the future of this package

[jankapunkt]

As I explained already in #741 there is no way to make this package optionally async.

Either we stick with the current state (sync style) or make it fully async.

Consequences:

stick with sync

• no changes for most dependencies
• no support for MongoDB operations in computed values on the server (client unaffected)

go fully async

• all dependants need a full update
• full support for async in computed fields on the server

[lynchem]

Nice work Jan 👏🏻
It seems we're outnumbered here on the current results but I'd say keep it sync. It limits what you can do a little but maybe that's not a bad thing. We're currently trying to rein in our overuse of autoform: options in our schema definitions and only provide them on the client. Looking at our use...

• allowedValues: We're generally pointing to an enum. Fine.
• autoValues: It's most this.userId and new Date() - also fine.
• custom: We've mostly just looked at other fields so all fine.

Have I missed something obvious? I think we'd be fine with the sync version and it might encourage keep schemas clutter-free by not allowing async?

Edit: Is it worth trying to get to a sync v3 compatible version first and then go for async ? I imagine the likes of Autoform will be much easier with this sync version and could unblock some people.

[aldeed]

I won't vote since I no longer use Meteor or this package in my day-to-day work, but could you create a new package that is async leave this one as is? Or a new major version and maintain both.

[simonwebs]

I think its good to create package that match with modern node instead trying to do something then will lock on the way

[StorytellerCZ]

I think doing a major version release and continuing maintenance of the previous one is the best approach.