Add a rubber stamp indicating if a package is compliant with dart 2 or 1

[fmatosqg]

With strong mode and optional new, both forward and backward compatibility of code are not trivial for developers who search for packages.

Please add

• a filter in search
• a clear indication of whether a package can be compiled to either dart 1, 2 or both

so people can make informed decisions while choosing a library.

I'd suggest that the package publisher decides what information to put in. Some sort of linter / analysis could help, but anything now is better than perfect later.

With Dart 2 and strong mode being planned as mandatory for flutter and already rolling in, friction is already showing up.

[isoos]

@fmatosqg: Could you highlight some examples where an old package is causing problem for a new codebase?

[fmatosqg]

Here's a couple of open issues, related to dart + flutter packages, all of those contain native code but I can't be sure if they all present the same problem.

1. Dart 2 compatibility issue / type '_Future' is not a subtype of type 'FutureOr<Null>' roughike/flutter_facebook_login#12
2. Dart 2 Compatibility issue: 'Future<dynamic>' is not a subtype of type 'Future<bool>' mongo-dart/mongo_dart#124
3. Compatibility with Dart 2.0 mode dotintent/FlutterBleLib#18
4. Confusing error message: type '_Future' is not a subtype of type 'Future<bool>'  flutter/flutter#15654

the last one is actually coming from flutter_blue library not being compatible with Dart 2, which I was already aware. It's a gem because the first 3 issues reference it.

As usual the fix is using analyzer in ways that it can tell you with static analysis that something has 100% chance of failing at runtime. Why the compiler and runtime can't agree still puzzles me.

A special pain point is the MethodChannel.invokeMethod which was encouraged to work without casts that now are necessary. I believe that most if not all flutter plugins (packages that implement a bridge to run native code) use that method in one shape or another, the question here is whether they make casts in a Dart 2.0 compatible way. BTW this particular thing can be caught by analyzer.

[fmatosqg]

Here's a more complete user experience moving from dart 1 to dart 2, with official feedback on why problems happen and how to mitigate.

flutter/flutter#14921 -> I recommend jumping to the first comment from @rfuhrer on 1/March/2018.

That issue is fixed and closed but I expect most packages to go through something similar.

[mit-mit]

@isoos could we solve this simply by 'penalizing' in the score packages that don't pass Dart 2 analysis?

[isoos]

could we solve this simply by 'penalizing' in the score packages that don't pass Dart 2 analysis?

@mit-mit: we could, e.g. dart-lang/pana#312 is roughly along that line. However, it will send the message: "The way forward is Dart2, update your package to be compatible or else your score will be bad.", and we may consider doing that only after Dart 2 gets released?

[fmatosqg]

A score being a proxy for Dart 2 support may not be the best way. If I'm about to pick up a pure dart (non-flutter) component for my flutter business logic I'll have to wonder if that package has low rating because it's "bad" or because I'll have run time errors. I can probably get by with a "bad" package but runtime errors will bring my app to its knees. Updates to that package will be likely to bring even more runtime surprises.

I'll also restate the obvious: even if a developer can fix a bug in 5 seconds the users will still have to wait for a) apple approval, usually ranging from 12h to 24h and b) the new version trickling down to MOST users, which on apple happens within a few days and in android may take a week. And that's still MOST users, we never get 100% updates in neither.

This is the main reason I try to encourage different practices for mobile compared to other faster-cycle parts of a tech solution.

[mit-mit]

@fmatosqg thanks, great notes. I fully understand the run-time issues part. However, not really sure how to resolve that. Even if we added a Dart 2 'badge', that would have to be based on static analysis, which would thus not capture the potential run-time errors!? Or were you thinking of a Dart 2 flag that the author of the package would maintain to 'declare' when they are done upgrading the package?

[zoechi]

@fmatosqg

A score being a proxy for Dart 2 support may not be the best way.

Dart 2 will be the default soon, with or without Flutter. It's just that Flutter pushes a bit harder for Dart than the other platforms.
I wouldn't expect much packages to work well (or at all) in Dart 2 that are not explicitly designed and tested for Dart 2 (and reflect that in the Dart SDK constraint)

[fmatosqg]

My goal here is allowing informed decisions when choosing a library. If we can only see the final score we go back to scores as proxys for what I'd like to know. Transparency usually wins, and if we allow devs to see how many points are deducted because of analyzer output I'd say it's a big win. Light suggestion: deduct points per amount of "wrong lines" (or percentage of overall package?). Upside: there's an incentive for incrementally improve repo. Downside: get everyone/decision makers to agree policy on points, fairness etc, and possibly harder to implement.

@mit-mit my light original suggestion would be as you understood, allowing the author flag a boolean -> badge saying his intent is to maintain a dart 2 package. It was really a conversation starter. Upside: minimal work for maintainers of this repo (my guess), and it would catch mainly unmaintained packages that would never have the trouble to set the flag. Downside: booleans are all or nothing.

@zoechi I'd like people to use both dart and flutter constraints, that rarely happens but I think it's a different battle. I'd like both to be mandatory for flutter plugins, and more concerned at spreading it as a good practice than having everyone put the right numbers from day one.

[isoos]

Light suggestion: deduct points per amount of "wrong lines" (or percentage of overall package?)

This is already done as part of pana: certain kinds of errors and warnings are reducing the health score as a percent of the total, while typically hints reduce it 'per line' (e.g. a big repo will not really notice a reduction on that).

Maybe we could tune up the penalties here and there, but I'd do that only with some specific examples at hand.

[isoos]

@fmatosqg: Could you please comment on how you find the recent changes about visibility and issue indication?

Unfortunately, the packages you have mentioned have Dart 2 runtime failures that are not yet covered with dartanalyzer, and we do not run the code directly (yet).