TypeError: Cannot use 'in' operator to search for '__next_img_default' in undefined

[ojj1123]

Link to the code that reproduces this issue

https://github.com/ojj1123/next-custom-loader-issue-repro

To Reproduce

1. pnpm install
2. pnpm dev
3. and then you can see the issue below:

Current vs. Expected behavior

Expected behavior

I want to configure the image loader globally.
Nextjs docs describes that I can configure the image loader at next.config.js:

const nextConfig = {
  images: {
    loader: 'custom',
    loaderFile: '/custom-loader.ts',
  },
};

export default nextConfig;

Current

But currently, nextjs occurs this error:
It is shown at either App router or Page router

TypeError: Cannot use 'in' operator to search for '__next_img_default' in undefined

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:28:12 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T8103
Binaries:
  Node: 18.19.0
  npm: 10.2.3
  Yarn: 1.22.21
  pnpm: 8.15.4
Relevant Packages:
  next: 14.1.4
  eslint-config-next: 14.1.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

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

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local)

Additional context

This error occurs at getImgProps

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

Lines 286 to 294 in 0c21ff7

	let loader: ImageLoaderWithConfig = rest.loader || defaultLoader
	// Remove property so it's not spread on <img> element
	delete rest.loader
	delete (rest as any).srcSet
	// This special value indicates that the user
	// didn't define a "loader" prop or "loader" config.
	const isDefaultLoader = '__next_img_default' in loader

rest.loader is what the user pass loader function at Image's loader prop. But I didn't pass the custom loader at Image component so then the value of loader variable above would be defaultLoader. __next_img_default property is only in defaultLoader for checking whether or not the user pass the custom loader. I don't know why the value is undefined

Update

If setting images.loaderFile at next.config.js, defaultLoader module is resolved as config.images.loaderFile during build. So we have to export loader function as default. #63803 (comment)

next.js/packages/next/src/build/create-compiler-aliases.ts

Lines 112 to 119 in b434ea4

	...(config.images.loaderFile
	? {
	'next/dist/shared/lib/image-loader': config.images.loaderFile,
	...(isEdgeServer && {
	'next/dist/esm/shared/lib/image-loader': config.images.loaderFile,
	}),
	}
	: undefined),

Nextjs internally import/export defaultLoader as a default function

next.js/packages/next/src/shared/lib/image-external.tsx

Lines 7 to 8 in 29d53c8

	// @ts-ignore - This is replaced by webpack alias
	import defaultLoader from 'next/dist/shared/lib/image-loader'

After build, the build assets is like:

// next.config.js
const nextConfig = {
  images: {
    loader: 'custom',
    loaderFile: '/custom-loader.js'
  }
}

// custom-loader.js
// ⚠️ named export
export function customLoader({ src }) {
  return src
}

Since custom loader is exported as a named, defaultLoader.default is undefined

// build asset for getImgProps.js
 import defaultLoader from '/custom-loader.js' // Resolve through webpack alias

...
 let loader: ImageLoaderWithConfig = rest.loader || defaultLoader.default // ⚠️ defaultLoader.default is undefined
  
 // Remove property so it's not spread on <img> element 
 delete rest.loader 
 delete (rest as any).srcSet 
  
 // This special value indicates that the user 
 // didn't define a "loader" prop or "loader" config. 
 const isDefaultLoader = '__next_img_default' in loader 
...

[ojj1123]

https://github.com/vercel/next.js/tree/c9439b5654432df6488e178e5ade6f4ad2d1cf6a/test/integration/next-image-new/loader-config

But why this test pass?

Next.js version for test environment : Next.js 14.2.0-canary.48

Repro

https://github.com/ojj1123/next-custom-loader-issue-repro/tree/with-next-canary

So I try to upgrade nextjs version to Next.js 14.2.0-canary.48 and then reproduce it, but the error occurs.

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:28:12 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T8103
  Available memory (MB): 8192
  Available CPU cores: 8
Binaries:
  Node: 18.19.0
  npm: 10.2.3
  Yarn: 1.22.21
  pnpm: 8.15.5
Relevant Packages:
  next: 14.2.0-canary.48 // Latest available version is detected (14.2.0-canary.48).
  eslint-config-next: 14.1.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.3
Next.js Config:
  output: N/A

[ojj1123]

