🆙 📅 Any other feeback?

Just a side-conversation on work on the Razor compiler: does anyone have any good suggestions for how we can make the code review workflow reasonable when "update baselines" generates 1000+ changes? The specific problems I encountered were:

• Couldn't use GitHub's "Files" tab to view any changes in the browser, as the sheer amount of changes caused the web browser to hang. Instead I had to use the GitHub VS Code extension to review this.
• Due to limitations in GitHub VS Code extension, couldn't Ctrl+F find any review comments. There were a couple of conversations going on in here that I wanted to read, but didn't manage to find them manually among the large slew of conversations that are marked as "resolved".

I know we plan to do a lot more Razor Compiler work soon, so would be great to come up with any system to improve this. For example:

• We could choose not to push any commits to GitHub that update the baselines until review is done. However I know that's inconvenient for the person doing the PR, plus sometimes in code review you actually want to see some baseline changes
• We could choose not to mark any conversations as "resolved" until it's all completely signed off, or possibly not resolve them at all, so it remains possible to ctrl+F search through them.

Any other ideas @javiercn? How did you review this, @pranavkm?

@SteveSandersonMS this is a particularly challenging one because we were changing the code generation part in a very cross-cutting way. I don't expect most changes to be this impactful and to be more localized in general.

In general, when I had to deal with reviews like this, as an author you probably saw that I updated code and baselines in separate commits as to make it easier to see on each individual commit; in the same vein, as a reviewer, if the PR has these sort of changes and makes it hard to review on GH, I pull it down and perform a git diff -- <<path>> to review things and narrow down the changes.

When I started working on this I was planning on breaking down the PR using a "case by case" approach, but that caused a lot of extra work as its easy to make multiple changes or discover that you need to make changes because they don't play well with other required changes (they are not independent).

In general, even if you need to go through lots of files, changes in these files are very similar.

There's obviously room for improvement here, but in general it's hard to do this other than breaking it up in individual commits/updates (some of which will still update hundreds of baseline files)

In my own testing, what I did was craft a regex and use VS Code search to find places where I missed using global:: until I got all the places we care about.

Its also hard to predict that we didn't break anything, other than by the fact that we have a myriad of tests and that they all check that the code compiles successfully. Which means that if we mess something up, its not common nor critical (hopefully), but we can never be sure.

I would like to see if we can find ways to leverage more "real world" apps to test changes in the compiler, but that'll require some thinking through.