Pimm / ruply / 35591053901

100%

master: 100%

Pull #7

github

fix(types)!: type chains with a state machine instead of intersecting

run and runIf detected asynchronicity by intersecting all step types
(`T & Z & …`), apply by intersecting all callback return types. Two
sync types without overlap (number and string, or a void callback
followed by a number-returning one) collapsed that to `never`, and
with it the whole return type. apply additionally typed callbacks
that are only sometimes asynchronous as always asynchronous.

A chain now carries a small state instead: still synchronous, turned
asynchronous, or ended by a step which never produces a value. Each
step advances the state through a lookup table, and the state is
applied to the result once at the end. runIf excludes null-ish values
per step, contributing each step's null-ish part to the result with
the state the chain is in at that point. Two things follow for free:
a step which is always null-ish ends a runIf chain even when a later
step is asynchronous, and callbacks spread from an array keep their
position, so an asynchronous callback after a spread still makes
apply asynchronous. apply gets an overload per number of callbacks,
like run, plus overloads for the spread shapes. A spread array is
typed as a whole, so an array holding callbacks of several types
counts as possibly asynchronous; only one fixed callback on either
side of a spread is told apart, further ones are absorbed into the
array, which costs precision but not soundness.

This shape is chosen for consumers which build declaration files: an
unannotated generic wrapper around a chain gets these helper types
spelled out in its own declaration file, and with helpers nested
inside each other that grew exponentially with the number of steps.
With the state mentioned once per step it grows linearly for run and
apply and quadratically for runIf, and no helper needs to be
exported. A test compiles such wrappers.

BREAKING CHANGE: callback parameter types use the lib's `Awaited`, the
only promis... (continued)

14 of 14 branches covered (100.0%)

Branch coverage included in aggregate %.

1 of 1 relevant lines covered (100.0%)

412.0 hits per line