[Image] Loader config is ignored when using the unoptimized prop

[zignis]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Home Single Language
    Binaries:
      Node: 16.18.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.4.4
      eslint-config-next: 13.4.4
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5

Which area(s) of Next.js are affected? (leave empty if unsure)

Image optimization (next/image, next/legacy/image)

Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/ecstatic-matan-zd6jjm?file=%2Fpages%2Findex.tsx%3A5%2C1

To Reproduce

Create an image (next/image) component with both the loader and unoptimized props.

Describe the Bug

From current docs:

When true, the source image will be served as-is instead of changing quality, size, or format. Defaults to false.

From my understanding, the unoptimized prop disables quality and size optimization, but it should still use the loader config. This is particularly useful when using an external CDN and requesting svg images, which does not require these optimizations. I know we can use the native img tag, but temporarily disabling optimization for an image with just a single props would be such a relief.

Expected Behavior

The loader configuration should be used when the unoptimized prop is set to true.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_NEXT-1493

[vnaveenprasanth]

Hey @zignis , after researching for a while I've found the loader prop and the unoptimized prop cannot be used together.

The purpose of the loader prop is to provide a custom function for generating the image source URL, and it overrides the default optimization behavior. If you want to disable image optimization, you can use the unoptimized prop. However, you cannot combine it with a custom loader function.

Use the following component in your sandbox to test the outcome, I've checked and it loads the image unoptimized, you just need to provide a proper path in src to avoid unloaded Image component...

const CustomImage = (props: Partial<ImageProps>) => ( <Image src={"some_dir/emoji.png"} unoptimized width={64} height={64} alt={""} {...props} /> );

If there's any more I'm missing let me know, I'll be glad to help!

[zignis]

Thanks for the follow-up @vnaveenprasanth! I know you can use an absolute src, I just wanted it to use loader when using the unoptimized prop, as it makes more sense to still use the loader config and just skip the width, height, and quality props. The unoptimized prop should just disable the optimizations, but still use the loader config to resolve the image src. Your thoughts are welcomed.

[yy523697597]

I just stumbled with the same issue. The document doesn't mention this issue.
Because I want to display 3 different images for mobile / tablet / desktop, If I can use the loader that would be easy like this:
const imageLoader = ({ width }) => { console.log('width-->', width) if (width >= 1024) { return image?.desktop } else if (width >= 768) { return image?.tablet } return image?.mobile }

If I can't use the loader, I have to use useEffect to listen the window size change, that would be painful.

[pschaub]

I think this is the code that results into this issue:

next.js/packages/next/src/shared/lib/get-img-props.ts

Lines 500 to 517 in 754a2a6

	if (!unoptimized && !isDefaultLoader) {
	const urlStr = loader({
	config,
	src,
	width: widthInt || 400,
	quality: qualityInt || 75,
	})
	let url: URL | undefined
	try {
	url = new URL(urlStr)
	} catch (err) {}
	if (urlStr === src || (url && url.pathname === src && !url.search)) {
	warnOnce(
	`Image with src "${src}" has a "loader" property that does not implement width. Please implement it or use the "unoptimized" property instead.` +
	`\nRead more: https://nextjs.org/docs/messages/next-image-missing-loader-width`
	)
	}
	}

Here is an example of this issue in a real use-case: cloudinary-community/next-cloudinary#245

[colbyfayock]

for my use case, my solution is to recognize the unoptimized flag in the wrapper and manually construct a new src with the same logic used to construct with the loader

https://github.com/colbyfayock/next-cloudinary/pull/250/files#diff-879a45f305415a4b663acd8b4463e563c5a05d789e561f405d78d7cd3d5cc707R80

the only thing this doesn't address is global configuration of the unoptimized flag, which as far as i can tell, there's not a reliable way to get that information programmatically

one idea i had is to use getImgProps when thats stable and compare the src it provides to the original src passed in to hopefully be able to tell if it has been updated or not from the loader logic, at which point if it hasnt, i can run it, but i wouldnt consider this reliable. ideally we could access any next.config.js context from within the application aside from directly importing next.config.js which i dont think is an option in my case, as its library code

[styfle]

This is the expected behavior because unoptimized prop (or in next.config.js) will serve the image as-is. That means no image optimization, no loader transformation, just the src prop as-is.

Its important to keep this behavior because image optimization often incurs charges and you may have an unexpected bill that you want to immediately turn off so you have a quick solution using unoptimized: true.

One solution here could be introducing a new prop, loaderParams that can be read from the loader function.

It might look like this:

export default function myLoader({ src, width, quality, params }) {
  return `https://example.com/{src}?w=${width}&q=${quality}&foo=${params.foo}`
}

<Image 
  src={src}
  loader={myLoader}
  loaderParams={{ foo: 'one', bar: 'two' }}
/>