Where do you store user settings? Can you read the setting directly from there? This way you don't need to patch the URL. People tend to save and share URLs, so one person's setting could leak to another person.

Issue here is that you're not actually using the userConfig variable. You probably need to splat it into the config below, i.e.:

...
    config: {
        canvasKitBaseUrl: 'canvaskit/',
        ...userConfig,
    },
...

Also, if you want JS + CanvasKit by default, you need to set the renderer to canvaskit when there is no url query parameter. The bootstrapper will use the first build it can find that works in the browser environment and abides by the configuration set by the user. The dual-compile build has the dart2wasm+skwasm build as its first option, and dart2js+canvaskit as its second option. If you want to skip the first option, you need to specify that you want canvaskit.

I would actually change the way this url query parameter is structured and just simply make it like allowWasm=true or something like that. Then, I would specify 'renderer': canvaskit if that query parameter is not found (or a non-truthy value), and then don't specify the renderer at all if allowWasm=true. That way, if someone opens it in a browser that doesn't actually support WasmGC or some of the other things skwasm needs, it will still fall back to dart2js+CanvasKit.

We store settings on disk in the ~/.flutter-devtools/.devtools file. DevTools runs on local host, so URLs won't typically be shared unless someone is running on a remote machine and passes that URL around, which is unlikely.

Issue here is that you're not actually using the userConfig variable. You probably need to splat it into the config below, i.e.:

...
    config: {
        canvasKitBaseUrl: 'canvaskit/',
        ...userConfig,
    },
...

Also, if you want JS + CanvasKit by default, you need to set the renderer to canvaskit when there is no url query parameter. The bootstrapper will use the first build it can find that works in the browser environment and abides by the configuration set by the user. The dual-compile build has the dart2wasm+skwasm build as its first option, and dart2js+canvaskit as its second option. If you want to skip the first option, you need to specify that you want canvaskit.

I would actually change the way this url query parameter is structured and just simply make it like allowWasm=true or something like that. Then, I would specify 'renderer': canvaskit if that query parameter is not found (or a non-truthy value), and then don't specify the renderer at all if allowWasm=true. That way, if someone opens it in a browser that doesn't actually support WasmGC or some of the other things skwasm needs, it will still fall back to dart2js+CanvasKit.

@eyebrowsoffire @yjbanov is there a way to know that we tried to use WASM but had to fall back? Otherwise this could get in an infinite loop when the attempt to load with WASM fails and we fell back to JS.

This would make kIsWasm false, and we would continually try to change the value of the wasmEnabled notifier to true based on the value of (enabledFromStorage || enabledFromQueryParams). This would then trigger the listener and reload the page again, and repeat.

I think you can just check the actual query params via JS interop (I'm not sure if DevToolsQueryParams is actually doing that or if it is some other system for composing the URL to pass back to the user) and then also look at kIsWasm. If the query parameters in the actual url have the useWasm parameter, but you're not in wasm mode, then we've fallen back to JS.

I have contemplated exposing some more rich information about what happened in the bootstrap process and why, but I don't know exactly what that would look like and we haven't implemented anything currently.