Elegant validation library for type-safe input data (for TypeScript and Flow)
MIT License
Bot releases are visible (Hide)
Published by nvie about 5 years ago
[...things]
) in favor of Array.from()
.Published by nvie about 5 years ago
New feature:
map()
calls to throw an exception in the mapper function to rejectPublished by nvie over 5 years ago
New features:
instanceOf
decoders in TypeScript (see #308, thanks @Jessidhia!)predicate()
in TypeScript (see #310, thanks @Jessidhia!)Fixes:
Published by nvie over 5 years ago
Potential breaking changes:
pojo
criteria. Now, custom classes like new String()
or new Error()
will not be accepted as a plain old Javascript object (= pojo) anymore.Fixes:
Potentially breaking changes:
Changed the API interface of dispatch()
. The previous version was too complicated and was hardly used. The new version is easier to use in practice, and has better type inference support in TypeScript and Flow.
Previous usage:
const shape = dispatch(
field('type', string),
type => {
switch (type) {
case 'rect': return rectangle;
case 'circle': return circle;
}
return fail('Must be a valid shape');
}
);
New usage: docs
const shape = dispatch('type', { rectangle, circle });
Where rectangle
and circle
are decoders of which exactly one will be invoked.
Removed the field()
decoder. It was not generic enough to stay part of the standard decoder library. (It was typically used in combination with dispatch()
, which now isn't needed anymore, see above.)
pojo
decoder now returns Decoder<{[string]: mixed}>
instead of the unsafe Decoder<Object>
.
Fixes and cleanup:
Potentially breaking changes:
mixed
(TypeScript: unknown
) arguments, instead ofany
🎉 ! This ensures that the proper type refinements in thenew Date('not a date')
) won’t be considered valid bydate
decoder anymore.New features:
guard()
now takes a config option to control how to format error
messages. This is done via the guard(..., { style: 'inline' })
parameter.
'inline'
: echoes back the input value and inlines errors (default);'simple'
: just returns the decoder errors. Useful for use in sensitive contexts.Export $DecoderType
utility type so it can be used outside of the decoders
library.
Fixes:
Migration notes:
If your decoder code breaks after upgrading to 1.11.0, please take the
following measures to upgrade:
If you wrote any custom decoders of this form yourself:
const mydecoder = (blob: any) => ...
// ^^^ Decoder function taking `any`
You should now convert those to:
const mydecoder = (blob: mixed) => ...
// ^^^^^ Decoders should take `mixed` from now on
Or, for TypeScript:
const mydecoder = (blob: unknown) => ...
// ^^^^^^^ `unknown` for TypeScript
Then follow and fix type errors that pop up because you were making
assumptions that are now caught by the type checker.
If you wrote any decoders based on predicate()
, you may have code like
this:
const mydecoder: Decoder<string> = predicate(
s => s.startsWith('x'),
'Must start with "x"'
);
You'll have to change the explicit Decoder type of those to take two type
arguments:
const mydecoder: Decoder<string, string> = predicate(
// ^^^^^^ Provide the input type to predicate() decoders
s => s.startsWith('x'),
'Must start with "x"'
);
This now explicitly records that predicate()
makes assumptions about its
input type—previously this wasn’t get caught correctly.
New decoders:
tuple3
, tuple4
, tuple5
, and tuple6
unknown
decoder is an alias of mixed
, which may be more recognizable for