strapi local image sharp provider

[jiblett1000]

Hello,

I created this originally to solve #641. Strapi doesn't normally provide modifiers beyond "breakpoint". Since the sizes prop uses width & height path/query url parameters to request appropriately sized images, it normally has no effect. However, when the local image sharp plugin is installed in Strapi, it provides many modifiers (including width & height). This provides the necessary parameters for the sizes prop to function properly while also allowing additional modifiers through the local image sharp plugin.

This could perhaps be included in the Strapi provider with the functionality being enabled through a nuxt.config.strapi boolean (localImageSharp: boolean or similar), but for now, I've separated it into it's own provider. I'm happy to refactor it however after some review and do a PR for the docs as well.

Look forward to hearing from you. Thanks for reading!

[netlify]

👷 Deploy request for nuxt-image-v1 pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	bfb405e

[pi0]

Thanks for the pull-request. However I'm not sure about advantages of this new preset. Image module already uses default IPX provider which uses local sharp transforms.

[jiblett1000]

@pi0 I did not see that before. However, after testing just now, it adds the _ipx prefix to images which eliminates the possibility of using it with strapi. Setting baseUrl in the config doesn't work either. Perhaps there is something I'm missing here?

[den-kar]

Hi everyone,
@jiblett1000 thx for this PR, looks exactly like the preset I need.
@pi0 the advantage of this new preset is access to modifiers like format, quality, etc., when using files from the Strapi media library. The current available strapi preset only offers access to the modifier breakpoint.

[jiblett1000]

@den-kar No problem 😁. In case you haven't seen it. I posted a solution using a custom strapi provider at the bottom of the related issue in case you want to start using it.

[Krislunde]

I wish this pull request would get accepted, as it's better than the already existing Strapi provider since it provides utility beyond strapis set "breakpoints" - that way I wouldn't have to roll my own every time. Would there be a higher likelihood of it getting accepted if there was some work done to the existing provider so that an option could provide the functionality this PR includes or something instead of offering two strapi providers?