loosen peer deps constraints, bump a few dev deps versions #3
Conversation
| @@ -48,7 +48,7 @@ export function getArbitrary<T extends HasArbitrary>(codec: T): fc.Arbitrary<t.T | |||
| const type: HasArbitrary = codec as any; | |||
| switch (type._tag) { | |||
| case 'UnknownType': | |||
| return fc.anything(); | |||
| return fc.anything() as any; | |||
There was a problem hiding this comment.
Is it possible to use unknown here over any?
There was a problem hiding this comment.
It should be, but I kept any here for consistency with other lines below. Anyway, it does not make much difference in this case IMO
| "io-ts": "^2.0.1", | ||
| "fast-check": "^2.10.0", | ||
| "fp-ts": "^2.9.3", | ||
| "io-ts": "^2.2.13", |
There was a problem hiding this comment.
Note also that io-ts has deviated from semantic versioning above 2.1.3 😕
everything above 2.1.3 and below 3 is called "experimental"".
Not sure that this will play nicely with users still on a "stable" version, but I'm not sure of what the best approach is here. O how I wish io-ts had used a dist-tag for the experimental work!
There was a problem hiding this comment.
Note also that io-ts has deviated from semantic versioning above 2.1.3
Not really, meaning that 2.1 and above introduce experimental features without breaking the old/stable API. The current stable API will eventually be dropped in favor of the experimental one in a breaking release (3 I assume)
There was a problem hiding this comment.
My team have been experiencing compatibility issues between packages using different versions of io-ts across the 2.1.3 boundary. Our solution was to standardize on ~2.1.3 until 3.0.0 is released.
I believe the problem comes from providing a codec with a version of io-ts from one side of the boundary, and using that codec in another codec defined by io-ts on the other side of the boundary. Not sure if this library is at risk then 🤔 need to look at the internals more closely
No description provided.