How come this package is not stable?

[lindeberg]

@sergeyshaykhullin you mentioned that this package is not stable. What do you mean by that? Is it production ready? If not, what is missing or what are the issues?

[sergeyshaykhullin]

You can use it is production, i cover a lot of use cases and have 99%+ test coverage. I am using it every day and for now have no troubles and new bugs

This is package is not stable, because i am not sure in public api stability:

• I have one issue which i can't close without a lot of internal rewrites and may be public api breaking changes
• I have some closed prs with ideas to migrate to strongly typed errors
• I want to migrate to middleware approach to compose and reuse code
• Also i am using some parts of functional programming inside and have some space for improvements and reimplementations

This is my internal roadmap and mostly "nice to haves"

I mentioned FairyBread, it has already 6 major version, but package was released less than year ago

I prefer Rust approach, when 1.0.0 is stable version with stable apis. A lot of pretty decent Rust crates has 0.x versions - no commitment to not to have breaking changes in public apis

[sergeyshaykhullin]

It is now in errors field. The main problem is that errors has no well-defined schema = not strongly typed and something like apollo-client or StrawberryShake can't generate models for them

[lindeberg]

Found this in the HC-slack

[sergeyshaykhullin]

It is not a problem, all HC validation libraries is using errors, but i did some r&d and discovered alternative approach based on HotChocolate

[lindeberg]

Why need to have types? What would the types be? "FirstNameNullOrWhitespaceError"? A ValidationError with
Code
Message
Field
is fine?

[sergeyshaykhullin]

You can see draft prs for more details. You need types for results to generate... Ok(payload) or Error(validation details) with the same shape as input parameters