fp-ts@2 support added

[mlegenhausen]

I added the minimum changeset to get the library working with fp-ts@2. I was not able to make it backwards compatible cause of the removal of Monodial, the changes in the Foldable and Alternative instances.

Would be great if you could take a first look and give me feedback.

I add a fp-ts-v2-lib branch so you can try it out directly

yarn add https://github.com/werk85/remote-data-ts.git#fp-ts-v2-lib

[raveclassic]

@YBogomolov Could you help with reviewing the transformer module please?

[YBogomolov]

Looks good to me. I like how the code style is streamlined with fp-ts@2 style 👍🏻

[raveclassic]

@mlegenhausen Thanks for you work! However we can't merge this to master because of direct repo reference in package.json. In spite of that we can release an .rc version from this branch if you need it.

/cc @sutarmin

[raveclassic]

#33

[YBogomolov]

Looks good to me. I like how the code style is streamlined with fp-ts@2 style 👍🏻

[mlegenhausen]

Before we merge I would like to add the pipeable operators and deprecate the class operators? This would allow us in a next step to go classless without the further introduction of breaking changes.

[mlegenhausen]

I reworked the code to add pipeable operators and changed the test accordantly. I also added the getOrElse, fold, toUndefined and toNullable operators. Because adding operators introduce no breaking changes I only added the one that are most useful for my use cases.

[raveclassic]

@mlegenhausen Thanks for you work!

@sutarmin I'd like to discuss if we're ready to go classless. Migration to [email protected] is already a breaking change, is there any reason we'd want to split migration steps?

[sutarmin]

I don't see any reasons for separating fp-ts@2 support and classless approach for rd itself. I think even quite the opposite, it would make much more sense for rd consumers to migrate both fp-ts and rd at ones, so in my opinion, we need to provide fp-ts@2-way API as fast as possible.

But regarding this PR, we can either rewrite to classless approach here or merge this one (once io-ts-types has a version with fp-ts@2 support) and continue working it separate PR. Again, to provide users new API faster, I would go with former.

[raveclassic]

So, summing up, we're still waiting for io-ts-types release. In the meantime we could drop classes

[YBogomolov]

@raveclassic, just FYI – [email protected] was released with support for fp-ts@2: https://github.com/gcanti/io-ts-types/releases/tag/0.5.0

[sutarmin]

Nice! Now I think we could update this PR, merge it and then work on making RD classless is separate PR, to be more granular.
What do you guys think?

/cc @raveclassic @mlegenhausen

[raveclassic]

Agree on moving classless to separate PR

[mlegenhausen]

I updated the pull request.

Would be ok from my side. Could we then already start with a next version package release for npm?