React Surgeon: click a broken element, it maps it to the JSX and repairs it, but only calls it fixed if a browser replay passes
I have been building this for a while and it is finally on npm, so I would rather put it in front of people who will tell me what is wrong with it.
How it works. A development-only Vite plugin stamps source coordinates onto intrinsic JSX during serve. You click the broken element in your browser and it reports the file and line that rendered it. Babel then assembles a narrow slice of context from the clicked component, its imports and related components, and a small local model proposes an exact substring replacement. Not a file rewrite. It has to match a unique existing substring or the patch is rejected.
The part I actually care about is that the model's opinion does not count. After every edit it runs your typecheck, lint, tests and production build, then replays your acceptance scenario in a real Chromium instance. Only if all of that passes does it report VERIFIED. Otherwise it reports BLOCKED, leaves the diff in your working tree so you can read it, and tells you the undo command.
That distinction earned its keep while I was testing. One patch passed typecheck, lint, tests and the production build and was still completely wrong. It set state back to the previous array reference, React bailed out on Object.is, and nothing re-rendered. Four green checks on a broken fix. Only the browser replay caught it.
It also refuses to run if your acceptance scenario already passes against the unmodified app, so it cannot invent a reproduction to look useful.
Everything is local. Qwen 2.5 Coder 1.5B on CPU through node-llama-cpp, which npm installs as a prebuilt binary, so nothing needs to be on your PATH. If you already run Ollama or LM Studio you can point it there instead. No API keys, no telemetry, nothing leaves the machine.
npm install -g @react-surgeon/cli cd your-react-app npm install -D @react-surgeon/vite-plugin react-surgeon init Honest limitations, because I would rather say them than have you discover them:
- The 1.5B model solves roughly half the bugs it attempts on my three-bug demo app and refuses the rest instead of guessing. Read every diff.
- Analysis resolves ordinary relative imports. Path aliases, higher order components, re-exports and provider chains are where it will get the context wrong, and that is the next thing I am working on.
- You write the acceptance scenario. There is a command that drafts one from a recorded interaction and tells you which values changed, but you still decide what correct means.
Repo, docs, and a demo app with three reproducible bugs: https://github.com/waleedmustafa971/React-surgeon
MIT licensed.
I am genuinely after criticism on the approach, particularly whether the verification gate is strict enough or whether I am fooling myself with it.
[link] [comments]