How to deal with our aging vendor libraries?

[Fred Lin]

The question comes to my mind when I saw React released v15.5 recently.

In Devtools we have several vendor libraries in `client/shared` folder
(mainly react related libs), which is not modified frequently. But as we
know, web frontend libraries are evolving quickly.

Currently m-c & devtools-core use React 15.3.2(update at Sep. 2016), and
here are the major changes for React:

15.4 (November 16, 2016)
https://facebook.github.io/react/blog/2016/11/16/react-v15.4.0.html

Profiling Components with Chrome/Edge Timeline (with standard user timing
API https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API)

15.5.0 (April 7, 2017)
https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html

Some breaking change like React.PropTypes, React.createClass are moved to
the separate module.

It means after just half a year, we are aging by 2 minor(?) releases of
React, and we might miss more in the related libraries. The API
incompatibility might confuse potential contributors if we are too far from
the current react release version.
So, should we have a plan to deal with our aging vendor libraries?

For example:
* List and check vendor libraries changelog every two firefox releases (3
month) before the branch day.
* Make the decision if we need update them or not.
* Update the vendor libraries/m-c/devtools-html at nightly after branch day

How do you think?


--
Fred

[J. Ryan Stinnett]

I don't think we _have_ to be on the latest version, at least not just
because it's new. Constantly migrating to the newest thing might be extra
overhead we don't need to take on if there's no clear benefit to us. Newer
versions sometimes introduce unexpected performance regressions as well.

However, it's of course fine to check in occasionally and see what we're
missing from the latest versions. If we spot something in the change log
that seems like it'll help us, then let's put in the effort to upgrade.

- Ryan

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[Bryan Clark]

I like the idea of creating a cadence of reviewing the latest changes.
Every so often someone (or group of people) should be doing the work to
review bringing us up to speed with the latest stable vendor releases.

I'd say the people doing this work should be looking for significant
changes that could be improvements for us, and as Ryan said watching out
for regressions. I also think there is value, as Fred mentioned, to just
making sure we aren't too far behind. The more we lag behind the harder it
becomes to catch up later. A little bit of upgrade work every so often
can be better than larger refactors.

Just my thoughts,
~ B

[Patrick Brosset]

Thanks Fred,

No we don't have a plan or process to update our dependencies. But I agree
that we should update every once in a while to benefit from new features
and bug fixes we might need, and to avoid lagging too far behind.

I think the best way to get this started is filing a bug to update React,
describing what the benefits are (will the new version be faster? more
reliable? provide better features?). Then NI'ing various DevTools owners
for modules which use React today and get a quick Yes/No from them about
whether or not we should upgrade.
Then the question becomes: who does it and when rather than should we do it?

Patrick