Expo Tools: IntelliSense, debugging and prebuild previews in VS Code

Completion for five different Expo configuration formats

The core of Expo Tools is IntelliSense for the JSON and YAML files that configure an Expo project. The README lists exactly five formats it understands, and the choice of that list is the extension's main value.

EAS Build, Submit and Update are covered by eas.json. EAS Metadata is covered by store.config.json. EAS Workflow files are covered by .eas/workflows/*.yml. The Expo app manifest is covered by app.json, and Expo Modules are covered by expo-module.config.json.

That is a meaningful slice of the Expo configuration surface, and each entry points at the corresponding documentation page, so the suggestions come with the reference text for the key rather than a bare property name.

The mechanism is visible in the dependencies. jsonc-parser handles the JSON with comments that VS Code tolerates, and @expo/config-plugins is the same plugin resolution layer the Expo CLI itself uses to interpret app configuration, which is why the extension can validate a manifest the way the tooling would rather than guessing from a hand-written schema.

The practical value is narrower than a general JSON schema and that is the point. A generic schema would tell you that a property is a string. This one knows that a value in app.json means something specific to Expo and can tell you what.

One limitation is visible in the list: it is closed. The README does not mention support for other configuration files, such as a custom metro.config.js, babel.config.js, or a CNG-specific variant, and the extension is scoped to the Expo layer rather than to the whole toolchain around it.

An expo debugger that attaches from the editor

The second feature is debugging, and it is a thin layer over a debugger that already exists rather than a new engine.

The README states that the built-in expo debugger can connect directly to a simulator or a phone, giving insight into what the app is doing, and that you can start it with a single command through the Expo: Debug entry. Alongside that, the extension can be fully configured through VS Code launch scripts in .vscode/launch.json, using the standard VS Code debugging configuration format.

The distinction matters for how you work. If you are happy with the default settings, the command in the command palette is enough. If you need to change ports, environment variables or the debug adapter, you drop to launch.json, which is the same file any other VS Code debugger uses, so the settings live alongside the rest of your editor configuration and can be committed.

What the extension is not is a replacement for a native debugger. It is a launcher for the expo debugger inside the editor, and once you are debugging a native module in Java or Kotlin or Objective-C, you are back to the platform tooling. The README does not describe any native-level debugging support, so that boundary should be assumed.

The dependency list supports this reading. The debug package is listed as a runtime dependency, and the extension talks to the Expo CLI through @expo/spawn-async, which is how the Expo project spawns child processes.

Previews of the native files prebuild would write

The feature that distinguishes this extension is the live preview of native files. The idea is simple: you change app.json or app.config.js, and instead of running a prebuild to find out what changes on the native side, the extension renders the affected native files in the editor.

The README is precise about the mechanics. The previews are generated whenever you save the app manifest, they will not affect existing files, and you trigger them by opening app.json or app.config.js and running the Expo: Preview Modifier command. Nothing is written to your project, so the preview is a read-only view of what would happen.

The set of files that can be previewed is a fixed list, and the README enumerates it. On the Android side that is AndroidManifest.xml with its settings for build tools, Android and Google Play, gradle.properties for the Gradle build toolkit configuration, colors.xml for colour resources, strings.xml for string resources, and styles.xml for the format and look of a UI element.

On iOS the list is Info.plist with the core configuration for the app, the entitlements file for the app, which the README describes as the property list enabling permission to use services, Expo.plist as the supporting property list for Expo, and Podfile.properties.json with install or build configuration.

That fixed list is also the limitation. The preview is not a model of your whole native project, it is a rendering of a handful of files that Expo config plugins are known to influence. If a plugin writes a file outside this list, the preview will not show it.

Three manifest previews: prebuild, introspect and public

Alongside the native file preview there is a second preview command, Expo: Preview Config, which shows the generated manifest for your app rather than the native files.

The command works on the same two entry points, app.json and app.config.js, and it offers three flavours. The prebuild preview is the local app manifest as it would be when running npx expo prebuild. The introspect preview is the evaluated app manifest result of the same command, which is the difference between what you wrote and what the configuration actually resolved to. The public preview is the hosted manifest used when you publish with Expo Updates.

The distinction between the first two is the interesting one for anyone who uses app.config.js. A config file can compute values from the environment, so the file you wrote and the manifest the tooling evaluates can differ. Seeing both is a way to catch that before it becomes a confusing build problem.

The public preview is the one to use when the question is about what a client would fetch, since that is the manifest that determines the runtime behaviour of an update.

All three come from the same underlying configuration machinery, which is the @expo/config-plugins and @expo/prebuild-config pair in the dependencies. The extension is not re-implementing manifest generation, it is calling the same code path and presenting the result.

Building and packaging the extension from source

The extension is published as vscode-expo-tools with the display name Expo Tools, and it lives in the expo organisation on GitHub. Installation is from the VS Code Marketplace or from Open VSX, which is the store used by editors other than VS Code such as VSCodium, and the README links to both listings under the identifier expo.vscode-expo-tools.

The package.json describes a conventional TypeScript extension build:

  "name": "vscode-expo-tools",
  "displayName": "Expo Tools",
  "version": "1.6.3",
  "main": "./out/src/extension.js",

The main entry point is the compiled extension file under out/src, and the build is driven by npm scripts:

    "build": "tsc -p ./",
    "build:production": "webpack --mode production",
    "clean": "git clean -xdf ./out ./.vscode-test *tsbuildinfo",
    "test:vscode": "node ./out/test/mocha/vscode.js",
    "lint": "eslint ."

The production bundle is a webpack build, and there is a patch-package postinstall hook, which explains the patches/ directory in the repository: upstream dependency patches are applied automatically after install. There is a separate test script runner for the scripts directory alongside the VS Code integration tests, and both a .eslintrc.js and a .prettierrc.js for linting and formatting.

Releases are automated rather than hand-written. The .releaserc.js file and the semantic-release dev dependencies point to a conventional-commits release pipeline, and the changelog and contribution guides are kept in CHANGELOG.md and CONTRIBUTING.md at the root.

Where Expo Tools stops, and what it does not cover

The first boundary is the editor. This is a VS Code extension. Open VSX availability means the same code can be installed in other Code-compatible editors, but the extension relies on VS Code APIs, so it is not available in a full IDE such as Android Studio or Xcode, and it does not help a team whose React Native work happens elsewhere.

The second is the scope of the config coverage. Five config formats get IntelliSense, and the native preview covers a fixed list of files. Anything a custom config plugin writes outside that list is invisible to the preview, and the README does not describe an extension point for adding formats.

The third is what the preview does not do. It will not affect existing files, which is reassuring, but it also means you cannot use the preview as a diff of your real project, and you still need to run a prebuild to see anything the preview does not render. For a project with a large native directory that is committed to the repository, the preview and the real project can drift, and the README does not say the extension reconciles them.

The fourth is telemetry. @vscode/extension-telemetry appears in the runtime dependencies, and the README does not describe what is collected, whether it can be disabled, or how it is stored. For a team with a strict policy on build-time data collection, that gap is worth resolving before installing the extension across a fleet of machines.

Release rhythm, licence and the cost of keeping up

The project is not archived and the last push was on 2026-10-16. The tagged releases move a few times a year: 1.6.1 on 2025-07-10, 1.6.2 on 2025-12-10, and 1.6.3 on 2026-05-21. The package version in package.json matches the latest tag.

That is a slower cadence than the underlying tooling it depends on. The extension depends on @expo/config-plugins and @expo/prebuild-config, which track the Expo SDK releases, and the whole point of the extension is to describe a configuration format that Expo itself keeps changing. A user on a new SDK is therefore often waiting for the extension to catch up, and the version numbers alone will not tell you whether a given SDK is supported, because the README does not map extension versions to SDK versions.

The licence is MIT, recorded in the package.json metadata and in the LICENSE.md file at the root of the repository. For a developer tool, that means you can read the code, patch it, and redistribute it under the terms, which matters more for organizations that build internal variants of their tooling.

The upgrade cost for a user is the extension updating itself through the editor. The upgrade cost for a contributor is the Node and TypeScript toolchain, the webpack production build, the patch-package workflow for dependency patches, and the semantic-release pipeline, all of which sit in the repository rather than being hidden behind a hosted build service.

Editorial conclusion

Adopt Expo Tools if you work on Expo apps in VS Code and regularly edit app.json, eas.json or the workflow files, and you want to see what a config change does to the native project before committing to a prebuild. Do not adopt it as a replacement for Android Studio or Xcode, and do not expect the previews to be a full native project model, because the README scopes them to a fixed list of files. Verify first that your config format is one of the five the extension recognises, that your editor can install expo.vscode-expo-tools from the marketplace or Open VSX, and that you are comfortable with the extension telemetry dependency listed in package.json, since the last push was on 2026-10-16 and the newest tag is 1.6.3 from 2026-05-21.

Frequently asked questions

Official sources

1. expo/vscode-expo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases