The config arg should not be passed to user-defined loader function in `next/image

[addy-pathania]

Verify canary release

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

Provide environment information

Operating System:
Platform: win32
Arch: x64
Version: Windows 10 Pro
Binaries:
Node: 14.17.6
npm: 6.14.15
Yarn: 1.22.17
pnpm: N/A
Relevant packages:
next: 12.1.0
react: 17.0.2
react-dom: 17.0.2

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

Describe the Bug

The bug for next.config.js not considered for node_modeles was discussed here: https://github.com/vercel/next.js/issues/31065

Fixed in PR:https://github.com/vercel/next.js/pull/33559

After the above fix when trying to build the next app the config argument passed in the custom loader function resolves to the default next variables.

Expected Behavior

The config argument in the loader function should return the variables configured in the next.config.js coming from the node_modules when trying to build the app statically.

To Reproduce

1. Create the next app
2. The app should use a next.config.js for the 3rd party packages inside node_modules that import next/image(which uses a custom loader function).
3. Build the app next build

The config argument in the loader function returns default next.config variables set by vercel.

[ambrauer]

@balazsorban44 Just to provide some additional context / info...

We are creating a next/image wrapper component (to be published in our SDK npm package) which uses a
custom loader. According to docs/discussions, this approach should support build-time optimization (next build and even next export). However, as noted in the description the config values (in particular, we are using path) passed into the custom loader are not pulling from the app's next.config.js. Instead, they are the default values.

This issue does not occur with next dev.

[styfle]

Hi @ambrauer and @sc-addypathania

The config parameter of the loader() function is undocumented because its only meant to be used by the default loader.

It was changed from a global variable to a function parameter in #33559 as an implementation detail, not as a public API.

Furthermore, this config is meant for the default Image Optimization API. Since the loader prop bypasses the default Image Optimization API in favor of a custom function, those config options should no longer be relevant because the function can implement the optimization url however it wishes.

It sounds like the bug here is that next dev is accidentally leaking implementation details.

For the purposes of your custom loader, it might be best to ask the user for an explicit prefix prop rather than relying on next.config.js (especially if we ever decide to drop the path config option in a future release).

[styfle]

Here's a concrete example. Consider this Next.js app:

module.exports = {
  images: {
    loader: 'cloudinary',
    path: 'https://res.cloudinary.com/myaccount/'
  }
}

import Image from 'next/image'
import OtherImage from 'other-image'

<Image src="/me.png" width="100" height="100" />

<OtherImage src="/me.png" width="100" height="100" />

The path only makes sense because the loader is cloudinary and that prefix is for cloudinary. It emits something like:

https://res.cloudinary.com/myaccount/q_auto,c_limit,w_100,q_auto/me.jpg

For the other image imported from a package that wraps next/image, it would likely break if it tried to reuse this path. It might emit something that doesn't work with cloudinary, such as:

https://res.cloudinary.com/myaccount/me.jpg?mw=100

[ambrauer]

Hi @styfle, thanks for clearing this up.

We were struggling with the fact that the URL root/path/prefix is defined in the app, while the custom loader is in our SDK. Piggybacking on the default loaders config was a simple solution for us (and made some sense from a DevEx perspective since "path" served the same purpose for us), but your explanation makes sense.

One suggestion beyond aligning the config treatment between next dev and next build: it might also be helpful to exclude the config from the component loader function parameter type (ImageLoaderProps) to avoid confusion. Folks implementing a custom loader will see this and assume they can use it 😊

We will explore other options for providing the root (such as a prefix prop).

Thanks again!

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.