Make a map before reading every line
A large pull request becomes difficult when you lose track of how its files connect. Reading from the first file to the last can leave you remembering individual edits while forgetting the behavior they are supposed to change.
Start with a short inventory: the purpose of the PR, the distinct changes it contains, and the evidence each one needs. Then choose a review order based on consequences. A small access-control edit can deserve more attention than a long lockfile update.
We tried this with Vite PR #23658 in Diff it, a merged backport containing 18 changed files, 209 additions, and 29 deletions at commit 9dc3dd6. Eighteen files is a manageable example of a PR with several threads to follow; the same method helps when your file list is much longer.
Group files by the behavior they support
The four commits in this PR backport HTML handling fixes, an editor dependency update, a WebAssembly query access check, and safe module path handling. From the diff, we made this review map:
- File-access boundaries: transform middleware, import analysis, and the filesystem playground tests and fixtures.
- HTML URL handling: filename resolution, inline module proxy generation, and HTML regression tests.
- Dependency changes: the package manifest, lockfile, and workspace installation policy.
A fixture and the implementation it exercises belong in the same review thread, even if their paths are far apart. For example, the new playground plugin, HTML status display, and server test all support the safe-path regression. Reviewing them together explains why they exist.
Keep the original file inventory nearby. A useful grouping gives you a route through the PR; it still needs to account for files that do not fit neatly into your first pass.
Use Diff it to find a starting point
We opened this PR in Diff it and inspected its completed analysis on October 10, 2026. It identified four capabilities, including access checks for ?vite-wasm-instance, HTML URL normalization, safe module path recording, and the playground’s access-isolation status display. Those capabilities are not a one-to-one checklist of the four backported commits.
The first capability gave us a concrete question: does a module request with that WebAssembly query go through the loading-access check? Expanding its scenario showed pinned before-and-after source and a related test excerpt.
The same analysis reported 16 unresolved changed hunks and 27 limitations, including bounded source excerpts and incomplete related-file discovery. The selected capability’s two suggested checks were unverified. Those numbers describe this saved run; another analysis may differ. They are a reason to keep reviewing the source, not a measure of how much of the PR is safe.
Inspect this PR in Diff it with GitHub sign-in, or explore the public demo without an account.
Follow the paths with the biggest consequences
We started with file access. In the pinned transform implementation, the new query matcher enters the existing branch that checks both the cleaned URL and the original identifier. A review should ask which inputs reach that branch, what denial means to its callers, and whether an allowed request still works.
Next, import analysis adds a cleaned, resolved module identifier to safeModulePaths only when resolution produced one. Previously it recorded a filesystem path derived from the URL. The new SSR test asserts that an unresolved import is not added to the safe set. Check how a value enters a trusted set as carefully as how that set is later consulted.
For HTML, the implementation cleans the URL before resolving the filename and collapses multiple leading slashes in the HTML path used for generated URLs. The HTML regression test checks the generated proxy URL and module-graph entries for a protocol-relative request. Read those assertions alongside the implementation rather than treating “tests added” as a verdict.
Separate test source from test execution
The filesystem test matrix adds WebAssembly query cases expecting a restricted response. A separate safe-path test expects 403 on non-Windows systems and 404 on Windows for its particular request. That platform distinction is part of the expected behavior, not an interchangeable error code.
These are statements about assertions we read. We did not run Vite’s tests. Diff it’s suggested checks did not establish runtime verification either. To finish a real review, inspect the relevant CI jobs at the reviewed commit and reproduce the important paths in the appropriate environment when needed.
Keep the dependency thread open separately. The manifest updates launch-editor-middleware to a range starting at 2.14.2; the lockfile and installation-policy edits also deserve review. Reading the version change does not establish the dependency’s runtime behavior. We did not audit that dependency here.
Leave a record of what is covered and what is open
Before deciding on a large PR, write a short coverage record. For this walkthrough, ours would read:
- Source inspected: the query access branch, safe-set insertion, HTML URL handling, and their cited regression assertions.
- Execution evidence: no upstream tests run by us; suggested checks in the inspected capability remain unverified.
- Still open: complete caller and platform coverage, dependency behavior, and the analysis’s unresolved hunks.
For your own PR, attach each remaining question to a file, behavior, or test someone can inspect. If the change is too broad to explain or validate confidently, ask for a split or a second reviewer with the relevant expertise. A good stopping point is a review decision with explicit evidence and open questions.
For a smaller worked example, read what a gRPC PR actually changes. For the next verification step, see how to verify behavior when CI is green.