sdougbrown / umpire / 24250696608

93%

push

github

✅ Core Validation & Zod Integration Improvements (#6)

* ✅  Add validation as first-class concept

It may not always apply but it's better for it to be understood. I still
have no intention of taking on *how* things are validated, but it makes
sense to understand *whether* they are or not. This makes validation
compostion easier and allows for better devtool introspection.

This is a first pass and doesn't get all the way to cleaning up the zod
integration but i feel like this is on the way.

* ✅  Core Validation API & Zod Integ

Trying to make it easier to work with a composed validator means
bringing *some* knowledge of validation into core without owning it.
Tough line to toe. This may thread that needle but I'll have to look at
it more with fresh eyes tomorrow.

* 🤖  Simplify Example Type for SSO gate

Looking to see if it's reasonable to suggest this as a pattern and there
was WAY too much type boilerplate there before. This isn't bad but could
be better.

* ✂️  Cut unnecessary passing of zod to integ

Not sure how i missed this before but this isn't really necessary at
all. The umpire zod integration already imports zod so why are we
forcing users to pass it in?

* 🧹  Clean up unnecessary pass-through export

* 🧹  combine `isRecord` guard in zod integ

* 🧹  type readability grouping

* 🤝  Shared `check` and `validator` internals

An internal union makes sense to simplify checks on whether a predicate
is "supported" so they can share otherwise similar code paths. Don't
want to broaded the public `check()` api as that would lead down a
bewildering path, but this seems like an ok step to a tighter internal
structure.

* ✍️ document empty/satisfaction semantics wrt valid

important to document the different between empty and "satisfied" and
how it interacts with validity in case ownstream users want different
behaviour. fwiw i think we have it right, but it may not play nice with
what someone else wants to build!

* 👨 Normalized Validation Type

Pre... (continued)

558 of 632 branches covered (88.29%)

Branch coverage included in aggregate %.

108 of 110 new or added lines in 7 files covered. (98.18%)

1325 of 1362 relevant lines covered (97.28%)

206.5 hits per line