Improving support for third-party hosted image services #3957
Conversation
🦋 Changeset detectedLatest commit: 582ea9b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
github-actions
bot
added
the
pkg: integration
| import { loadImage } from '../utils.js'; | ||
|
|
||
| export const get: APIRoute = async ({ request }) => { | ||
| const loader = globalThis.astroImage.ssrLoader; |
There was a problem hiding this comment.
Fix pt. 1 - getImage() in dev will now only build a _image? src for local images. The endpoint can always use the ssrLoader global (currently defaults to the built-in sharp service)
| const isDev = globalThis.astroImage.command === 'dev'; | ||
| const isLocalImage = !isRemoteImage(resolved.src); | ||
|
|
||
| const _loader = isDev && isLocalImage ? globalThis.astroImage.ssrLoader : loader; |
There was a problem hiding this comment.
Fix pt. 2 - getImage() will always use the ssrLoader for local images during development
This makes sure that we don't build a src to a third-party service like Cloudinary for local images that aren't published yet
| } | ||
|
|
||
| declare global { | ||
| var astroImage: ImageIntegration; |
There was a problem hiding this comment.
Making typescript happy with a globalThis definition 🎉
Changes
Updating the image integration to handle a specific use case for hosted image services. When using a hosted image service like Cloudinary or Vercel,
astro devshould still use the built-insharpimage service for local imagesWhy?
Local images may not have been published to production yet and wouldn't be available to the hosted services
Testing
All existing tests should pass - not quite sure the best way to automate a test that would use a fake hosted image service
Docs
README updated with details on how the image integration works with hosted services in
astro dev