Change:
font-family: var(--font-family-sans); } <ins> .Source { padding: 0.25rem; border-top: 1px solid var(--color-border); } .SourceHeaderRow { display: flex; align-items: center; } .SourceHeader { flex: 1 1; font-family: var(--font-family-sans); } .SourceOneLiner { font-family: var(--font-family-monospace); font-size: var(--font-size-monospace-normal); white-space: nowrap; overflow: hidden; text-overflow: ellipsis; max-width: 100%; margin-left: 1rem; } </ins> .Component, .Owner { color: var(--color-component-name);

Discussion:
Do you want to request a feature or report a bug? Feature. What is the current behavior? The new DevTools doesn't show the component file path as did the v3 version. What is the expected behavior? It would be great to show the component file path, it's a really important feature when working in a large codebase. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React DevTools v4 is affected, v3 had it.
Please be more specific in your feedback. This is not helpful.
I agree with , in this new version (v4), we cannot get file locations which really slows development time, fix this asap.
You can get your component file path by clicking in the "Log this component data to the console", icon is like a bug, and then copy the path from the Console.
File info isn't shown in the top level UI anymore because there are a lot of important things fighting for space in that UI. You can still see it using the debug button though. ! Is this enough to satisfy your use case Seems like it should be?
I think doing 4 clicks for something so basic is way to much. Putting it at the bottom (or top) of the info panel doesn't seem like it would block anything, since it's quite empty and would be very helpful (at least a copy path button would be small) !
To counter this, I don't think people use this info / look for this info often- so I'm not sure it needs to be available at a glance. I think putting less accessed info behind a click or two isn't so unreasonable. I don't think 4 clicks is right. You have to click to select an element to begin with. Then it's: the bug console or type "Esc" to open the bottom console to expand the logged element (at which point the file info is already visible) Your screenshot looks like a pretty extreme edge case. Many people run this extension docked to the bottom 1/4th or so of their browser window, where there is much less height and adding it to the bottom would require scrolling.
Even 3 clicks is a lot. I know I used it multiple times a day, so does my co-workers.

Maybe adding an option to display it at the bottom would be a good compromise? Even off my default is fine, but the ones that use it would be able to turn it on. IMO, dev tools should help developers do their jobs better/faster, and an option would fulfill that purpose without impeeding others.
I agree with the old place that this piece of information where was way more accessible and easier to reach than now.
Please show the component file path by scrolling. It is very important for large projects. Doing it in 3 clicks is waste of time.
I agree with , in large projects this is such a waste of time, just put it in the old place as it was much much better.
I don't think further comments just saying "please add this" add much value. Copy-pasting Dan's response from another issue as I think it also applies here: We appreciate your feedback but s are enough to help prioritize tasks.
I had the chance to look into this a bit last night and this morning and here are my thoughts. I don't think this was intentional, but the screenshot in the comment above is pretty misleading: <img width="234" alt="Screen Shot 2019-12-10 at 8 20 04 AM" src="https://user-"Source paths are never this short. In practice, the string would always either need to be truncated- so it would not end up showing the file name or line number: <img width="337" alt="Screen Shot 2019-12-10 at 8 23 58 AM" src="https://user-"Or it would need to be the file name only, without the path: <img width="337" alt="Screen Shot 2019-12-10 at 8 22 19 AM" src="https://user-"Neither of which is actually that helpful if your goal is to copy a file path so that you can open it in an external editing tool. If we were to display the full string, and allow it to wrap, it would take up even more space.

<img width="337" alt="Screen Shot 2019-12-10 at 8 27 43 AM" src="https://user-"The only place I feel somewhat okay about putting the info is at the bottom, but I think this will often mean that in practice, it's not visible without scrolling (since most components have several props/state that would push it down): <img width="334" alt="Screen Shot 2019-12-10 at 8 33 32 AM" src="https://user-"I guess I could always make it a configurable option- but more options means more maintenance burden and I don't think this clears the bar for one. Maybe the best compromise would be to show the name only, at the bottom, and have a copy button for the full path with line number: <img width="335" alt="Screen Shot 2019-12-10 at 8 44 27 AM" src="https://user-"This would still require a bit of scrolling but... I don't think there's any way around that without harming the common case UX.
Thanks
This is already much better. Having a single option to make it copy the full path would be the best way though, since it's simple and all editors support opening by full path.
This is literally that. The partial path is shown but the copy button copies the full path. That's what I was trying to say with this:
Ah sorry I misunderstood! Thank you very much!
Still, we can get a file source by clicking the right-side source icon. <img width="1440" alt="Screenshot 2019-12-11 at 11 52 02 AM" src="https://user-"