Add ability to configure cache directory for image conversions in @sveltejs/enhanced-img

[mglinski]

Describe the problem

Using the @sveltejs/img:enhanced package generates a large number of cacheable converted image variants in various sizes/formats. This process also takes a long time to run the more images are processed and the more variants that are requested.

The vite-imagetools plugin supports caching these artifacts, which @sveltejs/img:enhanced also supports as of v0.2

It does not seem to be possible to use the configuration options that are built into the vite-imagetools plugin to specify where these cached build artifacts should be saved though when using @sveltejs/img:enhanced.

Describe the proposed solution

I would like to be able to configure the upstream vite-imagetools cache options for use in @sveltejs/enhanced:img.

The upstream PR is here and the documented configuration object for cache options is here.

Perhaps having a config passthrough in the vite.config.js file could be an acceptable solution?

import { enhancedImages } from '@sveltejs/enhanced-img';
export default defineConfig({
  ...
  plugins: [
    enhancedImages({
      cache: {
        dir: './node_modules/.cache/imagetools'
      }
    })
    ...
  ]
});

Alternatives considered

I have setup a cache using the default location that vite-imagetools uses but I would like to manually specify the cache location and bring it outside of the node_modules folder.

Importance

nice to have

Additional Information

No response

[marekdedic]

Drive-by comment: I think this is a duplicate of #13085

[strfx]

Facing the same issue when running npm clean-install (e.g., in CI), as it wipes out node_modules.

I'd like to configure the cache directory directly when setting up enhancedImages.

I am happy to create a PR for that. I have two ideas to set this up:

1. directly pass an object to imagetools via enhancedImages(); flexible, but also ties enhancedImage()'s signature to that of imagetools
2. wrap options in a dedicated interface, selectively pass through options to imagetools; Less flexible, but decoupled from imagetools and could potentially carry non-imagetools related options, too.

Personally, I think option 2 makes most sense going forward. Let me know what you think and I'll come up with a PR.

Edit: I opened a PR with above approach: #14991