chore(dev workflow): add pre-commit hook to compress staged images

[moonmeister]

Description

Adds pre-commit hook to the repo using existing husky config to compress jpg,png,gif images that have been added to the repository.

This package uses plugins for compression that are lossless. This is good for quality but means images can remain quite large.

https://web.dev/use-imagemin-to-compress-images - for list of lossless vs lossy plugins.

Related Issues

#13699

[DSchau]

@moonmeister I like the idea of this--but I'm also a little concerned about this perhaps introducing failures in the commit process. We've seen a fair amount of failures with e.g. sharp, so we don't want to put any other barriers in place or introduce potential failure points.

I think I'd rather we treat this as something we automate (e.g. perhaps we use a Github action to optimize the images in a PR with a commit?), or something that's done on an ad hoc/reactionary basis, just to reduce the potential for failure.

What do you think?

[moonmeister]

@DSchau Hadn't thought of doing it that way...I think it introduces a couple side effects that might be more troublesome. The primary goal of this is to is to reduce repo size. If we allow people to commit then ask a bot to checkout, compress, and re-commit images then we're duplicating the copies of images in history and significantly increasing repo size. This could be over come if the bot were to rewrite history with the new version of the image. But this seems more fragile and potentially dangerous then doing it with a commit hook. This said I am inexperienced with this kind of git operation, maybe it'd be fine.

Also, we're already using SVGO to optimize SVGs in commit hooks, this is effectively the same thing but for JPG/PNG/GIF. In fact, the tool I'm using includes SVGO for SVGs but I haven't included them in the husky file pattern matchers as our config is different.

All this said, you make a good point, this needs to be robust and not prohibit contributions in anyway. Maybe we figure out some ways to test this and see if it causes any troubles. Thoughts here? The one thing I noticed on REALLY large images(2+MB) it can take a while with little to indicate what's happening.

[wardpeet]

I agree with @DSchau, also imagemin needs some dependencies like libpng, libjpg, .... How do we feel about adding a lint rule on ci so we get a notice of this? Or maybe we shouldn't bother and just minify everything once in a while.

[sidharthachatterjee]

Agree with @wardpeet and @DSchau here that it would be best to avoid problematic hooks in the commit flow

Closing this for now but definitely think this could be a scheduled GitHub Action perhaps

Thank you for the work though, Alex! 🥇