Revert "revert #15354" for configurable image defaults

[Rich-Harris]

Placeholder to reinstate #15354 once we've settled the outstanding questions. cc @benmccann

[changeset-bot]

🦋 Changeset detected

Latest commit: 200b675

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/enhanced-img	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-16124-svelte.vercel.app/

[benmccann]

While I'm not strongly against this, my inclination would probably be to be a bit selective about exposing the vite-imagetools options. I'm not sure users of enhanced-img necessarily have a reason to use many of the options like extendOutputFormats, extendTransforms, resolveConfigs, etc. I think exposing them makes it harder to digest what all the possible options are and means that if a breaking change is made to those options that it also becomes a breaking change in enhanced-img. For those options, I'd prefer to see if users have a use case for them and build something easier to use as they're pretty low-level

I have no objection to exposing an option to control whether or not metadata is removed

@teemingc had a concern that making the cache directory configurable would be incompatible with cloudflare

[teemingc]

Should be fine for users to configure the cache directory if we can add a warning in the option documentation. From the top of my head, Vercel caches node_modules and Cloudflare caches node_modules/.cache with no option for configuration. It's a minor thing really.

[blt-r]

Besides cache directory, there's also #13085.

The reason why I decided to just allow full configuration, is because I imagine a someone may want to just use vite-imagetools while also using this package. As it is, it interferes with users ability to use vite-imagetools in other ways, with other configuration. Therefore, it seems to me that allowing user to configure vite-imagetools fully is correct, otherwise enhanced-img is needlessly restrictive and having having it liability in a way.

Ideally, i would want this package to only handle ?enhanced images and nothing else, so that user can just install vite-imagetools separately if they need. But that isn't really supported by vite-imagetools and implementation would be quite dirty.

Anyways, initially, I just wanted to customize default formats and widths. Maybe we can merge that part for now?

[benmccann]

initially, I just wanted to customize default formats and widths. Maybe we can merge that part for now?

It looks like you wanted to avoid generating the fallback image. I think at some point, SvelteKit's minimally supported browser version will mean that it will only run in browsers where webp/avif are supported and maybe we just generate a picture or img with those and there will be no need for a fallback image format. In that case it's much better to change the default for everyone. I wonder if we're already there in SvelteKit 3 or not.

Ideally, i would want this package to only handle ?enhanced images and nothing else, so that user can just install vite-imagetools separately if they need. But that isn't really supported by vite-imagetools and implementation would be quite dirty.

I actually thought that's how things were setup today.

[blt-r]

Actually, for my usecase I thought I'd just use webp only (hence the #15379 too). In any case, making them customizable is good in my opinion because we have avif, webp, the old formats, maybe jxl in the future, and it's different people might want a different subset of those.

I also wanted to change the default widths, because using the original size and half of it when there's no sizes makes no sense to me.

I actually thought that's how things were setup today.

If you try to add both enhancedImages() and imagetools(), then there would be two separate instances of imagetools and the one that's added first will get to handle the imports, and there will also be a conflict with server middleware for dev mode. To fix the import conflict we can just set include option of the bundled imagetools to only take paths with enhanced query param, and to fix the middleware conflict we would need to patch imagetools to allow to customize the /@imagetools/ path.

I don't think any of it is a good idea tbh.

And it's probably not really desired too. If the user wants to change the cache directory or removeMetadata they probably want to do that for both <enhanced:img>'s and and normal images imported with vite-imagetools at the same time.