In some contexts it can be convenient to automatically start a debug session (launched or attached) when the project is opened. For example, Firebase Studio embeds an emulator and starts a version of the Flutter app automatically, but Dart-Code is unaware of it (and therefore things like DevTools do not work).

It would be nice to specify a launch configuration somewhere that can be automatically started on start, which could be a full launch, or an attach. For example on Firebase Studio if we could automatically launch the config:

{
    "name": "Flutter app",
    "request": "attach",
    "type": "dart",
    "deviceId": "localhost:5555"
},

then when you load the project you would instantly have access to DevTools for the visible app in the emulator. By attaching (instead of launching ourselves), if you have a multi-user session, both would be attached to the same instance, rather than one of them replacing the other.

One option would be to add a flag (autostart: true) to launch.json, however since this is a file that is often committed to source control, it probably doesn't make sense as something that is auto-generated by the script that starts the preview. Probably a better option is to create our own file (that is easily gitignored).

Location

There are a few places we could store/read such a file from:

• .vscode/ folder (existing)
• .dart_tool/ folder (existing)
• .dart_code/ folder (new)

It's not clear to me that extensions should be using .vscode/ so probably we shouldn't use that. .dart_tool/ can be cleared by commands like flutter clean so probably is also not that suitable. So perhaps we should introduce .dart_code/ as a new workspace-level folder (which can easily be gitignored, but probably shouldn't show up for users except in some contexts). We could consider moving the existing "New Project" trigger files into this folder too.

.dart_code/autolaunch.json

So my current suggestion is to use .dart_code/autolaunch.json. The name makes it clear what this is for, and since the filename is similar to launch.json we can use the same format (since it's what we need anyway), but we can auto-launch these without an additional flag (it also avoids the confusion of what launch configurations without an autostart: flag would mean in this file, since right now they would be pointless).

For simplicity, we should still put the configurations inside a "configurations" key, so the format is the same as launch.json, because it's easier to copy/paste and compare.