State of imagemin 2023-04

[webketje]

After scanning issues & playing around a bit with:

• imagemin-pnquant & pngquant-bin
• imagemin-webp & webp-bin
• bin-wrapper & bin-build

It appears to me that most of the GH issues fall into one of these categories:

1. Outdated dependencies causing security warnings and requiring users to add yarn resolutions or npm overrides.
2. OS-specific installation or build failures, often triggered during npm install due to the *-bin packages doing postinstalls.
3. Requests to be able to use locally installed binaries

Of course there is also the issue of the bundled binaries not being up-to-date, and sometimes even different from the bundled source tar (pngquant-bin includes pngquant 2.2.12 as source and pngquant 2.2.16 pre-built on Linux). And the issue of many micro-dependencies stifling innovation on the end-user packages (imagemin-pngquant -> pngquant-bin -> bin-wrapper -> bin-build etc)

IMO the best way forward is:

1. Not depending on packages outside of the imagemin organization that appear to be abandoned (although their repo's are not archived [yet], looking at bin-wrapper, bin-check bin-build & other deps formerly managed by kevva).
2. Not doing automatic post-installs which default to fetching a dependency over the network. Some of the issues:
   • They can be disabled using --ignore-scripts
   • They can fail due to DNS issues or network configurations with whitelists where the source URL's are not allowed
   • They allow no flexibility in embedding the *-bin packages in other packages (ie exposing some kind of minimal JS API)
   • The download URL could be made to point to a malicious executable (unlikely but still)
3. Defaulting to using the binary in PATH when available, and allowing a configuration option (eg executablePath) to override it. If both fail, then, and only then fetch binaries from remote (allowing a custom URL too for mirrors) and build from source as last resort. This partially moves the burden of maintaining binaries for every distro in the imagemin-* repo's. Yes, there could be incompatibilities in the version locally installed and the version tested against in the imagemin-* repo's. Still this can easily be solved by logging the version and a warning if compatibility may be partially compromised