I'm not sure I understand why we want to make these changes. The current default in VS Code is "auto" which won't pass the argument. It sounds like this already does what you want, but this PR makes the default explicitly canvaskit (which will also apply to all SDK versions, which might negatively affect people on older SDKs).

If we don't land this PR, then people that have not customised anything should be on "auto" and no option will be passed to Flutter. If users explicitly choose a renderer, then that rendered will be used. Is this not what you'd like?

Oh, maybe there is some confusion about "auto" here. I think there are two different "auto"s here.

1. In Flutter, "auto" means "use canvaskit for desktop, html for web"?
2. In Dart-Code, "auto" means "don't pass anything to Flutter and let it use its default"

The reason (2) is slightly different, is that it was to decouple the extension from Flutter's default. So I feel like we don't need to (shouldn't) do anything here?

The "auto" option is gonna be problematic once the default is changed in Flutter. People who explicitly configure "auto" in the Dart extension will be surprised that "auto" now turns into "canvaskit".

I recommend either:

1. Making this configuration null by default (I'm not sure how to do that).

2. Introduce a new "default" option (different from "auto") that lets Flutter choose the renderer.

If we don't land this PR, then people that have not customised anything should be on "auto" and no option will be passed to Flutter. If users explicitly choose a renderer, then that rendered will be used. Is this not what you'd like?

To be clear, the problem is when people explicitly select "auto" in the extension and they expect to get the "auto" renderer in their Flutter app. After the change lands in Flutter, suddenly "auto" in the extension will turn into "canvaskit" in their Flutter app.

Ah, I understand now.

In that case, I think adding a new option for "Flutter's default" and making it the default here would be better:

• flutter-default (default) - use Flutter's default value for renderer
• auto - use Flutter's "auto" setting which may pick a rendered based on the device
• canvaskit - always use canvaskit
• html - always use html

Using an explicit value instead of null allows us to add a description to make the distinction between flutter-default and auto clearer. What do you think?

Using an explicit value instead of null allows us to add a description to make the distinction between flutter-default and auto clearer. What do you think?

I agree!

Let me know if you want to update this PR, otherwise I'm happy to make the changes :)

Let me know if you want to update this PR, otherwise I'm happy to make the changes :)

Done! Please let me know what next steps I need to take.

All looks good to me, but there's a lint failure on the bots:

/home/runner/work/Dart-Code/Dart-Code/src/test/flutter_debug/flutter_run.test.ts
Error: 90:5 error Strings must use doublequote @typescript-eslint/quotes

Once that's done, I'll merge. Thanks!

Thanks!

So wasm is only for build but not for debug?

@chasanpro my understanding is that using wasm vs js is unrelated to the renderer (this issue). The renderer is what determines how the pixels are drawn on the screen (eg. HTML DOM elements or rendered to a canvas), whereas wasm is an alternative format for the scripts (instead of javascript).

That said, my understanding is also that wasm is only for release builds. Based on the footnote at https://docs.flutter.dev/platform-integration/web/wasm I think this is today only flutter build but in future may support flutter run --release too (I'm not sure if it'll support debug builds even with flutter run though, I don't know if a wasm build would be debuggable in the same way as a JS build that is translated through DWDS).