Improve React Devtools release process

[jasonLaster]

Note: We are currently discussing strategies for running the backend in the client which would remove this problem entirely.

There are a couple of challenges today when it comes to bumping the react devtools backend:

1. Building the browser
2. Building react devtools
3. Patching react devtools backend and updating the gecko-dev files
4. Testing the new version of the browser
5. Deploying the browser

It would be nice if we could modify the react devtools backend without having to touch the browser. If that were possible, then you could

1. Build a new version of the react devtools backend
2. Point the Replay browser to the backend
3. Record a new replay and see if it works
4. Deploy a new version of the backend

In practice, the way I think this could work would be if we treated the react-devtools backend similar to the driver where the browser would be responsible for checking for changes and downloading the latest version. There would be some mechanisms here, but it's possible it could just a script hosted at app.replay.io and use a query param for cache busting.

[gideonred]

the browser would be responsible for checking for changes and downloading the latest version.

Last I heard the browser doesn't do this anymore and packages the driver in.

[bhackett1024]

The browser used to have a way to auto-update the recording driver, but that caused a lot of problems. The fundamental issue is that when you add a new update channel like this, you're essentially adding another dimension to the space of possible configurations in which the browser can run. Changing the driver can break old browsers, and it's extremely difficult to test all the possible combinations of browsers and drivers.

I don't think adding a separate update channel for the react devtools backend would be as problematic, but it still increases the space of possible configurations in a way which we can't test. More than that, this proposal lacks details about how this new update channel would work. When a recording process starts, we need to immediately load the devtools backend into the process so that any react on the page will detect it. We can't do a network fetch at this point because it would slow down the page load, and having the browser download the devtools with a separate mechanism and store it somewhere adds quite a lot of complexity and unpredictability (how do you know you're using the latest version of the backend?) --- this is what we did for the driver update and it was really hard to manage well.

Given the above problems I feel that we should continue packaging the devtools backend inside the browser, until we're able to run it client side (https://github.com/RecordReplay/devtools/issues/6126). The existing process could be streamlined by adding a script which updates the backend, then you can create a PR to update the browser and put it through the regular deployment and testing processes as for other browser changes (which we really don't want to sidestep, either).

[jasonLaster]

re driver updates: Didn't realize we dropped that release channel, although the rationale makes a lot of sense.

re backend update channel: Agreed that the devil is in the details. This is an improvement if the process is easy to streamline and browser building/testing/releasing continues to be a bottleneck. We'll be improving this flow too which would also remove the need for a separate channel too.

[gideonred]

I'd like to see @whtf0x's tackling this problem eventually and get us to be able to build the browser easily and quickly. (cc @jazzdan )