Suggested improvements to "dart fix" UI

[Hixie]

I used "dart fix" for the first time today. It's fantastic!

I would propose two changes to the UI:

1. when describing the changes, rather than "UNDEFINED_NAMED_PARAMETER - 1 fix" or similar, it would be nice to say something like "migrated from 'resizeToAvoidBottomPadding' to 'resizeToAvoidBottomInset'" or some such, to give some context about the change.
2. For the dry run, it would be really useful to have it describe what it wants to do in the form of a patch file.

[bwilkerson]

@devoncarew

I suspect that the first would require some additional support from server, and it appears to be specific to the data-driven fix support. I'll take a better look at what would be involved when I'm done adding the required test support.

The second can be done without additional work in server.

[devoncarew]

For the first item, we could do something like:

  UNDEFINED_NAMED_PARAMETER - 1 fix
  Migrate from the deprecated 'resizeToAvoidBottomPadding' API to the new 'resizeToAvoidBottomInset' API.

i.e., use a line below the change summary to provide brief context for the change.

[devoncarew]

For this:

For the dry run, it would be really useful to have it describe what it wants to do in the form of a patch file.

We did have discussions about the best preview format to use for changes. There were concerns about producing output that was too detailed - just having a lot of information scrolling by.

A diff would however remove any mystery about the changes the tool would make.

It may be worth prototyping the output for a few different sets of changes in a gist or something.

[bwilkerson]

Another possibility to consider, if there's enough demand for it, would be something like a --patch=filePath option that would cause the tool to write an actual patch file.

[Hixie]

I could see having a --summary mode that says what APIs were migrated, and a --patch mode that generates the actual patch. I have to say though, as an engineer, at the end of the day, what I care about is the patch. In my case, what I did was make sure my git repo was clean, apply the migration, then look at the diff, because that's all I actually cared about at the end of the day. I don't think we're doing engineers any favours by hiding the patch as being too detailed -- it's exactly the detail we need.

[Hixie]

  UNDEFINED_NAMED_PARAMETER - 1 fix
  Migrate from the deprecated 'resizeToAvoidBottomPadding' API to the new 'resizeToAvoidBottomInset' API.

I would skip the first of those two lines. It's not really meaningful to me. The second line is super useful.

[bwilkerson]

So I think what's being requested here is

• for the default output to be a patch file,
• for a --summary flag that produces a summary (which is currently the default output), and
• for the summary output to report the fixes that were applied rather than the diagnostics that were fixed.

Does that sound right?

[Hixie]

That would be great!