• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

sdougbrown / umpire / 24250696608
93%

Build:
DEFAULT BRANCH: main
Ran 10 Apr 2026 03:32PM UTC
Jobs 1
Files 27
Run time 1min
Badge
Embed โ–พ
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

10 Apr 2026 03:31PM UTC coverage: 94.433% (-0.03%) from 94.463%
24250696608

push

github

web-flow
โœ… 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

Uncovered Changes

Lines Coverage โˆ† File
1
93.56
0.37% packages/core/src/umpire.ts
1
84.38
packages/zod/src/validation.ts
Jobs
ID Job ID Ran Files Coverage
1 24250696608.1 10 Apr 2026 03:32PM UTC 27
94.43
GitHub Action Run
Source Files on build 24250696608
  • Tree
  • List 27
  • Changed 3
  • Source Changed 3
  • Coverage Changed 3
Coverage โˆ† File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #24250696608
  • 13407e13 on github
  • Prev Build on main (#24215693095)
  • Next Build on main (#24252220267)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc