Skip to content

[RFC] feat: Add react-native debug type for attaching to React Native apps#2384

Draft
huntie wants to merge 1 commit into
microsoft:mainfrom
huntie:attach-react-native-process
Draft

[RFC] feat: Add react-native debug type for attaching to React Native apps#2384
huntie wants to merge 1 commit into
microsoft:mainfrom
huntie:attach-react-native-process

Conversation

@huntie

@huntie huntie commented Jul 3, 2026

Copy link
Copy Markdown

Note

Early RFC PR: We're ironing out the last blockers for full VS Code CDP client compatibility in Hermes — this diff is an up-front RFC/preview of how we could bring 1P React Native support to VS Code users.

Motivation

React Native apps expose their debugger through the Metro dev server's inspector proxy, not as a local Node process, so the existing "Attach to Node Process" flow can neither discover nor attach to them.

This diff

Adds a first class "react-native" debugger configuration type (attach request). This mode changes two key behaviours:

  • Multi-target selection UX: Presents a visual picker for users to choose a target React Native app to connect to.
  • Identifies as a compatible CDP client: Sends the ReactNativeApplication.enable CDP method on attach.

Example launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to React Native target",
      "type": "react-native",
      "request": "attach",
      // Locates the React Native dev server, from which /json/list may reveal
      // several webSocketDebuggerUrl targets per device (dynamic and not
      // known up front)
      "port": 8081
    }
  ]
}

Target selection reuses the Node attach machinery but resolves its target by querying the dev server's /json/list endpoint and prompting the user to pick from the discovered targets (shown by name and description). The picked target's inspector WebSocket URL is written to websocketAddress, which the Node attacher connects to directly.

Impact / Why (I think) these changes belong in core

vscode-js-debug already claims to support React Native/Hermes under the "node" type (with specific references in this codebase) — but this is buggy. The added target selection step and ReactNativeApplication.enable call complete the picture, removing user confusion and the "unsupported debugging client" message we send back to VS Code currently.

By fixing this in core, the only thing React Native users will need is a configured launch.json for delightful VS Code debugging out of the box.

(Sidenote: We could go further, e.g. also shipping a 1P "Debug: Attach to React Native App" command to mirror Node.js — but skipped for now.)

Changes

  • New DebugType.ReactNative ('react-native'), added to the debug-type registry so the shared adapter and its config resolver are wired up automatically.
  • New IReactNativeAttachConfiguration, modeled as a distinct config type (structurally a Node attach with its own discriminant) so type narrowing stays sound. NodeAttacher and the source-path resolver route react-native through the Node path; threads.ts sends ReactNativeApplication.enable when the session type is react-native.
  • New ReactNativeConfigurationResolver and pickReactNativeProcess picker. The resolver only accepts the attach request and rejects a user-supplied websocketAddress (the target is always discovered, never hand-authored); the field is omitted from the type's schema. The dev server port comes from the launch config's port (default 8081).

**Motivation**

React Native apps expose their debugger through the Metro dev server's inspector proxy, not as a local Node process, so the existing "Attach to Node Process" flow can neither discover nor attach to them.

**This diff**

Adds a `react-native` debug type (attach request). It reuses the Node attach machinery but resolves its target by querying the dev server's `/json/list` endpoint and prompting the user to pick from the discovered targets (shown by name and description). The picked target's inspector WebSocket URL is written to `websocketAddress`, which the Node attacher connects to directly. On attach, the shared debug adapter sends the non-standard `ReactNativeApplication.enable` CDP method so the app knows a real debugger is attached.

Example `launch.json`:

```json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to React Native target",
      "type": "react-native",
      "request": "attach",
      "port": 8081
    }
  ]
}
```

**Changes**

- New `DebugType.ReactNative` ('react-native'), added to the debug-type registry so the shared adapter and its config resolver are wired up automatically.
- New `IReactNativeAttachConfiguration`, modeled as a distinct config type (structurally a Node attach with its own discriminant) so type narrowing stays sound. `NodeAttacher` and the source-path resolver route `react-native` through the Node path; `threads.ts` sends `ReactNativeApplication.enable` when the session type is `react-native`.
- New `ReactNativeConfigurationResolver` and `pickReactNativeProcess` picker. The resolver only accepts the `attach` request and rejects a user-supplied `websocketAddress` (the target is always discovered, never hand-authored); the field is omitted from the type's schema. The dev server port comes from the launch config's `port` (default 8081).
@huntie

huntie commented Jul 3, 2026

Copy link
Copy Markdown
Author

@microsoft-github-policy-service agree company="Meta"

@huntie huntie changed the title [DRAFT] feat: Add react-native debug type for attaching to React Native apps [RFC] feat: Add react-native debug type for attaching to React Native apps Jul 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant