Dart 2 migration guide

Dart 2 has a few key differences from earlier versions of Dart.This page briefly covers those differences andgives general advice on migrating your code to Dart 2.

For information on why Dart 2 has changed, see theDart 2 announcement.

Differences

The Dart language, libraries, build system, and web development tools have changed.

Language and libraries

Tools

Migrating your code

How to migrate your code depends on how old your code isand what platforms it runs on.For help with migrating web apps,see the web app migration guide.If you’re migrating a Flutter app,consult the breaking change notification.If you publish packages,then in addition to making platform-specific changes,follow the package migration instructions below.

General process

Here’s an overview of the process of migrating to Dart 2,from either Dart 1.x or an earlier version of Dart 2.

  • Get an up-to-date version of the Flutter or Dart SDKand the plugins for any IDEs you use.
  • Upgrade the packages your app depends on.
  • Run the dart2_fix tool. It helps migrate someusages of deprecated Dart 1.x APIs to Dart 2.
  • Run the analyzer to find compile-time errorsand deprecation hints.
  • Fix issues in your code and run the analyzer again,repeating until your code passes static analysis.
  • Run tests to find runtime errors.
    • Run all automated tests for your software.
    • Do manual testing, and look for console errors.Consider adding automated tests to catch issues that you find.
  • Fix issues until your code works.
  • Optional:Remove new and unnecessary const.
    • You can remove these by hand or use a tool such as dartfmt —fix.
    • To find occurrences of new and unnecessary const, add the rulesunnecessary_new and unnecessary_const to the linter section of youranalysis options file.

Migrating packages

As a package owner, you need to do the following:

  • Follow the migration tips for the platforms that your package supports(see above).
  • Make sure your package passes Dart 2 analysis (see Run the analyzer above)
  • Make sure your package’s users know how to report issues.
  • Respond quickly to issue reports.
  • If code changes aren’t backward compatible,update the lower SDK constraint.

Changes and backward compatibility

If you have to change your package’s code,try to make it work in 1.x, as well as Dart 2.For example, you might be able to add type annotationsor (if an API has been removed) to use an alternative 1.x API.

If a backward-compatible change isn’t possible,update the lower SDK constraint.

Test your changes to make sure that your package works as expected.

Upper constraints on the SDK version

Once your package passes Dart 2 analysis, update the upper constraintto declare that the package is compatible with Dart 2:

  1. environment:
  2.   # Works in Dart 2 only.
  3.   sdk: '>=2.0.0 <3.0.0'

If you plan to maintain compatibility with older versions of Dart, adjust thelower SDK constraint accordingly:

  1. environment:
  2.   # Works in Dart 1 (starting with 1.20.1), and works in Dart 2.
  3.   sdk: '>=1.20.1 <3.0.0'

If you use features introduced after 2.0,be sure to specify the correct lower SDK constraint:

  1. environment:
  2.   # Works in 2.1 but not 2.0.
  3.   sdk: '>=2.1.0 <3.0.0'

Packages must have an upper constraint of <3.0.0 to work in Dart 2 stable and subsequent Dart 2 releases. Dart 2 dev builds before the stable release have lax upper constraint checking and can use packages that have no SDK constraints or an upper constraint of <2.0.0.

More resources