Source-mapped feedback: from a clicked element to file:line
Why "which file renders this?" is the slowest part of acting on visual feedback, and how the Feedback DevTools SDK answers it at the moment the reviewer clicks.
Why the file matters more than the screenshot
A screenshot tells a developer what is wrong. It does not say where to fix it. On a large React app the same button style can come from a shared component, a page override or a third-party library, and finding the right file is often slower than the fix itself. For a coding agent the problem is worse: an agent given only a screenshot and a selector has to search the repository and guess. A report that already says src/components/PricingCard.tsx:42 removes that search, which is why source mapping is the centre of Feedback DevTools rather than an add-on.
How the mapping works
At build time, the SDK's Babel plugin adds a small property to each JSX element with the file name, line and column where it was written. The Next.js plugin wires this in for webpack builds; with Turbopack, Vite and Create React App, the SDK reads the source information React's own development transform already adds. At click time, the runtime walks from the DOM node to its React fiber and reads the location in order of reliability: the plugin's property first, then React's debug source data. The nearest named component is recorded with it.
Source data is a development feature by default, so the SDK is on in development and preview builds and off in production unless you set ENABLE_FEEDBACK_SDK=true, which adds a little to the bundle. Most teams run review rounds on a staging or preview deploy, which is where the mapping is switched on. Install it with the npm alias, npm install @feedback/sdk@npm:feedback-devtools-sdk, and wrap your Next.js config with withFeedbackSDK.
What a report contains with and without the SDK
Every report from the widget, with or without the SDK, includes the element's CSS selector, tag and visible text, a screenshot, recent console errors and warnings, recent network requests with failures first, the page URL, viewport and browser, and a DOM replay of the last couple of minutes with input values masked. That is enough to reproduce most visual bugs on any framework, because the widget is a plain script tag.
With the React SDK, the same report adds the component name and the source file:line:column. That is the field a coding agent needs to start editing straight away, and it is what the generated Claude Code prompt and the MCP context lead with. Sites built with Vue, Svelte or Angular get the full report without the component and file fields, since the source mapping reads React's component tree.
Frequently asked questions
What is source-mapped feedback?
A visual feedback report that names the code behind the clicked element: the React component and the source file, line and column. Feedback DevTools adds it with its React SDK.
Which frameworks support file:line mapping?
React apps: Next.js with webpack or Turbopack, Create React App, Vite, and other React setups that use @babel/preset-react. Other frameworks get screenshots, console and network context, but not the component and file fields.
Does source mapping work in production?
It is on in development and preview builds by default. To enable it in a production build, set ENABLE_FEEDBACK_SDK=true; this adds a small amount to the bundle.
Do I need the SDK to collect feedback?
No. The widget alone captures the selector, screenshot, console errors, network requests and a short replay. The SDK adds the component name and source file:line.
Keep reading
Try it on your own site
Feedback DevTools is free to start: unlimited feedback, shareable review links and no client accounts.