Depends on the cleanup no? I mean, if it's just obselete version of one library, and the ensuing lockfile change, it doesn't really matter. If iys upgrading to a new language/framework however, yes, please do so.
I'm not saying cleaning up separately isn't warranted.
But it isn't always legacy that needs cleaning up.
It can also be mess created very recently by active team members.
So on the one hand, a separate PR for the cleaning up is warranted, but since it isn't being matched with a separate PR for introducing the mess, the double standard is magnified by introducing more book-keeping for those who clean up after others.
For that reason, when working with messy people who are not held accountable, I usually clean up in separate commits in a PR. This way, when looking at the blame for the logical changes that I introduced, and when reviewing, this is separate from the cleanup.
But it isn't always legacy that needs cleaning up.
It can also be mess created very recently by active team members.
So on the one hand, a separate PR for the cleaning up is warranted, but since it isn't being matched with a separate PR for introducing the mess, the double standard is magnified by introducing more book-keeping for those who clean up after others.
For that reason, when working with messy people who are not held accountable, I usually clean up in separate commits in a PR. This way, when looking at the blame for the logical changes that I introduced, and when reviewing, this is separate from the cleanup.