Next beta app directory - random problem with local Images #48820
Comments
|
Do you have a reproduction repo or codesandbox or something like it where it runs into this issue by chance? |
|
OK i spent few hours to create repetitive scenario on local environment. It looks like a problem with sharp. after removing sharp - it works fine: git clone https://github.com/diabelb/next-bug Right now you have 10 seconds to make some load on example image. On first container start above endpoint will hang forever. This fails only on first start. To repeat this problem you need to rebuild docker container with different image tag. You can use any image width. In real world scenario this is a huge problem. On every deployment to docker environment i have some broken images that loads forever. |
|
and in turbo pack is not working at all, I already rise this bug but seems not be followed, I hope this one gets tracked |
|
i have same issue, i am using import like |
webpack or turbopack ? |
i am using webpack. try this https://nextjs.org/docs/advanced-features/output-file-tracing |
Webpack work as expected to me, is turbopack which is not working with images. |
…ep (#61696) ## History Previously, we added support for `squoosh` because it was a wasm implementation that "just worked" on all platforms when running `next dev` for the first time. However, it was slow so we always recommended manually installing `sharp` for production use cases running `next build` and `next start`. Now that [`sharp` supports webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no longer need to maintain `squoosh`, so it can be removed. We also don't need to make the user install sharp manually because it can be installed under `optionalDependencies`. I left it optional in case there was some platform that still needed to manually install the wasm variant with `npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't believe sharp has any fallback built in yet). Since we can guarantee `sharp`, we can also remove `get-orientation` dep and upgrade `image-size` dep. I also moved an [existing `sharp` test](#56674) into its own fixture since it was unrelated to image optimization. ## Related Issues - Fixes #41417 - Closes #54670 - Related #54708 - Related #44804 - Related #48820
…ependency (#63321) ## History Previously, we added support for `squoosh` because it was a wasm implementation that "just worked" on all platforms when running `next dev` for the first time. However, it was slow so we always recommended manually installing `sharp` for production use cases running `next build` and `next start`. Now that [`sharp` supports webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no longer need to maintain `squoosh`, so it can be removed. We also don't need to make the user install sharp manually because it can be installed under `optionalDependencies`. I left it optional in case there was some platform that still needed to manually install the wasm variant with `npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't believe sharp has any fallback built in yet). Since we can guarantee `sharp`, we can also remove `get-orientation` dep and upgrade `image-size` dep. I also moved an [existing `sharp` test](#56674) into its own fixture since it was unrelated to image optimization. ## Related Issues - Fixes #41417 - Related #54670 - Related #54708 - Related #44804 - Related #48820 - Related #61810 - Related #61696 - Related #44685 - Closes #64362 ## Breaking Change This is a breaking change because newer versions of `sharp` no longer support `yarn@1`. - lovell/sharp#3750 The workaround is to install with `yarn --ignore-engines` flag. Also note that Vercel no longer defaults to yarn when no lockfile is found - vercel/vercel#11131 - vercel/vercel#11242 Closes NEXT-2823
…ependency (#63321) ## History Previously, we added support for `squoosh` because it was a wasm implementation that "just worked" on all platforms when running `next dev` for the first time. However, it was slow so we always recommended manually installing `sharp` for production use cases running `next build` and `next start`. Now that [`sharp` supports webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no longer need to maintain `squoosh`, so it can be removed. We also don't need to make the user install sharp manually because it can be installed under `optionalDependencies`. I left it optional in case there was some platform that still needed to manually install the wasm variant with `npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't believe sharp has any fallback built in yet). Since we can guarantee `sharp`, we can also remove `get-orientation` dep and upgrade `image-size` dep. I also moved an [existing `sharp` test](#56674) into its own fixture since it was unrelated to image optimization. ## Related Issues - Fixes #41417 - Related #54670 - Related #54708 - Related #44804 - Related #48820 - Related #61810 - Related #61696 - Related #44685 - Closes #64362 ## Breaking Change This is a breaking change because newer versions of `sharp` no longer support `yarn@1`. - lovell/sharp#3750 The workaround is to install with `yarn --ignore-engines` flag. Also note that Vercel no longer defaults to yarn when no lockfile is found - vercel/vercel#11131 - vercel/vercel#11242 Closes NEXT-2823
|
This issue has been automatically marked as stale due to two years of inactivity. It will be closed in 7 days unless there’s further input. If you believe this issue is still relevant, please leave a comment or provide updated details. Thank you. |
|
This issue has been automatically closed due to two years of inactivity. If you’re still experiencing a similar problem or have additional details to share, please open a new issue following our current issue template. Your updated report helps us investigate and address concerns more efficiently. Thank you for your understanding! |
|
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Verify canary release
Provide environment information
Which area(s) of Next.js are affected? (leave empty if unsure)
No response
Link to the code that reproduces this issue
It's random
To Reproduce
No way to reproduce.
Describe the Bug
I have random problem with next images served from public directory.
Currently i'm using latest v13.3.1 with beta App directory - but i had the same problem on all v13.3.1 canary versions.
It's random - sometimes all images are working correctly sometime not. For example right now i have a banner with srcset:
/_next/image?url=%2Fbanner-desktop.jpeg&w=640&q=75 640w, /_next/image?url=%2Fbanner-desktop.jpeg&w=750&q=75 750w, /_next/image?url=%2Fbanner-desktop.jpeg&w=828&q=75 828w, /_next/image?url=%2Fbanner-desktop.jpeg&w=1080&q=75 1080w, /_next/image?url=%2Fbanner-desktop.jpeg&w=1200&q=75 1200w, /_next/image?url=%2Fbanner-desktop.jpeg&w=1920&q=75 1920w, /_next/image?url=%2Fbanner-desktop.jpeg&w=2048&q=75 2048w, /_next/image?url=%2Fbanner-desktop.jpeg&w=3840&q=75 3840w"All sizes are working correctly except one: /_next/image?url=%2Fbanner-desktop.jpeg&w=1200&q=75
It's pending forever without any error message or timeout. What's more funny if i'll change query param q from 75 to any different number for example /_next/image?url=%2Fbanner-desktop.jpeg&w=1200&q=76 - it'll work.
It's random without any way to reproduce it or errors in logs, sentry etc.
Is there any way to debug it?
Expected Behavior
It should serve an image.
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response
The text was updated successfully, but these errors were encountered: