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

[kelson42]

Is imagemin totally abandonned?

[webketje]

It is. It could only be realistically resuscitated (that is, without becoming a maintenance nightmare) as a light JS interface that depends on pre-installed binaries available in $PATH or with a custom executable path. The responsibility of installing compatible versions of these binaries would fall back onto the user (diminishing the value of imagemin).

Moreover some of the binaries depended upon are themselves no longer maintained/ superseded by newer initiatives (they still work though). For example Sharp has feature parity with all of mozjpeg, jpegoptim, jpegtran, pngquant, pngcrush and gifsicle.

[kelson42]

@webketje Thank you very much, I was not aware that sharp was able to replace imagemin.