Did your deps make upgrading to React 16.x hard too? | Hacker News Reader

Did your deps make upgrading to React 16.x hard too?

1 pointsammorrowdrums3 comments

I am struggling not to spout cliches about how the JS community make breaking changes constantly.

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've been forced to bulk upgrade and fire-fight and read all the documentation in one mega upgrade...

React itself has a really good deprecation / 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've had to do too.

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!

My point is not that breaking changes are a problem on their own, it's that I was left with the version change dilemma where breaking changes across 10s of deps were made without a straightforward deprecation / 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...

Anyone else have a similar experience?

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...

There were some other upgrades, for example we used some React Bootstrap components, and then upgraded to new Bootstrap as we wanted the flexibility of the new version, but they weren't going to support it, and Reactstrap only came into existence from React 16 so we had to roll out our own components to do that upgrade within React 15 - otherwise upgrading bootstrap would have pushed us to next version of React. That was a choice though.

There were just more major API changes in a lot of the libraries we use than I've had to deal with previously on major upgrades. Maybe it's just the project has more dependencies.

I had another issue where one upgraded webpack dep wanted new babel, but then that broke another one, so I also had to help with that before I could complete the upgrade.

It's not just about the individual incidents though, it's more that upgrading one thing often required the upgrade of another, and after following that path, it became clear that much of it had to be done at once.

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.

Reply on news.ycombinator.com