
Did your deps make upgrading to React 16.x hard too? - sammorrowdrums
I am struggling not to spout cliches about how the JS community make breaking changes constantly.<p>Up to now I was one of the proponents of how great the ecosystem is (these days). I have been deeply frustrated by the number of libraries that made major breaking changes across different React versions, without a straightforward upgrade path, so instead of being able to incrementally upgrade I&#x27;ve been forced to bulk upgrade and fire-fight and read all the documentation in one mega upgrade...<p>React itself has a really good deprecation &#x2F; upgrade version support, but I inherited a codebase using react-router (complete paradigm shift across versions), redux, redux-saga and a bunch of other deps with code splitting and webpack too, and this has been painful unlike any other upgrade I&#x27;ve had to do too.<p>The hot reloading library was deprecated, there were changes in the history api, the router is no longer parsing query strings and also changing the signature of the properties routes create have changed... I could go on and on, there was even a breaking API change to react-select!<p>My point is not that breaking changes are a problem on their own, it&#x27;s that I was left with the version change dilemma where breaking changes across 10s of deps were made without a straightforward deprecation &#x2F; migration path in a single version of React and I ended up with little choice but to upgrade everything and work through all the issues, until the thing built correctly again...<p>Anyone else have a similar experience?
======
acemarke
As you've pointed out, none of that is really about React itself.

React-Router did completely change its API between version 3 and version 4,
but my understanding is that version 3 is still maintained. So, you likely
didn't _need_ to upgrade to v4.

React-Hot-Loader has always been something of an "experimental" tool. There's
entirely too many edge cases around detecting components and trying to
maintain state of component instances when hot reloading. The React team has
suggested they have some ideas for ways to make hot reloading a better
experience down the road. (Personally, I prefer to keep most of my state in
Redux and use "plain HMR" [0], but I'm biased.)

It sounds like most of the issue here was really with React-Router. Were there
other specific issues you ran into?

[0] [https://blog.isquaredsoftware.com/2017/08/blogged-answers-
we...](https://blog.isquaredsoftware.com/2017/08/blogged-answers-webpack-hmr-
vs-rhl/)

~~~
sammorrowdrums
You are correct, this was voluntary. It was the difficulty level of the
upgrade that was frustrating.

We also love the NPM known vulnerability scanner, and we managed to get down
to zero known vulns in our deps, we like the direction of React, and Bootstrap
and some other things. We want to be a good citizen and use recent versions of
software, partly to play our part and decrease the maintenance burden for old
versions of things, but also when we feel that holding back the tide will not
help us.

Webpack has also got a lot nicer, the defaults are getting better. Its
opinionated starting point philosophy is good, and did let us simplify a lot
of config, and speed up builds etc.

I'm willing to accept that I'm grumbling, and perhaps the trade-off of better
software but more serious breaking changes is worthwhile, but I think it could
have been avoided if there was more of a focus on trying to bridge versions of
React. It would be nice to be able to upgrade React and focus primarily on how
that might affect my own code, than having to chase down all the deps that
don't straddle versions.

