Support app.config.ts for URL scheme resolution and declared plugin discovery #84

Hi! Thanks for the new agent CLI. I am using @expo/agent-cli@1.0.13 with Expo 58.0.0-preview.2, and would like dynamic configs to be supported consistently for URL scheme resolution and declared plugin discovery.

Configuration

My app uses only app.config.ts, with no app.json. Relevant fields, reduced from the existing app (not a separately tested minimal project):

import type { ExpoConfig } from "expo/config";

export default {
  name: "Marmelade",
  slug: "marmelade",
  scheme: "marmelade",
  ios: { bundleIdentifier: "dev.marmelade.app" },
  plugins: ["expo-font"],
} satisfies ExpoConfig;

The package name is marmelade; expo-font and expo-dev-client are installed. bun run agent runs the project-local expo-agent-cli.

Observed behavior

1. Run bun run agent navigate /dev --ios --app-id dev.marmelade.app --print-url --json.

The output URL is exp+marmelade://dev, with the explanation that no scheme field was found. Expected: marmelade://dev. Adding --scheme marmelade produces the expected URL. This command only prints the URL; it does not open a device. The fallback scheme may also be registered by the dev client, so this alone does not establish a navigation failure.

2. Run bun run agent inspect:config-plugins --json.

The command successfully evaluates native config through expo config --type introspect --json, but reports:

{ "name": "expo-font", "version": "58.0.1", "declared": false }

Expected: declared: true, since the plugin is explicitly listed in app.config.ts.

Suggested improvement

I understand that deepLink.ts and project/appConfig.ts intentionally read static JSON rather than executing project code inside the CLI.

Could these consumers resolve dynamic configs through the project-local Expo CLI in a subprocess, retaining the fast static path? #70 introduces caching for evaluated configs for the OTA verdict and might provide a reusable mechanism; it does not appear to cover these consumers.

This would avoid repeating the scheme and make declared-plugin metadata consistent with effective config. If evaluation fails, an explicit unknown result would be preferable to reporting configured plugins as undeclared.

Environment

• Agent CLI: 1.0.13
• Expo: 58.0.0-preview.2
• React Native: 0.88.0-rc.0
• Node: 24.21.0; Bun: 1.4.2
• macOS: 27.0

Thanks for considering this!