I'm a CSE student, and reviewing pull requests always felt slower than it should be. My theory was simple: most of a pull request is noise. Renamed variables, reformatted lines, code moved from one place to another. If a tool could prove which lines don't change what the code does, reviewers could skip them.
So I built that tool. ReviewRaccoon is a free GitHub Action. It turns the old and new version of every changed JavaScript and TypeScript file into a syntax tree, strips out everything that can't change behavior (formatting, comments, local variable names), and compares the two trees piece by piece. There's no AI involved: a piece is only called safe when it is provably the same.
Before launching, I wanted a big number for the README. So I tested my theory.
The experiment
I ran ReviewRaccoon over the last 100 merged pull requests of 10 well-known projects: React, Next.js, VS Code, TypeScript, Vite, Svelte, Angular, Prettier, ESLint and Node.js. That came to 1,000 pull requests and 170,160 changed lines of JavaScript and TypeScript.
The result
Only 3% of the changed lines were refactor-only. The other 97% changed what the code does. No project came close to my guess: the range was 1% (VS Code and TypeScript) to 6% (Svelte).
Pure refactor pull requests were almost nonexistent. Of the 666 pull requests that touched JavaScript or TypeScript, 11 changed nothing, and the biggest of those was 11 lines of tidied comments and types in Svelte.
Why I was wrong
My best guess is that experienced teams don't mix refactors into feature work, so there's very little noise to remove. I had imagined a problem these projects don't have.
Two caveats, so you can judge the numbers yourself. The count is strict: if a function changed, every changed line inside it counts as a change, even a rename on the next line, so the true share is somewhat higher. And the scanner skipped 8 giant pull requests with more than 100 code files, which is where mass renames would most likely be.
What I changed
I kept the tool and changed the pitch to match the data. On every pull request, ReviewRaccoon now leads with two things:
- Which functions behave differently, with links to their exact lines.
- Proof when a change is refactor-only, so a rename or a reformat can be approved in seconds.
Try it, or check my numbers
Installing it takes one workflow file, and the README has it. The scanner is in the repo too, so you can rerun my numbers or measure your own repo:
git clone https://github.com/TheRealJahaan/reviewraccoon cd reviewraccoon npm install GITHUB_TOKEN=$(gh auth token) node scripts/scan.js your-name/your-repo --prs 100 I only measured big, well-run projects. If you run it on your team's repo, reply with your number. I'd really like to know if it looks different.
