In XP preview, next/image Images keep their local-to-next.js URLs even when src is prefixed with XP proxy

[espen42]

When using the <Image tag from next/image, a src prop that refers to a file under src/public, is processed to a proprietary format.

For example:
import xpShield from '../../public/images/xp-shield.svg';
...and...
<Image src={xpShield}
...is server-side-rendered by next.js into...

/_next/image?url=%2F_next%2Fstatic%2Fimage%2Fsrc%2Fpublic%2Fimages%2Fxp-shield.074583348b1b4aee2574f3e054e22a93.svg&w=96&q=75

The XP-side proxy processes this to point to the asset proxy instead...

/_/service/com.example.myproject/assetProxy/_next/image?url=%2F_next%2Fstatic%2Fimage%2Fsrc%2Fpublic%2Fimages%2Fxp-shield.074583348b1b4aee2574f3e054e22a93.svg&w=96&q=75

But the browser still tries, and fails, to fetch the first-generated url from the XP root:
http://localhost:8080/_next/image?url=%2F_next%2Fstatic%2Fimage%2Fsrc%2Fpublic%2Fimages%2Fxp-shield.074583348b1b4aee2574f3e054e22a93.svg&w=96&q=75

[espen42]

Path resolution, or hydration-update problem after the SSR? Might be related to #60 .

[sigdestad]

Should probably not use the image "module" in next at all?

[sigdestad]

Alas, images should be added with URL's from XP.

[espen42]

As in, choose not to support it? We might, but it's such an encouraged part of next that a default linting rule in next is to break the build if <img is used instead of <Image.

[espen42]

Two different things. Urls from XP are easier, this issue concerns next's /public/, the parallel to our /assets/. I think we should support this.

[espen42]

The next.js <Image> tag is handy, but the url is difficult to handle for the proxy. Not prioritized for now.