Forward device_id via toolArgs so Flutter run honors it

[FrantisekGazo]

Summary

Closes #85.

The device_id field in .zed/debug.json is currently a no-op for Flutter launches. The extension reads it and forwards it as deviceId in the DAP launch JSON, but Flutter's DAP (flutter_tools/lib/src/debug_adapters/flutter_adapter.dart) does not read that field — grep -r deviceId packages/flutter_tools/lib/src/debug_adapters/ returns a single hit and it's a comment. Only toolArgs is forwarded to flutter run --machine.

This PR forwards device_id as ["-d", <id>] in toolArgs so device selection actually works, and defines how it interacts with the user-facing toolArgs option added in #66.

Changes

• src/dart.rs:
  • When device_id is set explicitly, append ["-d", <id>] to the user's toolArgs — but only if the user hasn't already passed a device flag (-d / --device-id) themselves. In that case the user's toolArgs takes precedence.
  • The injection is gated to flutter mode only (dart run has no -d flag).
  • If device_id is not set, nothing is injected — Flutter's auto-pick stays in effect (preserves current behavior for users who don't specify a device).
  • Removed the phantom "chrome" default for the deviceId JSON field. It was never read by Flutter's DAP, and now that device selection flows through -d, an unconditional default there would hijack Flutter's auto-pick. deviceId is now emitted only when the user sets it, kept purely for forward-compat in case Flutter ever wires it up.
• debug_adapter_schemas/Dart.json: documented device_id and its precedence relative to toolArgs.

Precedence

User config	Result
device_id unset	Flutter auto-picks a device (unchanged)
device_id: "macos"	flutter run -d macos
device_id set + -d/--device-id already in toolArgs	user's toolArgs wins, no injection
type: "dart"	no -d injection (dart has no device flag)

Verification

DAP-level (hand-built launch requests piped to flutter debug_adapter, Flutter 3.41.6 stable):

Launch JSON	Result
{"deviceId": "macos", ...} (old behavior)	"More than one device connected", exits
{"toolArgs": ["-d", "macos"], ...} (this PR)	macOS app launches successfully

End-to-end in Zed (patched extension installed as a dev extension, Flutter 3.41.6, with an Android emulator + macOS desktop + Chrome web all available):

• device_id: "macos" → launches on macOS (previously hijacked to the running emulator)
• No device_id set → Flutter's auto-pick selects the emulator (current behavior unchanged)
• device_id + explicit -d in toolArgs → user's toolArgs wins

Related

• Fix debug adapter config bugs and add missing config options #66 added the user-facing toolArgs config field. This PR builds on it: device_id is merged into toolArgs, with the user's explicit device flag taking precedence.
• Add hot reload and hot restart custom actions #72 includes the same -d <id> via toolArgs mechanism as part of its hot-reload feature.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @FrantisekGazo on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[FrantisekGazo]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[FrantisekGazo]

@MrSubidubi could you please review this PR?

[MrSubidubi]

Hey, sorry for the delay! Could you please quickly merge main and update your changes to the older PR I just merged? I think there are some semantic conflicts and I'll hold off releasing a new version here until we resolved this here. Hope that works for you!

[FrantisekGazo]

sure. i merged the main now, but there we no conflicts

[MrSubidubi]

I do think there are some, see line 203. I think we might need to update the logic here perhaps and/or change the schema?

[MrSubidubi]

Note I mentioned

semantic

merge conflicts 🙂

[FrantisekGazo]

Good catch — merging main left three semantic conflicts with #66:

1. My early tool_args binding was shadowed by Fix debug adapter config bugs and add missing config options #66's toolArgs parsing before it was read, so device_id was silently dropped.
2. toolArgs got written into the config JSON twice (the json! literal + the conditional at line 203).
3. No precedence rule when both device_id and a -d in toolArgs are set.

Fixed in 3f2f3dc:

• device_id is merged into the user's toolArgs as -d <id>, only when they haven't already passed -d/--device-id (user's toolArgs wins), and gated to flutter mode.
• Removed the duplicate write and the phantom "chrome" default (never read by Flutter's DAP; deviceId now emitted only when set, for forward-compat).
• Documented the field + precedence in the schema.

Verified end-to-end: device_id: "macos" launches macOS with an emulator running; unset falls back to auto-pick; explicit -d in toolArgs wins.

[FrantisekGazo]

@MrSubidubi one more thing — the device_id field is snake_case, while every other field in the debug config is camelCase (toolArgs, flutterMode, vmServiceUri, stopOnEntry, ...). Since device_id has been a no-op until this PR (Flutter's DAP never read it), there's effectively no working config relying on it, so this seems like a good moment to rename it to deviceId for consistency.

It's technically a breaking rename, but only of a field that never actually did anything. Are you OK with me including that here, or would you prefer to keep device_id (or accept both)?