I found the reason.
Nextjs docs describes that the loader file must ONLY export a default function
so I did export as a default and then resolve this issue.

https://github.com/ojj1123/next-custom-loader-issue-repro/tree/export-default-loader

diff --git a/custom-loader.ts b/custom-loader.ts
index 461b1e3..d0af4f9 100644
--- a/custom-loader.ts
+++ b/custom-loader.ts
@@ -2,6 +2,10 @@

 import { ImageLoaderProps } from 'next/image';

-export function customLoader({ src, width, quality }: ImageLoaderProps) {
+export default function customLoader({
+  src,
+  width,
+  quality,
+}: ImageLoaderProps) {
   return `${src}?url=${encodeURIComponent(src)}&w=${width}&q=${quality || 75}`;
 }

Suggestion

BTW, How about supporting a named export?
some people(also me) use the eslint rule, import/no-default-export. Currenly whenever using the custom loader, I have to turn off this rule manually. For flexibility, I suggest supporting a named export for loader.

[devjiwonchoi]

Hi, I'd say it is similar to how the next.config.js is imported, where it also requires a default export.
Since Next.js doesn't support multiple loaders, it is hard to target which one to import with named exports.
Glad you found out the cause by your own!

[ojj1123]

@devjiwonchoi

Since Next.js doesn't support multiple loaders, it is hard to target which one to import with named exports.

Yeah, I agree with you.
Nextjs replaces defaultLoader with custom loader (images.loaderFile) through webpack config.resolve.alias

next.js/packages/next/src/build/create-compiler-aliases.ts

Lines 112 to 119 in b434ea4

	...(config.images.loaderFile
	? {
	'next/dist/shared/lib/image-loader': config.images.loaderFile,
	...(isEdgeServer && {
	'next/dist/esm/shared/lib/image-loader': config.images.loaderFile,
	}),
	}
	: undefined),

next.js/packages/next/src/shared/lib/image-external.tsx

Lines 7 to 8 in 29d53c8

	// @ts-ignore - This is replaced by webpack alias
	import defaultLoader from 'next/dist/shared/lib/image-loader'

But I think it would be good to warn users not to use named exports. Is it possible?

[devjiwonchoi]

Yeah, an accurate error message is always preferred. Mind if I open a PR? Feel free to open one if you'd like to!

[ojj1123]

Oh, so Could I try to PR? I want to investigate and resolve this issue!

[devjiwonchoi]

Yeah, for sure! It's up to you if you'd like to contribute. Ping me if you want to discuss anything. 😄

[ojj1123]

@devjiwonchoi

UPDATE
It's easier to check it during runtime. Because if checking it during buildtime, i should parse the code of a loader file so it's a bit complex. So I've decided to deal with it runtime.

---

I try to resolve this issue but I want to discuss about this issue.
My tries were to detect during runtime and buildtime

1. During runtime

After build (dev or build script), Webpack replaces defaultLoader with custom loader module. And then If exporting custom loader as named, _imageLoader.default(build result) is undefined. So I try to write this condition statements.

import defaultLoader from '.....'

if(typeof defaultLoader === 'undefined') {
  throw new Error('you should export the loader function as default');
}

It was working well. But I thought it's a bit hacky, because if doing that, I write that code wherever Next.js import defaultLoader. (Of course, just two now)
So I try to check it and throw the error during build.

2. During buildtime

I try to make the custom webpack loader for allowing our to use a default function.

// /webpack/loader/next-image-loader-file-loader.ts
const nextImageLoaderFileLoader: webpack.LoaderDefinitionFunction = function (
  this,
  source
) {
  const hasDefaultExport = /export default/.test(source)
  if (!hasDefaultExport) {
    throw new Error('you should export the loader function as default')
  }

  return source
}

// webpack.config.ts
...
module: {
  rules: [
      ...(config.images.loaderFile
      ? [
          {
            test: config.images.loaderFile,
            use: ['next-image-loader-file-loader'],
          },
        ]
      : []),
  ]
}
...

It was throwing the error well. But I thought it has some edge case:

function customLoader() {...}

export default customLoader; // correct
export customLoader; // throw error
export { customLoader as default } // throw error.. but this case is also default export so it should have not to throw the error!!

It's a bit difficult to check whether or not default function during either runtime or buildtime.
How do you think? Do you come up with another solution?

[github-actions]

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.