meteor-simple-schema

meteor-simple-schema copied to clipboard

This is now the updated migration base-branch, exceeding #740 / #738 This means all of the following tasks should be done in an own PR, pointing to this one's branch (migrate/3.0)

I come to the point to realize there is no way to support both sync and async computations. Since any method call will require async this bubbles down to all functions involved in the validation chain.

It's also nearly impossible to break up the existing syn structures and make them partially async using conditional return of Promises, where applicable.

It works for the labels but it does not work at all for doValidation which is basically the core validation routine, without making it all async.

I therefore will go down the path of making it fully async. Any objections please add here.

published 2.0.0-rc300.0 → compatibility with 3.0-rc.2

Hi @jankapunkt , is 2.0.0-rc300.0 already supporting async functions for autoValue ? It doesn't seem to work in my setup. Thanks !

Published aldeed:[email protected] which should allow for final Meteor 3 compatibility.

@jankapunkt for lint fixes I would be willing to move to Biome and standardize that across the entire organization. Thoughts?

@vparpoil no, async validate etc. is a much bigger effort than expected. For now we will only cover Meteor 3.0 compatibility (in terms of versions / dependencies) and tackle full async in another PR

@StorytellerCZ let's discuss biome in the organization repo / discussions there

I come to the point to realize there is no way to support both sync and async computations. Since any method call will require async this bubbles down to all functions involved in the validation chain.

It's also nearly impossible to break up the existing syn structures and make them partially async using conditional return of Promises, where applicable.

It works for the labels but it does not work at all for doValidation which is basically the core validation routine, without making it all async.

I therefore will go down the path of making it fully async. Any objections please add here.

@jankapunkt Any updates on this async computations?

@aashutoshshr I got stuck by https://github.com/serut/meteor-coverage/pull/95 which blocks most of my conributions right now, since without decent coverage it's really time-consuming and stressful to migrate/refactor code.

@StorytellerCZ I released a 2.0.0 as of today. It's stable in what it does and resolved the correct 2x/3x versions dependencies. Regarding async compatibility: we should make a vote