No information about how to customize <Image> component hash

[MrAmericanMike]

📋 Explain your issue

So I was reading the documentation at https://docs.astro.build/en/guides/images/ and the only mention about hashes is:

Keep in mind that during development, Astro uses a src/ path, but upon building, it generates hashed paths like /_astro/cat.a6737dd3.png.

But there is no mention on how to customize that hashing process. Personally I find that a6737dd3 in this example, looks ugly as hell and probably isn't SEO friendly, but not clue about this. Would also love to be able to place images somewhere else and not in a _astro folder. (Will check astro.config.mjs I'm assuming there is some option in that file for this)

I would like a way to be able to customize the hashes so they become something like....

cat-300x200.jpg or anything that looks not only more user friendly, but also more informative about what was done with the image during the build process.

So maybe this is not only a documentation request, but also a feature request?

Let me know what can be done to achieve this (Hopefully it's possible)

[Princesseuh]

The assets are hashed (like CSS and JS) so that you can put an immutable cache header on them, otherwise you'd need to invalid them in another, less performant, way.

It's also the easiest way to have multiple images with the same attributes without conflicting names. In the example you shared, you wouldn't be able to have two images named cat.jpg of the same width and height, which is a fairly possible pattern (you might have a gallery of cats!)

As for SEO, the most important part is that you have a proper alt and caption for your image, not that it has a good looking for humans file names, see Google's publishing guidelines.

Likewise, the filename can give Google very light clues about the subject matter of the image.

Since it only lightly matters, the fact that file names contain the original file name should be enough information for search engines.

The most important attribute when it comes to providing more metadata for an image is the alt text (text that describes an image), which also improves accessibility for people who can't see images on web pages, including users who use screen readers or have low-bandwidth connections.

Google uses alt text along with computer vision algorithms and the contents of the page to understand the subject matter of the image.

[MrAmericanMike]

It's also the easiest way to have multiple images with the same attributes without conflicting names. In the example you shared, you wouldn't be able to have two images named cat.jpg of the same width and height, which is a fairly possible pattern (you might have a gallery of cats!)

I'm not sure I understand how I would end up with 2 files with the same name, if the images come from src/assets right there it would be impossible to have 2 files with the same name already. And if the images live for example in pages/calico/cat.jpg and pages/tuxedo/cat.jpg you would think Astro when building will place those on _astro/calico/cat.hash_or_nice_name.jpg and _astro/tuxedo/cat.hash_or_nice_name.jpg Even then Astro could fail at build time informing the developer of the error and it would be on them making sure the file names are unique.

Anything that gives us more control would be great.

And btw, I tried specifying the output folder for the resources, but it fails as Astro keeps looking for them inside _astro while building, and it doesn't use the folder specified in astro.config.mjs

[Princesseuh]

And if the images live for example in pages/calico/cat.jpg and pages/tuxedo/cat.jpg you would think Astro when building will place those on _astro/calico/cat.hash_or_nice_name.jpg and _astro/tuxedo/cat.hash_or_nice_name.jpg

Why would it? Where the image are in the src is fairly irrelevant to the final structure, because you might be referring to it from completely unrelated files. Same thing for CSS and JS, right, they end up wherever is the most efficient. (which is also _astro/* for the same benefits)

With the structure you're suggesting files in src/pages/calico/ and in src/calico/ would end up in the same folder, assuming that what your suggesting applies to every folder. (It's not very common to have images in src/pages). src/pages/ could have a special behaviour, but it'd be a bit unusual since the folder typically only really contains pages (hence the name, ha)

And btw, I tried specifying the output folder for the resources, but it fails as Astro keeps looking for them inside _astro while building, and it doesn't use the folder specified in astro.config.mjs

The following config seems to work for me for changing the folder:

build: {
  assets: "_something",
},

But there's quite a lot of settings that control the outputting of assets, so it's not impossible we don't respect all of them yet, I know there's an issue for something related here: https://github.com/withastro/astro/issues/8739

Anything that gives us more control would be great.

I'd suggest opening a discussion here: https://github.com/withastro/roadmap/discussions with this feedback so that users can vote it and we can discuss as a community if we should or not do this. I'll close this issue in the meantime to avoid bothering our docs team

[MrAmericanMike]

Thanks a lot for the response. Also the build: assets worked, I was using vite build rollup options and that caused issues I guess.