Announcing Dart 2.10

Michael Thomsen
Oct 1, 2020 · 6 min read

A new, unified dart tool for all core tasks. Also, an update on null safety timelines and migration principles.

By: Michael Thomsen & Kevin Moore

Today we’re announcing a new release of Dart, version 2.10 (two-dot-ten). This release features a new, unified Dart developer tool: a single tool for all your developer needs like creating projects, analyzing and formatting code, running tests, and compiling apps. We also have an update on the null safety roadmap and timelines, and a discussion of the principles for migrating existing code to null safety.

A new, unified Dart developer tool

Learn about the 2.10 dart tool by running dart help.

Flutter includes this new Dart tool in the Flutter SDK. Starting with today’s Flutter 1.22 SDK, the <flutter-sdk>/bin directory (which you likely have in PATH) contains both flutter and dart commands. If you do both Flutter and general-purpose Dart development, you get both developer experiences from a single Flutter SDK, without needing to install anything else.

Note: If you want to download and install a second Dart SDK (perhaps because you require a different version), make sure the SDK of the dart tool you wish to default to is at the beginning of your PATH environment variable.

Over the coming stable releases, we plan to add more to this dart tool and gradually deprecate the smaller tools (dartdoc, dartfmt, dartanalyzer, etc.). Next year we expect to ship Dart SDKs that contain only the single dart tool. We recommend that you switch over to the new tool when running Dart commands now, whether manually in the terminal or in continuous integration (CI) scripts, and give us feedback if anything is missing or not working as intended.

Looking forward to null safety

When might null safety be ready to use? Here is the current timeline:

  1. Flutter experimentation with technical preview 2: We’ve successfully migrated most parts of Flutter. Soon — likely within the next month — we expect to have the complete Flutter framework migrated, and thus be ready to enable experimental use with Flutter. You’ll be able to try null safety in a Flutter sample, and to do trial migration of your Flutter apps and packages. You’ll need to pass an experiment flag, shouldn’t use it in production, and shouldn’t publish any migrated packages.
  2. Early package migration with beta: Later this year, we’ll complete performance tuning and have sufficient test coverage to give us confidence that the feature works as intended, and that backwards compatibility is solid. At that time we’ll publish a beta version of the feature, and you won’t need to pass the experiment flag. We hope to see package owners begin migration of their packages to null safety, with that one last round of validation that the feature is ready for a stable release.
  3. Production use with stable: Depending on the feedback from the beta launch, we’ll fix any remaining issues and then publish to stable. It’s hard to state a concrete timeline for this, but we’re thinking early next year. Once the feature is stable, we hope to see lots of adoption of null safety, with null-safe apps published to stores, and many null-safe packages published to pub.dev in stable versions.

Principles for migrating to null safety

Adopt when you’re ready

Without null safety                 With null safetyString s; // A String or null.      String s; // A String, not null.

Such a fundamental change would be extremely disruptive if we insisted on forced adoption. We want to let you decide when the time is right, so null safety is an opt-in feature: you’ll be able to use the latest Dart and Flutter releases without being forced to enable null safety before you’re ready to do so. You can even depend on packages that have already enabled null safety from an app or package that hasn’t yet.

Adopt incrementally, in order

Why is the order important? Although you can make some progress migrating code before your dependencies migrate, you risk having to do a second migration pass if your dependencies change their APIs during their migration. We will provide tools to help you find out which of your dependencies have migrated. If you’re a package author, then to avoid the risk of breaking your APIs, wait until all of your dependencies have migrated before you publish a null-safe version.

Use automated tools to reduce migration cost

The migration tool is interactive, so you can review the nullability properties that the tool has inferred. If you disagree with any of the tool’s conclusions, you can add nullability hints to change the inference. For example, if you want to make an API non-nullable even though some refactoring will be needed, you can tell the tool and rerun the migration analysis. Adding a few migration hints can have a huge impact on migration quality.

Get full benefit with full use

Next steps

We’ll have more news about null safety soon — very likely within the next month, when we expect our friends in the Flutter team to have a null-safety-enabled Flutter framework ready for experimentation. Keep an eye on the Flutter blog for an update. In the meantime you can experiment with null-safe Dart code using DartPad with Null Safety, and learn more about the feature design by reading our null safety documentation.

Dart

Dart is a client-optimized language for fast apps on any platform.

Dart

Dart is a client-optimized language for fast apps on any platform. Learn more at https://dart.dev.

Michael Thomsen

Written by

Product Manager working on Dart and Flutter. Helping developers is my passion!

Dart

Dart is a client-optimized language for fast apps on any platform. Learn more at https://dart.dev.