It would be nice to find a workflow where commits are played against a repository from its beginning. It's kind of archaeological, but may also benefit contexts like a Spring Boot upgrade from 2.x to 3.x, or moving from JDK 8 to 17, or even a Node.js project from 10 to 18 (or higher).
The key point is where the project doesn't work, you don't have to deal with extra files. The breakage is in exactly the files in that early commit, not dozens of others.
One killer feature is when the same file is encountered in a subsequent commit, the same transforms are also applied--so you don't have to fix the file again (or maybe have the ability to apply the same transform to similar files).
This speaks to the need for transforms and rules. (Rules can be embedded in the transforms, like a guarded regular expression.)
Benefits are installing the latest packages one-by-one helps catch deprecations and whether an incoming package behaves well with the newest framework version.
Not sure if there are such git-oriented maintenance workflows. Combined with an evergreen app template, upgrade complexity may be reduced.
Now, there are certainly ways to reduce dependency on a (specific version of a) framework or even a technology (react-test-renderer versus enzyme versus react-testing-library). Some examples--not all of which are possible--include
* An app consists of the framework and consuming the "app." Then the quoted version is actually the pieces that solve the domain, and the "delivery mechanism" or "execution context" is an HTTP frontend framework. And that is the app deployed.
* Wrap the vendor dependency without re-exporting everything. I'll only believe this if it can be done with Cypress, for example. Usually, one must use `cy.' for everything.
* Force a dependency to use your own version of its dependency, if possible. One use case is the dependency is archived, so using the overrides section of package.json to specify a path to "./lib/our-bundled-fork." (The easier in this case would be to fork the actual dep and consume it.)
The last point comes to a Github Action that installs packages one by one and sees if the tests still pass. It could run weekly on latest Node.js and latest React.
I wonder if there exists a solver that can reduce a history to the smaller working version of the code, like a "minimal reproducible example creator" of sorts.
