No viable alternative to imagemin - applying for maintainer privileges about imagemin

[sindresorhus]

Invited you 👍

[sindresorhus]

last thing: do you have a preferred Way of Working? Contributor's guide with maintainer section somewhere? Should I create branches and add you/someone as reviewer? Who pubs to NPM? I know you're super-busy, so I'm not sure you wish to be pinged for imagemin-related stuff. Perhaps you can point me to another active maintainer?

I don't have a guide. Just the normal best practices. New features should have tests. It's good to get a review on larger changes. Smaller changes can land directly on main. Feel free to add me as a reviewer. There are no other active maintainers. It's easy to get burnt out on this project. If you have someone else that would be interested in reviewing your changes, that would be great too. You are free to publish new releases on npm.

[sindresorhus]

Exploring making the -bin libraries optional peerDependencies of the imagemin- plugins and making relying on the OS-installed dependencies the default (eg for using webp on Debian distro's, try calling webp first, which will fail if it is not in $PATH).

There are problems with relying on OS-installed dependencies too, like version incompatibilities.

I would suggest exploring using WASM for some of these as it fixes almost all compatibility problems.

For example, pngquant can be used from WASM: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/imagequant

[Tofandel]

Also if you publish a major, can you make the package cjs compatible with an exports in the package.json, it was recently made esm only and it's unpractical because the main usage of this package is in build tools which don't just don't have good esm support

[webketje]

@Tofandel TBH this was also an issue for metalsmith-imagemin (which I pinned to the latest CJS-compatible imagemin plugins for my fork) as long as you support Node 12. FWIW you can use ESM modules in CJS builds by using dynamic imports starting in Node 13.something. Providing a dual build is definitely outside the scope of my involvement, but I could clarify in the README how to load it in a CJS build.

@sindresorhus last thing: do you have a preferred Way of Working? Contributor's guide with maintainer section somewhere? Should I create branches and add you/someone as reviewer? Who pubs to NPM? I know you're super-busy, so I'm not sure you wish to be pinged for imagemin-related stuff. Perhaps you can point me to another active maintainer? 😄

[Tofandel]

You don't need a dual build but you do need a typescript base or a build step, I did it for @prerenderer by simply giving a cjs.js file which imports the entry of the module

"use strict";
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
const index_1 = __importDefault(require("./index"));
module.exports = index_1.default;

Or before building in ts

import def from './index'

export = def

And then in the package.json remove the type: "module" and add

  "exports": {
    "import": "./dist/index.js",
    "require": "./dist/cjs.js"
  },

Works wonders, as this allows for both require and import in node builds instead of just the import that the type: "module" does

[sindresorhus]

I don't intend to bring back CommonJS support.

[webketje]

@ahmadnassri this thread should be of interest to you

Sindre mentioned

There are no other active maintainers. It's easy to get burnt out on this project. If you have someone else that would be interested in reviewing your changes, that would be great too.

Are you interested? If not I'm going to close this issue since I got invited to the GH org.

[ahmadnassri]

@webketje thanks for the follow up, I don't think I can help with with a larger scope project like imagemin at the moment.