There was a bug when the user defines a width on the Image component, but a larger size image is requested.
This is because the browser uses the `srcset` to decide which image size to request and we had the srcset basically hardcoded.
This PR fixes the behavior so that the `srcset` will never be larger than the `width` defined on the component.
It also fixes a bug where the preload srcset did not match the img srcset.
- Related to #18147
- Related to #18122
We currently always accept requests to the new `/_next/image` endpoint, even when it should not be used.
Instead, we should check to see if the default loader is used as a signal to enable this API.
Other loaders (such as cloudinary) will not go through the Next.js API so there is no need to expose this, instead we 404.
- Analogous to https://github.com/vercel/vercel/pull/5321
- Related to #18122
For many users refactoring from `<img>` to `<Image>`, we can often support their properties as-is.
The exception was width/height.
This PR allows the `<Image>` component to accept strings for `width` and `height` just like `<img>`.
Related to #18122
Previously, vector images like svg were being converted to webp and resized.
However, vector images already handle any size so we can bypass the same we do for animated images.
Related to #18122
The `w` parameter in the Image Optimization API is the requested size of the image and should only be resized if the source image is larger than the requested size. This PR fixes the behavior to prevent accidental upscaling, for example icon images.
This PR updates the `<Image>` component to follow the same property naming as native `<img>`.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-loading
This currently allows two values,`loading=lazy` and `loading=eager`, but there might be new values added in a future spec.
cc @atcastle
This updates the fallback 404 handling to render the correct 404 page on the client when a 404 is returned from fetching the data route on a fallback page on the client. This prevents us from having to rely on a cache to be updated by the time we reload the page to prevent non-stop reloading.
This also adds handling in serverless mode to ensure the correct 404 page is rendered when leveraging fallback: 'blocking' mode.
Additional tests for the fallback: 'blocking' 404 handling will be added in a follow-up where returning notFound from `getServerSideProps` is also added.
This makes sure the `locales` are passed to `getStaticPaths` and also disables the removing the default locale from the path when the default locale is the preferred header. It also updates tests to ensure the domain redirects are working as expected.
x-ref: https://github.com/vercel/next.js/pull/17370
This makes sure that we detect the correct default locale for domain specific locales since a domain can have a different default locale residing at the root and we need to check this on the client for prerendered/auto-static pages. This also makes sure we disable the built-in redirect handling when on Vercel since it's handled already.
Tests for this are tricky since we need to load the browser with a custom domain which requires editing the host file. Existing tests should ensure this doesn't break non-domain specific locale behavior though. This was also tested manually while testing https://github.com/vercel/vercel/pull/5298
x-ref: https://github.com/vercel/next.js/pull/17370
This updates the new image optimizer endpoint to instead of relying on the `host` and `proto` headers for relative files to use the internal route handling in `next-server` to load files from the public directory. The existing tests for relative files with the endpoint should cover these changes
This makes sure the image optimizer doesn't de-animate images by transforming them with sharp since sharp doesn't currently handle outputting animated images
x-ref: https://github.com/vercel/next.js/pull/17749
