-
Notifications
You must be signed in to change notification settings - Fork 50.2k
[DevTools] Add Option to Open Local Files directly in External Editor #33983
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This lets us update when any other hooks makes changes in the same window.
This is unnecessary. It's implied by the source field being not null.
This is basically a super set of ReactFunctionLocation but this will be important to support stack traces.
eps1lon
approved these changes
Jul 25, 2025
sebmarkbage
added a commit
that referenced
this pull request
Jul 25, 2025
…l editor (#33985) Stacked on #33983. Allow React to be configured as the default handler of all links in Chrome DevTools. To do this you need to configure the Chrome DevTools setting for "Link Handling:" to be set to "React Developer Tools". By default this doesn't do anything but if you then check the box added in #33983 it starts open local files directly in the external editor. This needs docs to show how to enable that option. (As far as I can tell this broke in Chrome Canary 🙄 but hopefully fixed before stable.)
sebmarkbage
added a commit
that referenced
this pull request
Jul 25, 2025
…r presets (and make VSCode default) (#33995) Stacked on #33983. Previously, the source of truth is the url stored in local storage but that means if we change the presets then they don't take effect (e.g. #33994). This PR uses the hardcoded value instead when a preset is selected. This also has the benefit that if you switch between custom and vs code in the selector, then the custom url is preserved instead of getting reset when you checkout other options. Currently the default is custom with empty string, which means that there's no code editor configured at all by default. It doesn't make a lot of sense that we have it not working by default when so many people use VS Code. So this also makes VS Code the default if there's no EDITOR_URL env specified.
Collaborator
|
I know it's been a while but could this in any way have led to the regression where clicking links in console logs doesn't do anything? https://issues.chromium.org/issues/462747680 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
useOpenResourcehook is now used to open links. Currently, the<>icon for the component stacks and the link in the bottom of the components stack. But it'll also be used for many new links like stacks. If this new option is configured, and this is a local file then this is opened directly in the external editor. Otherwise it fallbacks to open in the Sources tab or whatever the standalone or inline is configured to use.I prominently surface this option in the Source pane to make it discoverable.
When this is configured, the "Open in Editor" is hidden since that's just the default. I plan on deprecating this button to avoid having the two buttons going forward.
Notably there's one exception where this doesn't work. When you click an Action or Event listener it takes you to the Sources tab and you have to open in editor from there. That's because we use the
inspect()mechanism instead of extracting the source location. That's because we can't do the "throw trick" since these can have side-effects. The Chrome debugger protocol would solve this but it pops up an annoying dialog. We could maybe only attach the debugger only for that case. Especially if the dialog disappears before you focus on the browser again.