QwikDev / qwik

Instant-loading web apps, without effort
https://qwik.dev
MIT License
20.45k stars 1.26k forks source link

[🐞] image optimizer with imagetools in cloudflare addressed wrong srcset #6620

Open alimrb opened 3 days ago

alimrb commented 3 days ago

Which component is affected?

Qwik Runtime

Describe the bug

In cloudflare, I see in the build logs that build directory webp images are being built correct in "build/q-[hash].webp", but in browser, developer tools says srcset ist set to "/assets/[filename]-[hash].webp".

dev and preview have no problem with it.

example here (Demo app): https://qwik-app-9et.pages.dev/

image

image

Reproduction

https://qwik-app-9et.pages.dev/

Steps to reproduce

cloudflare build

System Info

System:
    OS: Windows 11 10.0.22621
    CPU: (8) x64 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
    Memory: 20.31 GB / 31.90 GB
  Binaries:
    Node: 20.13.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.5.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (126.0.2592.81)
    Internet Explorer: 11.0.22621.3527
  npmPackages:
    @builder.io/qwik: ^1.5.7 => 1.5.7
    @builder.io/qwik-city: ^1.5.7 => 1.5.7
    typescript: 5.3.3 => 5.3.3
    undici: * => 6.19.2
    vite: ^5.2.10 => 5.3.1

Additional Information

No response

yasserlens commented 2 days ago

I'm facing the same issue on Netlify - so this doesn't seem to be Cloudflare specific. The issue does not appear in local dev.

This happened after I upgraded from qwik v1.3.x to 1.6.0 Nothing else changed other than the upgrade + added "fetchPriority='high'" to one of the images - but that shouldn't be it since all images are wrongly addressed.

Client-side navigation seems to reset image URLs to have the correct path.

Here's an example image tag with the wrong path (note "assets" in the path)

<img decoding="async" loading="lazy" alt="an example image." srcset="/assets/example-m-Dmbnq0dN.webp 200w, /assets/example-m-N97A-rpt.webp 400w, /assets/example-m-CkmAcJRP.webp 600w, /assets/example-m-CJIwsBYE.webp 800w, /assets/example-m-Dfse9hf3.webp 1200w" width="1200" height="1200" class="hidden lg:block object-cover w-full h-full" q:key="X5_3">

And here is the same tag when I navigate away then come back to the same page (it appears correctly - with the correct path "build" and the names of the image files obfuscated):

<img srcset="/build/q-5m56tHTT.webp 200w, /build/q-DfewPq6b.webp 400w, /build/q-pJgHCUT9.webp 600w, /build/q-iSMLAWBN.webp 800w, /build/q-37HvYX96.webp 1200w" width="1200" height="1200" decoding="async" loading="lazy" alt="an example image." class="hidden lg:block object-cover w-full h-full" q:key="X5_3">
yasserlens commented 1 day ago

Looking at the output of npm run build I see the following warning - could this be related? I do see it in the older qwik versions though which does not have the same bug (e.g. v1.3)

The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

assetFileNames isn't equal for every build.rollupOptions.output. A single pattern across all outputs is supported by Vite.
Screenshot 2024-07-01 at 11 30 49 p m
shairez commented 1 day ago

Thanks for the report @yasserlens !

Can you please provide a link to the repro github repo?

Thanks!

gioboa commented 1 day ago

I'm looking at this issue but I can't reproduce it locally.

yasserlens commented 17 hours ago

Since I can only see this in prod I don't have a ready repo - but I'll try to isolate the issue in sample code and publish it somewhere.

Note that I also tried this on Vercel using the Vercel adapter - same issue. So far, this exists on:

Only in production. Local dev doesn't show it. Local prod via npm run preview does not show the issue either.

yasserlens commented 3 hours ago

I created a public repo for you to see this - see demo below: https://qwik-1-6-test-5xqrst5a4-yasserlens-projects.vercel.app/

And the code is below: https://github.com/yasserlens/qwik-1.6-test-app

Notes:

export component$(() => return () )


- The behavior is the same on Vercel, Netlify (tested them myself) and cloudflare (original report).
gioboa commented 3 hours ago

I see thanks, I reproduced it locally and I found the commit that generated the issue. I'm working to fix this.