Dart 3.14 Brings Automated SDK Migrations, Hardware SIMD, and a Rebuilt DartPad

Dart 3.14 shipped on November 11 next to Flutter 3.50, and the language release reads less like a syntax drop and more like a tooling release. The theme in the announcement is a closed loop: prototype in the browser, ship to mobile, desktop, and web, then automate the upgrade path to the next SDK. Three of the five sections are about tooling rather than the language itself.

dart migrate Automates the Upgrade Path

Moving a package to a newer SDK has always involved two jobs that people do by feel: bumping the constraint and fixing whatever the new version broke or made redundant. The new dart migrate command splits the work into a repeatable sequence. For each version step it first applies preparatory fixes through dart fix, then raises the lower bound of the SDK constraint in pubspec.yaml, and finally offers optional cleanup fixes that adopt new language features or style rules.

The example in the announcement is a package on ^3.12.0 that passes final parameters in a method signature. Dart 3.13 made those a compile-time error, so the prepare step removes the modifier, the bump step moves the constraint, and the cleanup step rewrites an empty class body to the new semicolon form. The tool reports each step separately, including which lint produced which edit, so a reviewer can see exactly what changed between versions.

dart migrate --dry-run previews the changes and --apply writes them. On large codebases the --step flag allows running prepare alone before deciding whether to bump, or running bump,cleanup after a manual review of the preparatory edits. By default the tool advances one minor version at a time; --target-sdk=3.14.0 jumps straight to a target. Only packages whose constraint already requires Dart 3.0 or later are supported, which puts older libraries outside the tool's reach.

Faster Resolution, Faster Analysis

Two quieter changes affect daily wait times. dart pub now stores the server's ETag alongside cached package listings and sends conditional If-None-Match requests when the cache is warm. When nothing has changed, pub.dev answers with 304 Not Modified and an empty body, and pub reuses its local listing. On a Flutter project with 144 dependencies that removes about 1.5 MB of repeated version-listing downloads per resolution, which matters most on high-latency connections and in CI.

The analysis server picked up several fixes aimed at workspaces with many analysis contexts. File discovery is faster, which speeds up requests like Find References, tasks that used to block formatting are less blocking, startup is quicker including after a restart triggered by pubspec or analysis option changes, and documentColor responses no longer stall other requests. Analyzer plugin roots are now scoped to plugin context roots, so plugins analyze only what they own.

DartPad Now Runs the Toolchain in the Browser

The DartPad beta is rebuilt on package:dartpad, which compiles the Dart compiler, the analyzer, and the pub client to WebAssembly and runs them in a Web Worker. Analysis and compilation happen locally instead of on a remote server, so feedback arrives without a round trip. Full Language Server Protocol support comes with it, which means completion, hover documentation, go-to-definition, and quick fixes behave the way they do in an IDE.

Two consequences follow. Packages can now be pulled from pub.dev instead of a hand-picked allowlist, so a snippet can use the same libraries as a real project. And DartPad supports multiple files, which makes widget and data model organization possible without cramming everything into one buffer. The announcement frames this as proof that Dart scales across machines, servers, and browsers, since the tools themselves are written in Dart and compile to Wasm.

• WebAssembly apps now target Chrome 137+, Safari 26.2+, and Firefox 147+ by default
• dart compile wasm --standalone produces standard .wasm files that run in Wasmtime without a JavaScript host
• --no-deprecated-js-interop rejects dart:html, dart:js, dart:js_util, and package:js at compile time
• Int32x4, Float32x4, and Float64x2 operations compile to 128-bit SIMD, with up to 4x speedups in benchmarks

The WebAssembly work behind those bullets is mostly invisible until it is missing. dart2wasm now emits finalized try_table exception instructions instead of relying on JavaScript wrappers, which is what lets standalone modules run outside a browser at all, and it works around a streaming compilation issue in Safari 26.5 and earlier. The community contribution behind this came from Simon Binder, whose wasm_tools package explores WASI and the component model.

Hardware SIMD is the other performance story. More than 60 SDK contributions from community member Modestas Valauskas let dart2wasm compile typed-data vector types directly to v128 instructions, and dart:typed_data gained optimized Int32x4 operations on native platforms. In practice, code that does bulk math on vectors, image processing, or audio buffers can see up to a 4x improvement without changing its structure.

Smaller additions round out the runtime. dart:typed_data now has a rangeEquals extension on every integer typed data list and on ByteData, lowered to memcmp on the VM, to direct Wasm array loads, and to tight typed-array loops on JavaScript, so comparing a buffer slice no longer needs allocated views. The release also notes that type promotion and static extensions are still in progress for an upcoming version.

Finally, process. The Dart project now requires a Request for Comments document for large changes that need team consensus, following the same path Flutter took with its RFC repository. Both processes put design discussion and decision artifacts in one public place, which is the sort of thing that matters more as outside contributors drive more of the release, as they did for the SIMD and standalone Wasm work here.