Null safety migration

[olexale]

Thanks for your package! I totally love it!

I have migrated the package to null safety. Mostly here you might find changes from the Dart migration utility but I have changed code here and there to make linter happy. All tests passed and samples from the example folder were generated fine as well. I have tried this version with a simple app and seems like everything is working as expected.

Please take a look at the proposed changes. Thanks in advance!

[Tomucha]

This is awesome, I will gladly merge it!

Are you sure it's going to be alright? Because build_runner is not null safe yet, and I was under impression that it's generally recommended to wait till all dependecies are "null safe" ... ?

[olexale]

From my understanding, it is possible to have a non-null safe code and dependencies in the null safe package (like it is already in freezed or bdd_widget_test packages). In that case, there will be no sound null safety (and no fancy blue null safety badge on pub.dev), but in general, it should work. The good news is that i69n is a code generation package, hence your users will already benefit from null safety while you're waiting till all package dependencies migrate to sound null safety.

[Tomucha]

I guess so - the cleanest way would be to separate i69n_runtime and i69n_generator. As a power user of my library - what do you think about that? Should I go in that direction? Now would be a great time, we need to bump up the major version.

[olexale]

Usually, code generation packages are split into generator and annotations parts when there are some annotations that are going to be used in the lib folder and so the dependency must be set in the dependencies section of the pubspec.yaml file. In this case, it's a single dev_dependency hence I don't see a reason to split it up, unless there are some deep implementation details I am not aware of. How would responsibilities be divided between i69n_runtime and i69n_generator?

My proposition would be to publish a version with updated dependencies as this unblocks so many projects and your users would not need to override dependencies in their projects. Moreover, it is generating a null safe code, and I think that was the goal. When all the dependencies of the packages will be updated I propose to push a new version with the real sound null safety.

[Tomucha]

Ok then, I'll release it this weekend. I think you overlooked that the generated Dart files import bit of i69n code (pluralization), hence my temptation to split it into two packages. However, it look like I'm the only one bothered by it for now, so - maybe later.

[Tomucha]

I've just release it as a "prerelease", which should just fine for anyone who is eager to switch to null safety:

https://pub.dev/packages/i69n/versions/2.0.0-nullsafety.1

But as I expected, pub tool doesn't like it at all:

* This package is opting into null-safety, but a dependency or file is not.

  package:build_config is not opted into null safety in its pubspec.yaml:
    ╷
  7 │   sdk: '>=2.11.99 <3.0.0'
    │        ^^^^^^^^^^^^^^^^^^
    ╵

  Note that by publishing with non-migrated dependencies your package may be
  broken at any time if one of your dependencies migrates without a breaking 
  change release. 

  We highly recommend that you wait until all of your dependencies have been 
  migrated before publishing.

I hope it does what you need.

[Tomucha]

.... huge thanks!