Neat!

Can you try adding a migration for this?
https://github.com/flutter/flutter/tree/main/packages/flutter_tools/lib/src/migrations
https://github.com/flutter/flutter/tree/main/packages/flutter_tools/lib/src/ios/migrations
https://github.com/flutter/flutter/wiki/Flutter-migrate

That way (a) existing Flutter projects will get the benefit too, (b) the divergence between Flutter projects created at different times can be reduced.

Thanks for taking a look and for these links :)

Even though I consider myself a fairly experienced Flutter developer, I have never used flutter migrate on the CLI 😅 Maybe an IDE did some of it for me, but I can't recall. I feel like flutter migrate is not advertised enough - which is a pity, because it looks nice.

The migration sounds like a good idea, but I don't think it's worth it for this change. After all, it's a very minor change and I'm pretty sure the performance benefit is negligible. People who'll get the warning will Google it and replace the default, eager clean task declaration with a lazy one.

That said, if you think it's worth adding this anyway, I'll be happy to dive in and write the migration when I find some free time :)

Even though I consider myself a fairly experienced Flutter developer, I have never used flutter migrate on the CLI Maybe an IDE did some of it for me, but I can't recall. I feel like flutter migrate is not advertised enough - which is a pity, because it looks nice.

Yeah, this appears to be an entirely separate system from flutter migrate. (Which itself apparently no longer exists? Try flutter migrate --help and it says it can't find the command.)

If you take one of those existing migration classes and look at where it's used, you find that the migrations are applied as basically the first step of flutter run or flutter build. For example, the buildLinux function has this near the top:

  final List<ProjectMigrator> migrators = <ProjectMigrator>[
    CmakeCustomCommandMigration(linuxProject, globals.logger),
  ];

  final ProjectMigration migration = ProjectMigration(migrators);
  migration.run();

before it goes on to call _runCmake and _runBuild, and that buildLinux function is in turn called from flutter build linux and flutter run for a Linux target.

So this system doesn't need any advertising; it's already integrated into people's normal workflows.

The migration sounds like a good idea, but I don't think it's worth it for this change. After all, it's a very minor change and I'm pretty sure the performance benefit is negligible. People who'll get the warning will Google it and replace the default, eager clean task declaration with a lazy one.

Everyone will get the warning when they upgrade to Gradle 8+, right? Everyone who's building for Android, anyway.

Many Flutter developers will make that upgrade themselves after Gradle 8 reaches a stable release. And then in a few years everyone will make that upgrade who hasn't already, with the successor to #122376 when some Gradle 8+ version is needed for Java 21.

That's a lot of people who can be saved the effort of spotting this warning, figuring out what it's talking about, locating the fix, and then applying it and convincing themselves it was correct and didn't break anything. (Especially as many of those developers will know very little about Gradle — I suspect that even most people writing native Android apps try to avoid thinking about Gradle much, and all the more so for people working mainly in Flutter.)

So if you're up for taking the understanding you've already acquired of what this warning is about, and spending a bit of time to write and test an automated migration that encodes that understanding, then I think that would be a quite useful thing to do.

It looks like this would also be the pioneering example of a migration for Android builds — all the other platforms have one or more (and iOS is in the lead with ten), but not Android. Fortunately I think that part will be straightforward, just adding a few lines at the top of buildGradleApp similar to the code I quoted above.

Thank you very much for this thorough explanation @gnprice. I agree with this - let's spare people some Gradle warnings :)

I'll add the migration code to this PR when I find some free time (in a few days).

Great!

If you find you have any questions about how that migration system works, I recommend you go to the tools channel in Discord and ping jmagman there. She's the expert on this system, and I've seen her several times recently recommend people use it for various changes.

Hi @gnprice, I added a migrator :) I'll be happy if you review it!

Would also be great to have a review from someone who's worked with this migration system. @jmagman, tagging you in as the expert, but please feel free to pass it off to someone else.

Thanks a lot for the review @gnprice! I addressed all the things you mentioned.

@reidbaker can you add the right person to review?

Uh, Mac web_tool_tests are failing and from looking at the logs, I can't figure out why.

EDIT 1: Looks like it's a known issue #123018

EDIT 2: Works after rebase

The gradle parts look good to me that said I a have not yet written a migration. Pinging @camsim99 to see if they have any migration based input.

I don't have any experience writing migrators, so I would defer to you @reidbaker.