There were requests from multiple users that
they use squoosh for compression but for each
iteration side settings resets to default
causing issues and there is no way to save and
import side settings.
There will be two buttons adjacent to copy-over
save side settings : This will save side encoder
and latest settings to localstorage of browser
import side settings : This will import side encoder
and latest settings from localstorage of browser and
replace the existing settings
Also if there are saved settings in locaStorage then
whenever user loads the app it will take that settings
and populate the side so user do not have to repeatedly
enter same settings for similar compression operation
subject to user has saved side settings
Update:1
Import settings button remains disabled if there
is nothing to import
Whenever the side setting is saved there will be
event fired and eventually listened to enable import
button
All 2 operations show notifications now
Import notification has undo option
Update : 2
Changed Icon SVGs
There were requests from multiple users that
they use squoosh for compression but for each
iteration side settings resets to default
causing issues and there is no way to save and
import side settings.
There will be two buttons adjacent to copy-over
save side settings : This will save side encoder
and latest settings to localstorage of browser
import side settings : This will import side encoder
and latest settings from localstorage of browser and
replace the existing settings
Also if there are saved settings in locaStorage then
whenever user loads the app it will take that settings
and populate the side so user do not have to repeatedly
enter same settings for similar compression operation
subject to user has saved side settings
Update:1
Import settings button remains disabled if there
is nothing to import
Whenever the side setting is saved there will be
event fired and eventually listened to enable import
button
All 2 operations show notifications now
Import notification has undo option
Sample data had size label showing wrong memory units
13k instead of 13KB
2.8mb instead of 2.8MB
small b corresponds to bits and this would change entire
meaning of file so fixed it
* Update libavif and AOM (3.6) for improved compression and speed
* Minor fixes to package-lock done by NPM, also trigger new build
* Update AVIF version
---------
Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
Unfortunately, due to a few people leaving the team, and staffing issues resulting from the current economic climate (ugh), I'm deprecating the CLI and libsquoosh parts of Squoosh. The web app will continue to be supported and improved. I know that sucks, but there simply isn't the time & people to work on this. If anyone from the community wants to fork it, you have my blessing.
* Expose type declarations in libSquoosh npm package
* Add comment on why we remove the tsbuildinfo
* Fix PreprocessOptions type
Resize should require at least one of the width, height.
The other options are optional for all preprocessors
* Update libSquoosh README to reflect encode changes
I also removed requiring `await image.decoded` call before calling
preprocess or encode since they decode the image before the operation
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
