The image manifest file is like a flight manifest onboard an aircraft, it contains a list of source images that were processed, the image formats that were generated using the pipeline and the resulting metadata object at the time that the image was saved. As the pipeline is a completely dynamic, the resulting formats from an image may vary greatly in type and in number.
A bare-bones manifest contains a list of source images and it's relative path to the input directory, and its resulting formats with their relative paths to the output directory.
Manifest files are minimal, and use short property keys to minimise their size. p stands for path, f stands for formats and m stands for metadata.
To extend the manifest with more information,we can map certain keys to metadata values.
A map is a key/value object. Think of it as a function, that transforms an input value to a certain output value.
This allows us to select different metadata keys, include them in the manifest, and even modify them.
Notice that we can use the same limit selector ":" that we used in the
save property. This will shorten the value to the specified length.
The above manifest configuration will produce something like this:
Fantastic! We now know the size of each file, and the hash of the original source image.
How you want to exploit the manifest file is up to you. You can:
- Read it in your build process and move your images accordingly
- Serve images from an endpoint, using it to select the best format
- Let the client download the entire list and choose the best image
- Let the client request an image and get a list of formats
- ⭐ Inline relevant images into the web page to avoid round-trips
This is not the most elegant solution, but still works well. Give the manifest file a really large cache header, and the browser won't have to download it again, for any webpage!
This is essentially what the
gatsby-image plugin does. You request the image, it will generate
breakpoints and return a tiny object with paths, aspect ratios, etc. The same could be achieved with
IPP, although you may have to implement a plugin using some of IPPs lower-level modules, such as
This is the best of both worlds, as there are no wasted round-trips or redundant data.
The concepts of metadata and manifest are shared by many of IPP's packages, however, the specific shortened format of the JSON manifest object is generated by the CLI package.
It was chosen to be as compact as possible to allow it to be used over the network, whilst providing
as much user-chosen relevant information as possible. You may re-implement the design of the
manifest whilst benefiting from helpful metadata parsing and manifest generation functions exported
@ipp/common package to suit your particular use case.