react-dev-inspector opens the source file behind a component

The missing link between the browser and the file

The problem react-dev-inspector addresses is small and familiar. You are looking at a page in the browser, you want to change something in it, and you cannot remember where the component is defined. The readme names three versions of that moment: fixing a bug in someone else's project without knowing where the page's code lives, diving into an open source project and struggling to find the implementation of a screen, and thinking of a component you want to peek at without wanting to walk through never-ending deep file paths.

The answer is a click. You click the element in the browser and your local IDE opens the source file, which the project describes as a more advanced version of the Chrome inspector. The mechanism that makes it possible is that a modern React build already knows the file each component came from, the source path information a compiler plugin records. The inspector's job is to capture that information at the moment you inspect an element and hand it to something that can open a file.

The package is on npm as react-dev-inspector and is MIT licensed. The project has its own documentation site with a showcase and a StackBlitz demo that you can open in the browser to see the behaviour without setting anything up locally, which is the fastest way to judge whether the workflow fits you.

The repository is a monorepo named @react-dev-inspector/monorepo, marked private, built with pnpm and pnpm 9, with a packages directory for the publishable pieces, an examples directory for framework integrations, a docs directory for the site, and a scripts directory with a site build script. The tooling includes husky for git hooks, eslint for linting, and commitlint configuration, so the repository follows a conventional commit workflow.

The pipeline has three parts, and the first is optional

The readme documents how it works as a numbered pipeline, and the structure of that pipeline explains the whole design.

Part 0 is injecting the JSX source. A compiler plugin records the source path information into React components during the development stage. The readme marks this part as generally optional, and explains why: most React frameworks offer the feature out of the box, which means you usually do not need to configure it additionally. The numbering is doing real work here, because the zero in Part 0 implies the step you can usually skip.

Part 1 is the Inspector component. The package provides an <Inspector/> component that reads the source information and sends it to the dev server when you inspect elements in the browser. This is the part that adds to your page, one element in your tree.

Part 2 is the dev server middleware. The package provides middlewares for the dev server in most frameworks, and their job is to receive the source path information from the API and then call your local IDE or editor to open the source file.

The separation is the interesting part. Step 0 happens at build time and is a property of the framework, step 1 happens in the browser and belongs to your application code, and step 2 happens on the machine running the dev server and belongs to your tooling. The middle step is the only one you have to write into your own components, and the last step is a piece of configuration per framework.

Because the handshake runs through the dev server, this is a development-time tool by construction. Nothing in the design suggests it belongs in a production build, and the readme frames it as a development stage feature.

Two things to configure, per framework

The readme is direct about the setup: the Part 1 and Part 2 are what you need to configure to use. That is, add the <Inspector/> component in your page, and integrate the middleware in your framework's dev server. Both steps link to separate documentation pages, and the documentation site holds the details for each framework.

The examples directory in the repository shows the range of setups that are expected to work. There are example projects for Create React App 5 with rewired, Next.js with a custom server, Rspack, Umi 3, Umi 4, and Vite 2, Vite 3 and Vite 4. That list is the best available answer to whether your stack is covered, and it also tells you something about the shape of the integration. The Vite and Umi examples are the mainstream cases, the Create React App example covers a rewired setup, and the Next.js example uses a custom server, which is the point at which a dev server middleware becomes possible at all in that framework.

Building the packages and the examples in the monorepo is two commands, one for each group:

pnpm --filter './packages/*' build
pnpm --filter './examples/*' build

The root scripts also include a site build that runs a shell script in the scripts directory, and a purge script that cleans the node_modules directories, which is what you want after switching between the examples.

The documentation site is the authoritative source for the per-framework steps, and the readme's contribution to it is the pipeline description, since the exact middleware wiring changes with each framework's dev server API.

Where the browser's own tooling fits better

The alternative is the tooling already in your browser, and the difference in approach is the direction of the jump.

The browser's developer tools already show the rendered page. From there the usual path is to search the source tree by name or by the text you saw on screen, which works when you know what the component is called and when the naming in the code matches what you see in the tree. The inspector package removes both conditions. You click the element, and the file opens, without knowing the name and without reading a path.

There is a second alternative in the other direction. Most editors and IDEs have a jump to definition command, and the React language services understand JSX, so from a usage site you can jump to the declaration. That path is faster when you are already in the code and know what you are looking for, and it needs no browser at all.

So the tool earns its place in a specific moment: you are in the browser, looking at a rendered result, and you need the implementation of the thing in front of you. In that situation the alternatives ask you to remember a name and search, which is exactly the friction the project set out to remove.

The cost is the same in every case where a dev server is told to open a file on your machine. The middleware calls a local editor, which means the dev server can trigger an action on the host, and a dev server that is reachable from a network is a different proposition from one that is not. The package is a development dependency for a reason, and treating it that way is the whole of the security story.

The parts that are still thin

Two gaps are visible in what the documentation covers.

The first is the browser support story. The readme does not describe which browsers the inspector works in, nor what happens when the framework in use does not record the JSX source information. That is the Part 0 dependency, and while most frameworks now provide it, a framework that does not means the inspector has nothing to read, and the failure would present as a click that does nothing rather than an error message. The readme's answer to this is the compiler plugin, which is documented separately.

The second is the IDE side. Part 2 calls your local IDE or editor, and the readme does not enumerate which editors are supported or how the editor is chosen, that is documented on the integration page rather than in the overview. In practice this is the part you will spend time on, because the middleware has to know how to ask your editor to open a path on your machine, and every editor and every operating system has its own way of being asked.

There is a smaller documentation gap too. The readme links the per-framework steps to the documentation site rather than describing them, so a reader without the site open cannot see what a middleware call actually does on their machine.

None of these are defects in the design. They are the edges of a project whose documentation lives on a separate site, and the practical advice is to treat the site as part of the package rather than as an extra.

Versions, branches and where the project stands

The project publishes to npm rather than tagging releases on GitHub, and the repository has no GitHub releases at all. The npm version is shown through a badge in the readme, and the default branch is dev, which is where the examples, the packages and the documentation site are worked on. The last push to the repository was on 2026-04-20, so any statement about how recently the code changed has to be anchored to that date rather than to the npm version.

The licence is MIT, with the text in the LICENSE file at the root of the repository, and the readme closes with a thank you to three contributors by handle. For a tool that runs only in development and is not shipped to end users, the licence is rarely the deciding factor, but for a team that wants to vendor the middleware into an internal starter template it is a permissive one.

The repository structure says something about how the project is meant to grow. The packages directory holds the publishable pieces, the examples directory holds one integration per framework, and the pnpm workspace ties them together so that an example can depend on the local build of a package rather than on the published one. That arrangement is what makes adding a framework support a pull request rather than a release, and it is also why the examples are the best documentation of the integration steps for each framework, even where the site is more convenient to read.

Editorial conclusion

react-dev-inspector fits a front end developer who keeps losing track of which file a component came from, works in a Vite, Umi, Next.js or Create React App setup, and is willing to add one component and one middleware to the dev server. It does not fit a production build, a shared environment, or a workflow that cannot tolerate a dev server making requests to the local machine. Verify first that your framework has an integration example in the repository, that the source path information your framework records is the kind the Inspector can read, and that the IDE the middleware calls is configured on the machine where the dev server runs.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zthxxx/react-dev-inspector on GitHub