Feature request: Value.Assert and TypeCheck.Assert about typebox

[sinclairzx81]

@grenierdev Hi, Apologies for the delay in reply, and thanks for the suggestion.

At this stage, I'm not looking to add any new functions to the Value or TypeCompiler interfaces. The recommendation today is for users to implement their own Assert functions (as you have) using a combination of Check() + Errors() functions (as well as other Value processing functions if you need them).

The reasoning here is that TypeBox should only provide raw functions and guards, but not functions that use multiple internal calls to process a value (as would be the case for Assert using Check() + Errors()), this is just a general design constraint TypeBox has and applies to other aspects of the library. Also, the exception thrown for an Assert is currently deferred to the user to define (which may include ALL errors for the Exception, or only the first, noting your example includes ALL errors).

For now, I'm going to keep on with this design constraint (even if the Assert does seem to make sense from a convenience standpoint). I may review in later revisions, however this would be following some additional work to TypeBox's transforms which do implicitly Assert (so there is cross over between a general Assert an Transform decode Asserts which needs a review)

Will mark this one for consideration (but may close off temporarily).

Hope this brings a bit of insights
S

[grenierdev]

Thanks for the lengthy answer! I understand your reasoning.

I'm just going to add that I wouldn't mind that the .Assert doesn't use .Errors to construct a pretty assertion error message.

Maybe it's just aesthetic. My main reason for integrating that assertion function into the library is that I wouldn't have to use separate import statements for Value.Check(...) and Assert(...).

[sinclairzx81]

@grenierdev Hey, thanks for the follow up.

Maybe it's just aesthetic. My main reason for integrating that assertion function into the library is that I wouldn't have to use separate import statements for Value.Check(...) and Assert(...).

Yeah, I do appreciate the aesthetic side of things, but still need to be mindful of working outside the constraints imposed on the library. Historically, adding new convenience functions to TypeBox to simplify usage generally hasn't worked out well in the past, with particular abstractions (notably efforts to make type registration simpler (another function composed of existing TB functions)) had lead to a lot of confusion. Users will typically take on new functions as they are provided, and once they are added, it becomes very difficult remove or change them if there are problems with them (usually only identified once a function has been in the wild for a few months).

In the case of Assert specifically, as the function is a composite function (Check() + Errors()), and there is a need establish a viable AssertionError type, I do expect some churn getting an implementation correct (the devil is in the details). Additionally, given the cross cutting concerns with Transform types asserting for non-decodable values, I'm just a bit hesitant to change things here in the short term.

For now, Ill add a consideration tag to this issue, and investigate at a later time (post updates to Transforms), but will close the issue as out of scope (for now). The recommendation is still for users to implement their own assertion functions using the existing functions provided....but do somewhat agree the library could benefit from a simple Assert.

Hope this brings some additional insights
All the best!
S