Null Safety

[ryanheise]

Is this being worked on, or may I submit a pull request?

[ryanheise]

Bump. :wave:

This is a really useful project, but by not engaging with a potential contributor, I think it is not fully leveraging what it means to be open source.

I'll go ahead and create a fork supporting null safety and also the more recent Dart 3 because I need it for my project.

@KealJones @greglittlefield-wf @robbecker-wf

[kealjones-wk]

Hi there @ryanheise I am so sorry none of us ever got back to you, we don't really have a process for checking issues. I sincerely didn't even know we had people making issues here, so thanks for tagging us! We actually are already in the process of implementing null safety and getting prepped for dart 3. I don't have a timeline right now, but i know in the upcoming quarter it is a priority.

[ryanheise]

we don't really have a process for checking issues.

Project maintainers can subscribe to all comments made on the repository.

We actually are already in the process of implementing null safety and getting prepped for dart 3. I don't have a timeline right now, but i know in the upcoming quarter it is a priority.

2 years ago when the Dart community made a large scale concerted effort to migrate to null safety (Workiva being an exception), I migrated 3 of my own packages, and then also offered to submit pull requests to 5 other packages that I used and depended on. 4 of them welcomed pull requests. The 5th was a corporate outfit who talked about priorities and timelines for their own team, and assured me they were working on it. Long story short, everyone was getting antsy waiting months and months for anything to happen (because we all have our own market demands and deadlines), despite the fact that it should have been a 1 or 2 day job. I didn't bother waiting for their slow release schedule, and so after 7 days of waiting, I decided to just migrate it myself, and it was a relatively quick 4 hour job.

Obviously what turned out to be the case was that they tied their scheduling of an urgent feature in with their next "major release" along with a whole bunch of other major structural changes including API redesigns and new features. So we had to wait for them to perfect their design choices and do all of their testing for things that had nothing to do with the urgent migration to null safety (I say urgent - this is 2-3 years ago, and it seems Workiva didn't get the memo that it was urgent - which I suppose is possible. I do know that Kevin Moore, a product manager for Dart and Flutter at Google, proactively went around sending the memo to package developers as soon as all of their dependencies had been migrated, so that they would know when they could commence the migration of their own package, but this would have been in the order of most critical packages first.

The point from that fiasco was that it is much better to not tie unrelated changes together, and opt for smaller, more frequent releases. That also puts you in a better position to leverage contributions from the open source community. There is a way of performing the urgent migration to null safety that does not involve bogging down progress on other features. In the first stage, you can do a cheap migration to null safety in a 100% backward compatible way where every typing decision ends up being "nullable by default". The hard work of deciding for each variable whether to then tighten it up by making it nullable can be delayed for a later stage, but at least you have unblocked all the users who need to upgrade to the latest SDK so that they can have access to the latest bug fixes and new features for other packages and dependencies. And even if (like this other corporate outfit) you feel you can't escape it getting tied up with other major features and refactorings that you're working on, the change is small enough that you could theoretically do the migration twice: once for the current stable branch, and then again do an independent migration of the dev branch (I assume you are still using the old SDK so you would have access to Dart's whole program flow analysis tools which make it easier to do it this way.) At the end of it, I would expect a diff between the two branches to not show anything related to null safety if you applied the same philosophy in both cases.

Anyway, I have just done my own migration of this package. I spent around 3 or 4 hours on it. It would have been quicker if I had done this last year but since the upgrade to the latest SDK they have removed the null safety migration tools that could have made this job more efficient (another reason why it is better to act quickly rather than let it lag 2-3 years). I've just gone with my immediate intuitions on whether something should be nullable or non-nullable, opting for non-nullable when in doubt, and since "you're working on it", I don't plan to do anything more than that.