Reme Le Hane I'm not sure if I agree with that. If you go on the homepage it says 'Automated dependency updates' and below that it says 'Dependabot creates pull requests to keep your dependencies secure and up-to-date.' then if you look at the the 'How it works' flow it says 'Dependabot pulls down your dependency files and looks for any outdated or insecure requirements.' then 'If any of your dependencies are out-of-date, Dependabot opens individual pull requests to update each one.' (dependabot.com)
Security is definitely a part of it but I'd say the automated dependency updates are just as important. Maybe it started out with a security focus, but there are now even StackOverflow questions about how to configure it just to do security updates(stackoverflow.com/a/64145646) (apparently you don't even need to configure it in your repo anymore since GitHub acquired it, it just does it automatically for security updates now and I've seen it do this in some of my NodeJS/Javascript repos).
I'm not saying what I wrote above is a replacement or better than Dependabot, it is way too basic. If there was proper Dependabot support I would just use that(fingers crossed it happens soon 😅).
What you said about PRs, the same thing applies to what I wrote above in the action - you need to merge the changes for them to take affect it doesn't auto merge the PR for you it just creates it. You have to make a conscious decision to merge it.
The big difference is it doesn't update things one by one like Dependabot or have the same level of granular settings. If you are worried about the project breaking I think it'd just be a matter of running flutter build apk like I wrote above and it would tell you if you had any issues(then the action would fail, same as if your tests failed - the PR wouldn't even be created).
As far as the IDE plugin goes that actually sounds pretty nice, what are you using Android Studio or Visual Studio Code?
Just curious, what is your reasoning for wanting to automate this, packages are one of the few things that should be managed manually. The risk for breaking changes is pretty high, even in a well-tested application.
The problem is many developers do not understand the purpose or meaning of semantic versioning and I have personally seen breaking changes come out with patch and even build releases, developers rewriting entire API's and publishing as a patch release, and this was not even on pre-V1 releases.
One package, I recall 2.3.3 was working perfect and 2.3.3+1 had a new API. lol.
While in theory this is a good idea, not sure it's something one ever wants to put into practice back in the real world.