increment to react-redux v7, redux-form v8, redux v4

It looks like redux-observable@0.18.0 should be compatible with both redux 3 and 4

That's not what I see. 0.18.0 corresponds to these lines and 0.19.0 is the same.

I'm surprised to see v0.15.0 since it looks like we have ^0.15.0 everywhere.

In semver, a caret fixes the first non-zero value reading left to right. So, both ^15.14.13 and ^0.15.14 fix the 15. Another way to think of it is that ^ acts like ~ when the major version is 0. Another way to think of it is that this confuses basically everybody who expects ^ not to be special when just because the first value is 0 and even though there is a consistency to the way they worked it out, if it were possible to reach through the internet and punch people in the face I would totally do that to the person who wrote this.

All that said: I'm fine keeping things as-is given we have seen no ill-effects. I just wanted us to be aware of the decision we were making.

I agree with everything Mark said.

It looks like redux-observable@0.18.0 should be compatible with both redux 3 and 4 I wonder if we can try to set it 0.18.0 explicitly to see if this problem goes away. I'm surprised to see v0.15.0 since it looks like we have ^0.15.0 everywhere.

I'm also fine with going forward with the upgrade. The one place I worry about a bit is eholdings. I don't know the codebase well enough so we would need to reach out to the people responsible for it to see if they can review it / test it a bit more.

I personally wouldn't worry about the redux peer dependency. Redux 4 was an under-the-covers release and despite the issues we had with another this-won't-break-things! major release, our history upgrading Redux leads me to believe that it should be fine.

The explicitness of the requested versions gave me pause, so I looked up the authoring PR in case there was anything about specific Redux 4 behaviour, but it looks like it was switched so that it also worked with pre-release versions of Redux/RxJS.

RxJS on the other hand did change its API in v6. So AFAI see, we have the option of 1) staying with our current plan and assuming redux-observable will work for redux4, or 2) upgrading RxJS and moving to redux-observable v1?

Again, I don't foresee any issues with our first plan. But we're gonna have to do #2 anyway so if somebody has time, sure, let's do it in Iris. :shrug: But I defer to Michal on that.

@md331, @Michal Kuklis I noticed these upgrades put our redux-observable dep in a conflicted state WRT rxjs, which upgrade we opted to handle separately (https://folio-org.atlassian.net/browse/STRIPES-723#icft=STRIPES-723). At present, we get the following build warning:

redux-observable < v1.0.0 has the following peer-deps:

and >= v1.0.0 has the

The new Iris schedule gives us until 2021-02-05 for the API freeze, and until ~2021-02-19 (a week prior to the app feature freeze deadline) to actually publish the release. How do you think we should handle this? On the one hand, I haven't noticed any ill effects, on the other, I don't know exactly what kind of side effects I would look for.

I added a resolutions entry for redux-form at the platform level so we don't have to deal with a bajillion app-specific errors while waiting for apps to update their deps. Really, it should be a peer at the app level, but since we're aiming to complete the replacement of redux-form with final-form in the near future anyway, the resolutions entry seemed like the most pragmatic fix.