Issue with no co-existence of nullOK and maybeOf across channels. #74519
Comments
|
I'm also failing to understand how this transition is going to happen without a lot of pain. This week we were suddenly unable to run our project on the dev channel due a dependency relying on a So far we've been able to work around this by having an entry in |
|
As an additional primer to anybody else dropping by in this issue. In old SDK and well still current stable, this for example: ScaffoldState state1 = Scaffold.of(context);
ScaffoldState state2 = Scaffold.of(context, nullOk: true);Is the way Understandably this is messy and not doable in NNBD if you want to have a "clean" of method that returns a non nullable type. So in NNBD version you instead use: ScaffoldState state1 = Scaffold.of(context);
ScaffoldState? state2 = Scaffold.maybeOf(context);The difference in return types probably makes it problematic to keep If it is a problem, then why was The current NNBD static ScaffoldState? maybeOf(BuildContext context) {
assert(context != null);
return context.findAncestorStateOfType<ScaffoldState>();
}Then with a deprecation warning "Hey Still possible with a hot fix to introduce |
|
We do understand your complaint with this breaking change, and we're sorry that this is making things difficult for you and others. When designing this change, we considered a number of different alternatives, and in the end decided that having a more ergonomic API long term was more important than the short term pain that a migration would induce. We wanted to keep the We don't provide any guarantee that you will be able to build apps on multiple branches with the same source code. You might be able to get that to work most of the time, but we only provide assurances that code will work on one branch at a time, since API differences between branches (like this one) make some code changes necessary. As mentioned in the compatibility policy, we do try and minimize breaking changes, but to maintain good ergonomics they are a necessary part of the evolution of an API. This change doesn't fall under the deprecation policy, since it is not a deprecation, but a breaking change. There is a migration guide for this change available here. Again, we're sorry for the breakage. |
|
@gspencergoog I get all that, and thanks for feeling with us regarding this quite challenging breaking change. I still think it would have been (and would even still be) possible and better to introduce That As far as I can see there is nothing in As it is now, devs using Why not a migration path with
|
|
We currently don't use cherrypicks for things other than security issues or "halt-and-catch-fire" situations, in order to preserve the stability of the stable channel. Maybe we should reconsider that, but that's the current policy. |
|
My point was actually that with some planning and foresight, that there would not have been any need to cherry pick anything, maybeOf could just have been introduced as a planned parallel API to nullOK in previous stable 1.22 or even already in 1.20, in order to facilitate this problematic transition. |
|
Yes, true, and if we had decided to make this change before the previous stable was released, we would have done exactly as you suggest, but we didn't make the decision on this change until a month after the most recent stable was released. |
|
Thanks for all the info Greg, and I understand it is a tricky and unfortunate situation. I and few others that suffer with this issue just work around it for now. Mostly by for any non null-safe package that has this issue, we make our own fork and change the nullOK to the maybeOf variant, let the rest be as is and use the fork until this blows over and the package is eventually fixed too. In some cases a few nested deps also have to be to dealt with, but its all doable just a bit of a hassle. With this approach we obviously still can't use stable channel with the same code base, but perhaps that's OK too considering the timeline. Dev channel is certainly "stable" enough to develop in (probably even to release with if you have to) until all this lands in stable. No worries, I think we got it covered. :) Looking forward to 3.3 (= 3+3=6 platforms in stable? I hope so! 😃 ) |
|
Since nothing is likely to change or be resolved before the next stable release, I was about to close this issue since it won't be resolved. However, if it is kept open until it is solved by |
|
Wait what is this black magic https://github.com/flutter/flutter/pull/74866/commits did @Piinks just fix it all?? 🤯 On master now when I use a package with a dep that uses old "nullOK", it suddenly now builds just fine!? If I drill into to look at the package it for sure shows code that should not build (and did not before), because it uses removed nullOK and it is not resolved to anything newer that would use maybeOf. Also if look at the API in question in the Flutter SDK on used master version, it as excepted has no nullOK API, so it should indeed bomb, yet it builds! What!? Magic? Still nice save... or am I dreaming? What is this magical "fix_data.yaml" file? Some kind of dark art magical secret sauce build pre-processor that changes and migrates code before it is built? It's usage and syntax seems to indicate that. Could not find any info on it, just this: TODO(Piinks): Add link to public user guide when available.Although mostly I'm happy it all seems to magically work now! Thanks and super nice work @Piinks ! 💙 Unless I'm really dreaming or seeing things of course... 😃 |
|
The fix #74866 has now landed on channels, beta, dev and master. I tested by building an app with a few package dependencies that use By setting the dependency constraint for those dependencies to a min version or higher, that build and runs OK on stable, I was able to build the same project and code using same version constraints on:
Previously it was impossible to build an app with the same package dependencies on all channels. This issue is resolved via #74866. Thanks @Piinks and @gspencergoog 💙 ! |
|
Tested with
I still get the same error with the library |
|
@apoleo88 so it appears now, so it seems like my joy was premature. What does work though, at least for your mentioned flutter_svg issue, if that is all you need to work, is to set it's version constraint to: flutter_svg: ^0.19.1 Then you will get version 0.19.1 on stable, but on channels beta and higher you will get version 0.19.2 or higher, that has Flutter SDK version constraint that is higher than the stable version and its implementation actually uses , |
Thanks for the follow up. I tried with last beta/master using |
|
@apoleo88 You probably already tried, but in case did not, make sure to run: If you do a run: If you don't intended to build for stable channel at all, then you can of course set the flutter_svg version to ^0.19.2+1 in your pubspec.yaml file, but that won't build on stable. With version ^0.19.1 you can get the last resolvable version that builds on stable with This web screenshot is built with latest beta channel and flutter_svg: ^0.19.1 in pubspec.yaml (but resolved to 0.19.2+1) , the shown image is an SVG file: If you still have problems getting the correct flutter_svg version resolved, you could try to invalidate the cahces and restart the IDE (In IJ/AS: File -> Invalidate Caches / Restart ...), sometimes that can help too. |
|
Unfortunatly, nothing of that worked, the version of the library is indeed correct and I cleaned multiple time, did pub get and upgrade. I had to surrender and downgrad to the beta. |
|
We're still having this issue. We're using bits_dojo package, which imports the svg package. We tryied to do a dependancy_override to 19.2.0+1 but it just kept complaining about nullOk and would not build. |
|
same issue as @esDotDev on latest master flutter doctor -v |
|
I am closing this issue, it is solved a few stables releases back already. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Uh oh!
There was an error while loading. Please reload this page.
Removal of
nullOK- Issue with Severe Breaking ChangeI'm having severe issues and hence also objections to the removal of nullOK. I am referring to these changes:
nullOkparameter fromNavigator.ofand addNavigator.maybeOf#70726nullOkinMediaQuery.of#68736My main questions (and objections) are:
How do we for the moment write a single code base that needs to use past 'nullOK' APIs and now the new 'maybeOf' of APIs, that works and runs with the same codebase on at least stable, beta and dev channels, preferably also on master channel, but up to dev would be OK so we can work on Windows targets too.
How is this going to be introduced into the stable channel without it being a VERY severe breaking change?
If you introduce it into stable, by just overnight removing "nullOK", how does that not go against the Flutter compatibility policy?
Basically when you finally introduce
maybeOfinto stable, thennullOKshould be available also for 1 year at least. If that will be the case, then fine. However, why cannullOKthen also not be available on beta, dev and master channels, at least untilmaybeOfis introduced in stable, so we can do a well managed switch?https://flutter.dev/docs/resources/compatibility
I know this is a part of this design doc, but I'm concerned about its implementation and current difficulties its transition is causing, and that it at least based on what is available on stable/dev/master looks like it will be introduced into stable as an overnight breaking change that does not adhere to the above policy regarding providing a more controlled and manageable deprecation.
Mediation possibility?
Perhaps another way to handle and avoid the current catch 22 situation, would have been to also introduce the new
maybeOfAPI in parallel tonullOKas a hotfix to the stable channel to facility code that needs it and needs to work on channels up to at least channel dev, with a single code base. Seems likemaybeOfAPI could very well co-exist in some form on stable in the none null-safety SDK, where as the same can probably not be said about thenullOKAPI variant co-existing with the Flutter null-safe SDK.At the moment, our only recourse for managing the current situation is to dump and not use/support the Flutter stable channel at all in our projects.
The text was updated successfully, but these errors were encountered: