Image URLs from file loader no longer have asset prefix in 5.3.3

[mudge]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

Between Gatsby 5.3.2 and 5.3.3, image URLs generated by the file loader no longer include any configured asset prefix, e.g. the src URL for the following:

import logo from './images/logo.svg'

const SomeComponent = () => (
  <img src={logo} alt="" >
)

When built with gatsby build --prefix-paths and assetPrefix set to https://assets.example.com in gatsby-config.js should be prefixed with https://assets.example.com.

This seems to be caused by f448e12 as removing that change causes the asset prefix to be reinstated.

Reproduction Link

https://github.com/ghostcassette/gatsby-asset-prefix

Steps to Reproduce

1. import an image in a React component and use it in an img tag, e.g.

import logo from "../images/icon.png"

const IndexPage = () => ( 
  <img src={logo} alt="" />
)

2. Set assetPrefix to https://assets.example.com in gatsby-config.js
3. Build the site with gatsby build --prefix-paths

Expected Result

The image URL should be prefixed with the asset prefix, e.g. https://assets.example.com/static/icon-decafbad.png

Actual Result

The image was not prefixed with the asset prefix but was relative to the current hostname, e.g. /static/icon-decafbad.png

Environment

System:
    OS: macOS 13.1
    CPU: (10) arm64 Apple M1 Max
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.13.0 - ~/.nodes/node-18.13.0/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.19.3 - ~/.nodes/node-18.13.0/bin/npm
  Languages:
    Python: 3.9.9 - /Users/mudge/.pyenv/shims/python
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 108.0.1
    Safari: 16.2

Config Flags

No response

[tyhopp]

Thank you for the repro and description!

[jt-nti]

@tyhopp I think the same issue was introduced between 4.25.0 and 4.25.1 - do you know if the fix is likely to be included in 4.25.x at some point? Thanks.