nit: long line

This line is only 129 characters long. The consistency on line length recommendations is all over the place (you're not alone, I've seen this comment in other reviews). Is this really more readable?

I don't get why we care about "long" lines. Your IDE wraps and scrolls and you're probably working on a ~27" display anyway (130 characters doesn't look long on a 13" laptop either).

I can't even get the Android Studio column guide feature to work, it always just shows 80 characters no matter what I put in the visual guide field. What decade is this?

I'm all for consistency, but either we should have a linter or we shouldn't enforce it, and should just wrap where it's naturally readable.

I agree, I don't really have anything to go off of here (feel free to ignore nits). I would certainly prefer if we had a standard max line length, probably longer than 80 but I'm not sure how much until we hit the terminal width limit for @zanderso

The framework "hand-formatting" standard is really making this harder than it should be. Not to mention all of our lines are longer than they need to be due to the unnecessary RHS types for locals

Here is the relevant section of the style guide: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#prefer-a-maximum-line-length-of-80-characters. In particular, 'prefer going over if breaking the line would make it less readable, or if it would make the line less consistent with other nearby lines.'

'less readable' is subjective, so at the end of the day, this really means something like, "come to a consensus with the code reviewers."

I would vastly prefer it if we could use dartfmt under packages/flutter_tools with a line limit of say, 100 or so, and just not have these conversations anymore, but I believe that ship has sailed.

I was pointed to this as an example of why we should use dartfmt... It's worth noting that dartfmt never breaks strings, so it would not make this better. In fact it would make this worse because it puts a random newline before the ( and then puts the rest of the line on the next line indented by four:

  void _printDeprecationWarning() {
    if (deprecated) {
      globals.printStatus(
          '$warningMark The "$name" command is deprecated and will be removed in a future version of Flutter.');

My recommendation for formatting this would be:

  void _printDeprecationWarning() {
    if (deprecated) {
      globals.printStatus(
        '$warningMark The "$name" command is deprecated '
        'and will be removed in a future version of Flutter.',
      );

(If you do that, then it happens that dartfmt will keep that output unmodified. But it won't proactively cut the string.)

Can we add a line here that says for modifications required in the host Android or iOS apps, make those modifications in your own wrapper apps that import the Flutter module?

Good idea. I'll open a new PR.