Dart introduced Sound null safety with version 2.12, so we've recently been very busy making sure all our stuff supports it. That also means ensuring that all of our underlying dependencies are ready for Null safety too. In most cases we're using popular libraries that are actively maintained, so they've already made the shift. But there are a few things we use that haven't.
So we should just fork the code, make the fix, and move on with our version?
CC BY 2.0 image by i_yudai
Not so fast... forking without even trying to work with the upstream developer is just rude. So we've established a three-step process:
1. Raise an issue on the upstream repo
This lets the maintainer know that there's demand for a change. They may already have plans to do it, and an issue might be the nudge that they need. Or perhaps they're swamped with other work, in which case they can hang out the help needed label.
The best case here is that the upstream maintainer quickly responds with their own change to the code, and publishes it to pub.dev.
Worst case, there's no response at all, so after allowing a little while for a response, it's time to move on to:
2. Submit a pull request to the upstream repo with the desired changes
This will of course close the issue raised at #1, and now we're asking the maintainer to review and merge rather than start from scratch, so most of the work has been done for them.
The best case here is that the pull request is quickly merged, and the resulting package is updated on [pub.dev](https://pub.dev).
Again the worst case is no response at all, so after waiting another little while, it's time to move on to:
3. Fork the repo and publish a variant
The work on the code is already done from #2, so all that's needed is to come up with a variant name, clean up some metadata, and publish.
But now we have another dependency that we're maintaining rather than just contributing to, which isn't ideal.
