Address out of order compatibility brands in Filetypebox of heif files

[OliverSpeir]

Changes

1. Add detectType function to /lib/types/heif.ts

• This improve ability to accurately detect type for HEIF images where the compatibility brands are out of order
  • Currently heif.ts relies on the first brand in the FileTypeBox, but for example some .avif images do not have "avif" as the first type in their FileTypeBox

2. Sets node version in package.json to 18.4 which shouldn't cause any problems as far as I am aware

[netroy]

Thanks for this. Can we please add test images to assert these fixes, and to prevent any regressions in the future 🙏🏽

[sonarcloud]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[OliverSpeir]

what I've done in order to achieve the tests is somewhat hacky, I'll admit. I didn't know how to generate the actual images that would correspond to these conditions, so I manually edited the type boxes of a .avif version of sample.png I created with sharp.

The way I discovered this condition is from an image in astro's tests. Here's the original image and I looked at how this images type box was structured and recreated it.

All of the test files I added have a very similiar structure, the only difference is to test each condition I changed the second brand. They all are structured like this:

@netroy Hopefully this makes sense and is viable in your opinion I am happy to rework / make any changes you'd like. Thank you

[netroy]

I've been trying to find a way to create these images properly using a reliable tool. but no luck so far, as no tool lets us define the brands. The manually edited files look okay at a first glance, but the Image Properties section in my file browser shows a Failed to load image information only for the edited files. No such issues with light_walrus.avif though.
So, I'm guessing the manual editing of the brands isn't representative of actual images.
So, I'm conflicted about if I should delete those files, merge the PR, and just hope that this will continue to work as it should, or if I should keep looking for better tools for creating avif/heic/heif.

BTW, I've rebased this on the main branch, so that if this gets merged, we don't need to wait for 2.0 to release this to NPM.

[OliverSpeir]

or if I should keep looking for better tools for creating avif/heic/heif.

I will try to do the same, I am not too shocked to hear this didn't work I wish I could figure out how the original light_walrus.avif was created, but I'll try to also do some research

we can also use light_walrus.avif itself if we can't find a way to recreate this type of .avif