Closes #1059 (or should it stay open to track docs?)

Supported Node versions are now specified in package.json, meaning npm will warn users that install on an unsupported version.

Note that these files are not up to date! A bunch of changes have been published to npm, but they are not present in the repository.

@surma gifsicle will be used not only for animation, it is still used on legacy sites and will be good to compress them too, also animation gifs can be compressed too and it is good

Seems sad to add a whole new API for a temporary Safari bug.

I agree with that 😞

Cool, I'll make a PR for the package.json thing. Ideally, the docs should be updated based on what is set in package.json. I'm not sure if there are plans for a system that facilitates that.

Yeah I was trying to remember if engines in package.json would generate a warning. This SGTM! PRs appreciated :)

My thought process when releasing this was simply that for an experimental program, it was okay to remove support for Node versions that have active security vulnerabilities, and that can very easily be updated to a new version, especially because it gave us some nice perks to be able to use the new import syntax.

I completely agree it should be documented somewhere. In the docs and/or in package.json. If you define it in package.json, npm will warn anyone that tries to install it with an unsupported Node version. I'll happily provide a PR for that :)

I have a use case where I need to know if an input image is compressed with a lossy or lossless algorithm. Figuring this out is easy for codecs like png and jpg which only support one type, but it's not that simple when I want to test a webp or jxl image. Ideally, I would be able to get this information directly from Squoosh.

I have build a draft implementation in Squoosh, and it seems relatively simple to add this. I am detecting lossy/lossless encoding by reading the first two chunks of every image. Please let me know if there's a smarter way to get this info :D The signal would be added to libSquoosh as Image.decoded.lossless: true | false.

Apart from helping me out, I also think this could be very useful for Squoosh itself. Currently, Squoosh will default to encoding any image lossy, even if it's an SVG. With this signal, it should be possible to automatically toggle the lossy/lossless switch in the target encoder, matching the encoding type for the input image, resulting in much better defaults.

Adding a system to change defaults based on the input image seems so complex that it's probably better to let the core team do it (or do you disagree?), but if I can get a green light on this, I'll be happy to implement the signal :)

Yeah, we support all Node version since LTS (so 12, 14, 16), but we do expect the most recent of those respective major releases. Happy to take a PR to update the README accordingly.

(also cheekily cc’ing @atjn if he has opinions on this)

Describe the bug Currently, when I try to run the cli in different node versions, different kind of errors are occurring related to imports.

As far as I understand, support for named exports came to Node at v14.13.0 (Release notes) and we need it. For example, when I run in v14.0.0, I get this error:

import { ImagePool, preprocessors, encoders } from '@squoosh/lib';
                                   ^^^^^^^^
SyntaxError: The requested module '@squoosh/lib' does not provide an export named 'encoders'

I guess there are two possible things we can do:

• Document the Node versions we support (as v14.13.0 for CLI and I don't know for libSquoosh 😅 )
• Update build config to support more node versions and document the ones we support in readme

To Reproduce Steps to reproduce the behavior:

1. Install Node v14.0.0 (via nvm: nvm install v14.0.0)
2. Use Node v14.0.0 (via nvm: nvm use v14.0.0)
3. Install @squoosh-cli globally (via npm install -g @squoosh/cli)
4. Run the CLI (via squoosh-cli)
5. Observe that there is an error related to imports

Expected behavior The import error shouldn't happen (or people should know and not use CLI prior to Node v14.13.0)

Version:

• Node version: 14.0.0
• npm version: 6.14.4

The main problem here is:

import { openDB, unwrap } from 'idb';

const openPromise = openDB(...args);
const idbOpenRequest = unwrap(openPromise);

I can't introduce a 'wait' into openDB without breaking the unwrap case, since I won't have the real idbOpenRequest yet.

Could add an unwrapAsync to handle this scenario. Is unwrap commonly used by idb users? 🤔

Would this mean that the allowlist couldn't be expanded since we could similarly never know if it's safe to allow any currently blocked port?

Yes, I think we would never add new ports to the allowlist, only remove them.

Would a devtools configured exception be possible to use while not keeping devtools open (i.e. similar to adding an exception to your firewall)? I've seen many cases where the presence of devtools significantly slows down the site, and it's awkward to lose that screen real estate when you're not working on the site.

So essentially it would be a normal browser setting, but hidden in devtools rather than on the usual setting page? It might work.

Alternately, could we get most of the benefit without some of the pain by not restricting the main navigation, but only restricting sub-resource requests (explicitly allowing them to the ip:port used for the main navigation)?

I think the security benefits of this are not that great, since you can perform many attacks just by using a form with POST. However, it might be a good transitional stage to get web developers used the idea of there being an allowlist.

I have a large folder of WebP images that I use to test squoosh. All of them are valid and can be opened in Firefox/Chrome, but libSquoosh is being very dramatic about two of them, telling me [file] has an unsupported format.

Here are the first chunks of the two failing images:

 82  73  70  70  10  19   0   0  87  69  66  80  86  80  56  32
[R] [I] [F] [F]  []  []  []  [] [W] [E] [B] [P] [V] [P] [8] [ ]

 82  73  70  70 236  10   0   0  87  69  66  80  86  80  56  76
[R] [I] [F] [F] [ì]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [L]

And here are two functioning images for comparison:

 82  73  70  70 174  18   0   0  87  69  66  80  86  80  56  88
[R] [I] [F] [F] [®]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [X]

 82  73  70  70 202 131   0   0  87  69  66  80  86  80  56  76
[R] [I] [F] [F] [Ê]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [L]

The failing images both contain the code point 10, which JavaScript interprets as a newline. RegEx (which libSquoosh uses to sniff the image encoding) won't match across newlines by default. For that to work, you have to add the s flag, which is what this PR does :)

For annoying legal reasons, I can't post the failing images publicly, but I can send one of them privately if you'd like me to.

I have a large folder of WebP images that I use to test squoosh. All of them are valid and can be opened in Firefox/Chrome, but libSquoosh is being very dramatic about two of them, telling me [file] has an unsupported format.

Here are the first chunks of the two failing images:

 82  73  70  70  10  19   0   0  87  69  66  80  86  80  56  32
[R] [I] [F] [F]  []  []  []  [] [W] [E] [B] [P] [V] [P] [8] [ ]

 82  73  70  70 236  10   0   0  87  69  66  80  86  80  56  76
[R] [I] [F] [F] [ì]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [L]

And here are two functioning images for comparison:

 82  73  70  70 174  18   0   0  87  69  66  80  86  80  56  88
[R] [I] [F] [F] [®]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [X]

 82  73  70  70 202 131   0   0  87  69  66  80  86  80  56  76
[R] [I] [F] [F] [Ê]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [L]

The failing images both contain the code point 10, which JavaScript interprets as a newline. RegEx (which libSquoosh uses to sniff the image encoding) won't match across newlines by default. For that to work, you have to add the s flag, which is what this PR does :)

For annoying legal reasons, I can't post the failing images publicly, but I can send one of them privately if you'd like me to.

Async pool seems small and good enough. Not sure if it’s necessary, but whoever takes this on, is welcome to use it.

Looking into this, ti seems the wildcards are not working in Windows.

@samdutton is working on adding globs, so this will hopefully get solved through his work!

You'll get a DevTools "improvement" suggested for accessing navigator.userAgent. One would might realistically expect this issue to be fixed before Safari adds support for navigator.userAgentData, so this feels like a reasonable addition just in case you want to give it a whirl.