Repository navigation
[tool][web] Require --release for "flutter run --wasm" and emulate "flutter build web --wasm" #190777
Description
Currently, running flutter run --wasm without --release creates an ambiguous middle ground: it attempts a debug-style compilation without full DDC/DWDS debugging support, yet lacks parity with production Wasm deployments (flutter build web --wasm). There is no clean way for developers to test and preview an actual Wasm production deployment locally without manually performing a build and setting up a separate web server.
We propose:
- Require
--releasewhen using--wasm:flutter run --wasmmust require--release. Attemptingflutter run --wasmin debug/profile mode will fail fast with a helpful tool exit error. - Emulate
flutter build web --wasminflutter run --wasm --release: Provide maximum parity with production builds and local web serving setup (including release compiler optimizations, headers, and asset server setup). - Establish Clear Developer Expectations: Hot reload is explicitly unavailable for Wasm release runs, while Hot Restart (
R/r) operates on a best-effort basis (triggering full Wasm re-compilation and browser reload).
Proposed Behavior & Scope
1. Command Flag Validation
When executing flutter run --wasm, the CLI tool checks the target build mode:
$ flutter run -d chrome --wasm
Error: --wasm mode for "flutter run" requires --release mode.
To run your web app with WebAssembly, pass --release:
flutter run -d chrome --wasm --release2. Parity with flutter build web --wasm Deployment
flutter run --wasm --release will emulate the exact output structure and headers of running flutter build web --wasm + serving via a production web server:
- Release Asset Server: Serves compiled web output via
ReleaseAssetServer. - Cross-Origin Isolation Headers: Automatically injects required Wasm headers:
Cross-Origin-Opener-Policy: same-originCross-Origin-Embedder-Policy: require-corp(orcredentialless)Cross-Origin-Resource-Policy: cross-originAccess-Control-Allow-Origin: *
3. Compiler Parity
Align ResidentWebRunner compiler configuration for Wasm release builds with build_web.dart, producing release-optimized Wasm artifacts (WasmCompilerConfig with release optimization levels, minification, and symbol stripping).
4. Development Loop Expectations
- Hot Reload: Disabled (not supported for static Wasm compilation).
- Hot Restart: Supported on a best-effort basis by re-invoking
dart2wasmand refreshing the connected browser window.
Key File Touchpoints in flutter_tools
-
packages/flutter_tools/lib/src/commands/run.dart
Add validation logic inRunCommand.validateCommand()to reject non-release build modes whenuseWasmis active. -
packages/flutter_tools/lib/src/isolated/web_asset_server.dart&packages/flutter_tools/lib/src/isolated/release_asset_server.dart
EnsureReleaseAssetServeris used for allflutter run --wasm --releasesessions with full cross-origin isolation header support. -
packages/flutter_tools/lib/src/isolated/resident_web_runner.dart
Update_compilerConfiginResidentWebRunnerto pass releaseWasmCompilerConfigoptions matchingbuild_web.dartand handle best-effort hot restart re-compilation.
Activity
nshahan commentedon Aug 19, 2026
Related: #186253
JamesHancockAtteria commentedon Sep 17, 2026
I would argue that work needs to happen to enable wasm builds to have debugging. Wasm builds in production have significant differences in behaviors from non-wasm. We've been bitten by this deploying to production. Given that I would expect WASM will be the default way that flutter web apps are build within the year, not being able to debug with the same code execution that production is using is a major gap that lowers the quality of flutter applications without this being addressed.