Regression due to #14590: images with absolute paths in JSON cause (confusing) errors

[kslstn]

Astro Info

Astro                    v5.15.7
Node                     v20.19.1
System                   Linux (x64)
Package Manager          unknown
Output                   static
Adapter                  none
Integrations             @astrojs/mdx
                         @astrojs/sitemap

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

Continuing the thread at #14590.

When a JSON file used for a collection contains an image path that is treated as image() by the content layer, Astro throws an error saying the image does not exist.

The error message has an additional ./ preceding the file path. For example, this message is shown:

Could not find requested image ./src/assets/blog-placeholder-2.jpg. Does it exist?

Whereas the image path as defined in the JSON is "src/assets/blog-placeholder-2.jpg".

What's the expected result?

In previous versions, the image was found.

In v5.14.7, an error message showing the actual value from the JSON was shown:

Could not find requested image src/assets/blog-placeholder-2.jpg. Does it exist?

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-uy9ezbj7?file=src%2Fcontent.config.ts

Participation

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

[BuckyBuck135]

This bug is still occurring in v5.16.2.

@florian-lefebvre May I ask what is the workaround that you have found? (is it manually changing the image path?)

[florian-lefebvre]

Yes the workaround is to update the path. Not ideal

[matthewp]

@kslstn Is this just about the error message or does something not work any more?

[petwu]

I just tried to upgrade to Astro 5.16 and I think #14590 broke all my asset imports. I used #/assets/* as a typescript alias for all my images, videos, etc. Suddenly I get countless errors like this:

[ERROR] [ImageNotFound] Could not find requested image `./#/assets/img/foobar.png`. Does it exist?

I think the issue is, that the PR introduced an implicit assumption that all import aliases start with either @ or ~ and I my case wrongly added the ./ prefix. I'm not sure if such a strong assumption is a good idea, especially if it's not documented.