DEV Community

loading...

Mixing packages that don't support null safety in Flutter

Jordan Holland
I'm a Flutter enthusiast with a background in Android development.
Originally published at developermemos.com ・3 min read

Null safety has been supported for a few months now in Dart and Flutter. I've migrated pretty much all of my projects to null safety without any issues but in some cases you might be waiting on a particular package that isn't supported yet. It's actually possible to use packages that don't support null safety in your project and still migrate to null safety. It's even possible to slowly migrate your project piece by piece to null safety too.

Using outdated packages(that don't support null safety)

I ended up in this precidament with one of my projects because I made the mistake of depending on charts_flutter. The package itself is great but Google is pretty terrible at keeping the GitHub mirror up to date with their internal repo. That's a story for another day though...Anyway there was only one package in my project holding me back from going to null safety. Building without null safety requires passing an extra command line flag, that's why I put things off for so long but in the end I gave in. So if you want to use outdated packages in your project(that has migrated to null safety) you need to add this to basically every command: --no-sound-null-safety. So if you were running flutter run you would do it like this:

flutter run --no-sound-null-safety
Enter fullscreen mode Exit fullscreen mode

Same goes for your tests as well:

flutter test --no-sound-null-safety
Enter fullscreen mode Exit fullscreen mode

Declaring the Dart version of your entry point

There's also another option of adding // @dart=2.9 to the top of the entry point(main.dart) of your app:

// @dart=2.9

main() {
  // Do something
}
Enter fullscreen mode Exit fullscreen mode

I personally like this option better but doing this won't extend to your tests, so you either have to pin the dart version of all of your tests to 2.9 or use the --no-sound-null-safety flag. You can use the version pinning above to slowly migrate your project files too, which is pretty good if you would like to break your migration up into small commits(but still keep everything working between each commit).

In the end I just opted for using --no-sound-null-safety because I wanted to migrate all of my tests too. By the way, you still have to pass this flag even when you're doing stuff like building APK files:

fvm flutter build apk --split-per-abi --no-sound-null-safety
Enter fullscreen mode Exit fullscreen mode

I'm gunna try fiddling with the entry point version pinning in the future to see if I can work around this somehow.

But this doesn't work with Visual Studio Code...

Yeah I noticed this myself too... To get all of this working with VSC(including your tests) you need to change some settings. Open your preferences and then select 'Workspace', then type 'args' into the search bar. After that select 'Dart & Flutter' from Extensions in the left pane. After this you should see settings for passing additional arguments to a bunch of different Flutter commands. You need to add --no-sound-null-safety to the ones that are relevant to you. You could opt to pass it to all flutter CLI commands too. I just added it for run and test in the end. Here's a screenshot of my setup for reference:

Visual Studio Code Settings

The pains of null safety migration

Null safety support was a pretty big change. I think it was worth it too, and I'm really glad that there is atleast an option to choose to build/run without complete null safety. I do kind of wish Google would keep their repos up to date though...Even if it is just a mirror of an internal project... But I guess that is just how open source is so I can't really complain too much.

Discussion (0)