@astrojs/image: Don't include original image in output bundle

[jkjustjoshing]

What version of astro are you using?

1.2.5

Are you using an SSR adapter? If so, which one?

No

What package manager are you using?

npm

What operating system are you using?

Mac

Describe the Bug

I'm not sure if this is a bug or a feature request - my apologies if I should have submitted this to github.com/withastro/rfcs

When using @astrojs/image with the <Picture> component and widths={} prop, multiple different sizes of images end up in my ./dist/assets folder corresponding to the values I pass widths. However, there is also a copy of the original full-sized image.

This full-sized image is not referenced in the HTML at all, and is never downloaded by the site user, so I have no concerns for user-experience with an oversized image. However, including this full-size image in the bundle makes deploys slower and can increase hosting costs.

Suggested change

Remove full-size image from output directory

Alternatative

Setting in integration config options for removing the full-size image.

Link to Minimal Reproducible Example

Not applicable (but I can provide one if anyone disagrees)

Participation

• I am willing to submit a pull request for this issue.

[delucis]

I think this was added at the request of people who did need the full size image as well (to reference as an open graph image or use as a download link or something). So I guess a config option that lets you opt out might make sense (or opt in, not sure what makes most sense)

[jkjustjoshing]

That's what I figured. However, the original image has a hashed filename - how would someone write code to actually expose the URL of the full-sized image to the user?

If it is possible to get the path to the full-sized image, then I agree that it's good to keep in the output folder (with an option to exclude it). However, if it's not possible then I would say either a) there's no value in having it or b) there should be a way to expose the original file's path to the developer.

[panwauu]

Possible duplicate of #4896

[tony-sull]

The original image actually does need to be included here in case an image is imported and the src is used directly.

Astro won't actually know what image variants are used until every page is built, and it won't actually know at all in SSR since the pages are built at run time.

It's a bit of an implementation detail and a little annoying to see extra files included here, but there's not a way to safely avoid it either unfortunately

---
import hero from '../hero.jpg'
---

<!-- this src can be used as-is, but it will fail if the original file isn't included in dist -->
<img src={hero.src} />

[jkjustjoshing]

Ah that makes sense. I wasn't thinking about using the image in a raw/native <img> element without using <Image> or <Picture>. Thanks for the context!

[supermoos]

@tony-sull could a workaround be to have some sort of import parameter that would exclude it from the output? something like:

---
import hero from '../hero.jpg!discard'
---

It's a big issue as it defeats the purpose for a lot of image generation scenarios to output the original source also.

[supermoos]

Or perhaps some sort of post build way to delete those files again?

[jkjustjoshing]

@supermoos the naming convention of the files is regular, so you probably could write a script post-build that looks for the original file. It would be pretty fragile, but could do something like the following:

Look for files matching the regex /^([^.]+)\.([0-9a-f]+)\.([a-z]+)$/ - that is, "xxxx.abc123.jpg". This is an original (all non-original files have an underscore in the segment before the file extension). $1 is the first part of the path, $2 is the unique content hash, and $3 is the file extension. Before deleting it would be smart to make sure there exist optimized versions of this file - files that follow the pattern $1.$2_[anything alphanumeric].[any extension].

[supermoos]

Thanks for this. Seems a bit error prone though. What if I actually wanna keep some of the source files for some reason? The import suggestion would solve that issue.

[simonwiles]

Fwiw, this causes me a problem on a very image-heavy site, as my originals are large and when they're copied into the output folder I end up with something that's too big to upload to my hosting environment.

[rikur]

I get a lot of noise on aHrefs site audit, because the crawler will download the original images that are way too big.