Instantiating and using multiple image pools is not intended and can
lead to memory problems. Instead, users should use a single pool and
reuse that pool across all image processing. Therefore, let's add
a warning in the README to specify call this out and avoid users
of running into issues.
Relates to #1065
By upgrading to version 7, we now ensure that NPM/Yarn will run
the `prepare` script and appropriately install Husky. This also
migrates us to the `pre-commit` hook as a separate file, rather
than as part of the `package.json` definition.
This pulls in TypeScript 4.4, which ships ResizeObserver in the DOM
types, as well as sets caught errors to `unknown`, requiring explicit
checks for `AbortError`.
We already await the promises that we set on the `encodedWith` instead of setting already
resolved promises to `encodedWith` we can set the resolved values
So, the users can use like
`const { mozjpeg: { binary } } = await image.encode({ mozjpeg })` or
they can first run
`await image.encode({ mozjpeg })` and then
`image.encodedWith.mozjpeg.binary`
Before this, there were one way to use the API:
call `await image.encode({ mozjpeg: {} })`
then use `encodedWith` by asserting that `mozjpeg` property exists on it
After adding return value to encode, people
will be able to use it like
`const { mozjpeg } = await image.encode({ mozjpeg: {} });`
which provides better type safety
Instead of returning `any` we're now returning the whole object.
Still from typing perspective, the API is not that
great since we don't have any type relation
between `encode` calls and `encodedWith` property. Maybe we can think about
returning directly from `encode` call
with the returned object having properties
that is supplied in `encode` calls
