# React Native Tools for VS Code: Debugging and Editor Integration > React Native Tools is the Microsoft-published VS Code extension that runs react-native and expo commands from the command palette and attaches the editor debugger to Hermes. It suits teams already editing React Native or Expo code in VS Code, and it assumes a standard CLI project root. **microsoft/vscode-react-native** — VSCode extension for React Native - supports debugging and editor integration - Repository: https://github.com/microsoft/vscode-react-native - Website: https://marketplace.visualstudio.com/items?itemName=vsmobile.vscode-react-native - Stars: 2,733 · Forks: 295 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-vscode-react-native ## What React Native Tools solves, and who it is actually for React Native development splits attention across three surfaces: the editor, a terminal running Metro, and a device or emulator. React Native Tools collapses two of them. The extension contributes a Debuggers category to VS Code and a set of command palette entries that shell out to the react-native and expo CLIs, so react-native run-android, react-native run-ios and expo start are reachable without a separate terminal tab. The intended user is a developer who already has a working React Native environment and edits the project in VS Code. The README lists the preconditions plainly: a working React Native environment, an Android emulator on the PATH or an iOS simulator on macOS, VS Code with the extension installed from the Marketplace, and the React Native project root open as the workspace folder. That last point matters more than it looks. The extension declares activation events on workspaceContains:node_modules/react-native and workspaceContains:metro.config.js, so a workspace missing both will not light up the debugger at all. It is not a scaffolding tool and not a replacement for the React Native CLI. It is an editor integration layer over a toolchain you still have to install and keep working. ## How the debugger attaches: Hermes direct debugging versus the deprecated remote path The README divides debugging into two families. The recommended one is Hermes engine direct debugging, where VS Code's debugger talks to the Hermes runtime in the app rather than routing JavaScript through a proxy. The older remote JavaScript debugging path is still documented but marked deprecated. If you are starting a project today, configure the direct path; the remote path exists for projects pinned to older setups. Around that core the extension handles per-platform variants: Android Hermes debugging and custom builds for Android apps, iOS Hermes debugging, iOS devices, custom URL schemes for iOS apps, and Windows and macOS targets for React Native for Windows and React Native for macOS. Expo gets its own set: debugging on Expo Go, on expo-dev-client, and on Expo Web, plus Expo Hermes and EAS Build initialization. Two mechanisms are worth knowing before you file a bug. First, the extension writes intermediate debug files into .vscode/.react at the project root. The README says these usually get removed when the session ends but recommends adding the directory to .gitignore anyway, which tells you cleanup is not guaranteed on a crashed or killed session. Second, a monorepo section exists for debugging outside the React Native project directory, which is the acknowledgement that the default assumption of project root equals workspace root does not hold for everyone. ## Getting started: install the extension and run a first debug session Install from the Marketplace entry the README links, then confirm your machine is actually ready. The extension ships a check command for exactly this, and the README asks you to run it before going further. Open the Command Palette, type React Native, and choose the check command: ```bash React Native: Check development environment configuration ``` For an Expo project the equivalent check is React Native: Run expo doctor. Both report on installed software; if either complains about a missing emulator or SDK, fix that before touching the debugger. With the React Native project root open as your workspace folder, start the app. The README states that the Run Android and Run iOS commands trigger react-native run-android and react-native run-ios, and that Run Expo triggers expo start: ```bash React Native: Run Android ``` Metro comes up as part of that flow, and the Packager commands let you start and stop the Metro bundler independently if you prefer to control it yourself. To attach the debugger, open the Run and View panel, choose the React Native configuration, and start it. The extension declares activation events on onDebugResolve:reactnative and onDebugResolve:reactnativedirect, so the debug configurations appear once the extension is installed and the workspace contains a React Native project. Finally, exclude the scratch directory from version control. The README recommends adding .vscode/.react to your project's .gitignore. Without that line, a debug session that does not clean up will leave untracked files in every teammate's working tree. ## Where the extension gets in the way The biggest constraint is that this is an integration layer, not a build system. Every command it exposes delegates to the react-native or expo CLI, so anything your project does outside those CLIs is invisible to it. The README documents Re.Pack and Haul debugging as a separate topic, which is a signal that bundler swaps need extra configuration rather than working out of the box. The second constraint is the root directory assumption. The extension activates on node_modules/react-native or metro.config.js in the workspace, and the monorepo section exists because debugging outside the React Native project directory is not the default. If your app lives in packages/mobile and your workspace root is the repository root, expect to configure the debugger rather than have it work on first launch. The third is the .vscode/.react directory. The README's own wording is that files usually get removed after a debug session ends. Usually is doing real work in that sentence. Treat the directory as state that may survive an abnormal exit. Finally, there is a hard version floor. The extension's engines.vscode field requires VS Code ^1.75.0. On an older editor the extension will not install, and no amount of project configuration changes that. ## React Native Tools versus the standalone React Native CLI The honest alternative is the plain react-native CLI in a terminal plus whatever debugger the platform gives you. The difference is not capability, it is where state lives. With the CLI alone, Metro output, build logs and the debugger are three separate surfaces you arrange yourself; you can attach a debugger by hand and never install an extension. React Native Tools trades that manual arrangement for editor-owned state. Debug configurations live in your VS Code launch configuration, the debugger attaches through the editor's own UI, and the intermediate files land in .vscode/.react inside the repository. That is a real convenience when the whole team uses VS Code, and a real friction point when it does not, because the debug setup becomes editor-specific configuration that a Vim or JetBrains user cannot reuse. There is also a preview channel to consider. The README documents a nightly extension published daily at 9 PM PST on days when changes occur, under a separate Marketplace identity. If both the stable and preview extensions are installed, only the stable version activates; using the preview requires disabling or removing the stable extension and reloading VS Code. That is a deliberate design choice to avoid conflicts, but it means you cannot run both side by side to compare behaviour. ## Release cadence, upgrade cost and the licence question The repository is not archived, and the last push was on 2026-09-23. Releases are frequent and versioned: 1.13.3 on 2026-04-24, 1.14.0 on 2026-06-16, and 1.14.1 on 2026-07-13. The CHANGELOG.md at the repository root is where upgrade costs show up, and it is the file to read before bumping a minor version, since debugger configuration properties and deprecated paths can shift between releases. Building the extension from source is a separate track. The README states that building and testing React Native Tools requires Node.js 22 or later, and explicitly notes that this development requirement does not affect the runtime requirements of the installed extension. So a contributor needs Node 22; a user installing the .vsix or the Marketplace build does not. If you want to package it yourself, CONTRIBUTING.md documents the build, and the repository ships prepareBuild.bat and a gulpfile.js for that purpose. The licence is the part to read carefully. The repository metadata reports the licence as NOASSERTION, and package.json sets license to %reactNative.license%, a localized placeholder that resolves at build time rather than a literal SPDX identifier. The repository does contain LICENSE.txt and ThirdPartyNotices.txt. Read both before redistributing the extension or bundling it into a product; a placeholder in package.json tells you nothing about the actual terms. ## Conclusion Adopt React Native Tools if your team already edits React Native or Expo code in VS Code and wants the debugger attached without leaving the editor. Skip it if your project is driven by Re.Pack or Haul, or if your app does not live at the workspace root, because the extension activates on node_modules/react-native or metro.config.js in the opened folder. Before committing, run React Native: Check development environment configuration and confirm it reports your emulator and toolchain as ready, and add .vscode/.react to .gitignore since the extension writes intermediate debug files there. The licence field in package.json resolves through %reactNative.license% rather than a literal SPDX identifier, so read LICENSE.txt before redistributing the extension. ## FAQ ### Can I use React Native with VS Code? Yes. React Native Tools is published on the Visual Studio Marketplace and provides a development environment for React Native and Expo projects inside VS Code, including debugging and command palette access to the react-native and expo CLIs. ### How do I set up VS Code for React Native? The README asks you to have a working React Native environment, an Android emulator on your PATH or an iOS simulator on macOS, VS Code with the extension installed from the Marketplace, and your React Native project root open as the workspace folder. Then run React Native: Check development environment configuration to confirm the toolchain is detected. ### What is the best IDE to code React Native? The repository does not answer this, and the extension's contribution is bounded: it adds debugging and command palette integration to VS Code, and its debug state lives in VS Code launch configuration and .vscode/.react. Whether that makes VS Code the best choice depends on your team's editor, not on anything the README claims. ### Is React Native still relevant in 2026? That is a question about the React Native framework, not about this VS Code extension, so the repository material does not address it. The extension's own activity is visible in its release history, with 1.14.1 published on 2026-07-13. ## Sources - [Issues](https://github.com/microsoft/vscode-react-native/issues) - [microsoft/vscode-react-native on GitHub](https://github.com/microsoft/vscode-react-native) - [Project website](https://marketplace.visualstudio.com/items?itemName=vsmobile.vscode-react-native) - [README](https://github.com/microsoft/vscode-react-native/blob/master/README.md) - [Releases](https://github.com/microsoft/vscode-react-native/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-vscode-react-native