Generate data-driven fixes

[mosuem]

Just an idea:

With the dart_apitool, we can say what changed from one API to another. Could we use this information to generate data-driven fixes, allowing the user to run dart fix to update to the newer API?

What would be needed to do this?

cc @devoncarew

[devmil]

Hi @mosuem, this is an interesting idea.
At least for some of the changes a data driven fix could be generated.
Of course this has limitations as adaptions to a new API might be more complex (so no data-driven fix possible) or wrongly detected (dart_apitool as to guess renames which can be wrong in a set of multiple changes)
At least dart_apitool could point out potential "simple" API changes that don't have a data driven fix available.

[mosuem]

Yes, a generated list of fixes would have to be manually approved. But a list of proposed fixes would go a long way in making API changes go more smoothly.

Also cc @jonasfj who I was told has experience with data-driven fixes (and of course API changes 😉)

[mosuem]

Another thing we have to think about is whether the fix should be for users of the older version of a package, to update deprecated elements to the new API, or for users of the newer version to update now deleted elements to the new API. Or both.

[jonasfj]

I'm only a user of data-driven fixes, @keertip is the mastermind who worked in data-driven fixes.

I'm not sure I can see how data-driven fixes could be derived from API changes, but maybe I'm missing something.

There is probably some value in validating that breaking changes / deprecations are covered by data-driven fixes. And it could probably serve as a mechanism to encourage more people to write data-drive fixes.

[keertip]

Thanks for the suggestion, this is an interesting idea. It would definitely help in encouraging package authors to use data-driven fixes with API changes.

I am not familiar with the dart_apitool, and the information that it generates, so really can't speak to whether the information from dart_apitool is sufficient and complete enough to be translated into a data-driven fix.

Also, as mentioned before, the correctness of the fixes generated depends on the correctness of the dart_apitool.

/cc @bwilkerson

[bwilkerson]

I'm not sure I can see how data-driven fixes could be derived from API changes ...

I agree. Knowing that a method m1 was removed and a method m2 was added isn't sufficient to tell us that m2 is the replacement for m1.

I really like the idea of making it easier to add data-driven fixes, but I have a different proposal for how to do that. I realized that I'd never gotten around to adding an issue for the idea, so I just did now: dart-lang/sdk#60244.

[devmil]

I'm not sure I can see how data-driven fixes could be derived from API changes ...

I agree. Knowing that a method m1 was removed and a method m2 was added isn't sufficient to tell us that m2 is the replacement for m1.

I really like the idea of making it easier to add data-driven fixes, but I have a different proposal for how to do that. I realized that I'd never gotten around to adding an issue for the idea, so I just did now: dart-lang/sdk#60244.

ah, nice. So solving this issue while it is created.

[mosuem]

I agree. Knowing that a method m1 was removed and a method m2 was added isn't sufficient to tell us that m2 is the replacement for m1.

Yes, there are cases (maybe even most?) where that is not possible. But there are some where it might be - for example, when changing a positional parameter to a named one. A suggested data driven fix might encourage usage of those for package authors.

[bwilkerson]

There are definitely places where we could make an educated guess and be right a large percentage of the time. It won't ever be perfect, but that doesn't mean that it isn't worth doing.