Next.js: _next/image 404 on next build && next export

Created on 28 Oct 2020  路  17Comments  路  Source: vercel/next.js

Bug report

Describe the bug

Images are 404 on next build && next export. Works properly next build && next start

To Reproduce

  1. npx create-next-app --example image-component image-app
  2. cd image-app
  3. npx next build && npx next export && cd out && npx serve
  4. visit localhost:5000

Screenshots

image

System information

  • OS: macOS Mojave
  • Version of Next.js: [e.g. 10.0.0]
  • Version of Node.js: [e.g. 12.18.4]
bug 3 p0

Most helpful comment

@Timer that should be listed on the documentation as well. I had the same realization as everybody here, I thought that the image would just work.

All 17 comments

Screenshot 2020-10-28 at 3 24 35 PM
Same for me too.

OS: macOS Mojave
Version of Next.js: v10
Version of Node.js: v12.17.0

In the development mode, it's working fine. But when using next export. the images are broken.

same for me. On localhost it's ok but not on Netlify

Instead of optimizing images at build time, Next.js 10 optimizes images on-demand, as users request them. Unlike static site generators and static-only solutions, your build times aren't increased, whether shipping 10 images or 10 million images.

I guess it probably requires the node server.

Also /_next/image?url=%2Fimages%2Fpicture.png&w=1200&q=75 this is what the endpoint looks like so it makes sense.

Passing the unoptimized prop should fix that, but at the expense of losing most of the benefits (no srcset added).

The image component would have to have some sort of static generation mode, where it would function like gatsby-image, and generate the optimized image at build time.

I think if you are using some sort of external service, such as Imgix, this shouldn't be an issue for built times, as it should be able to just generate the urls needed, and doesn't need to actually generate the images themselves.

I haven't used it, but I think the react-imgix component does this today.

I believe the solution here is to fail next export unless if you configure a 3rd party image optimizer service (can't use the default one as it requires next start).

I am having this problem as well trying to deploy on Netlify. Could anyone explain why this doesn't show up after exporting and running next start locally?

@Timer that should be listed on the documentation as well. I had the same realization as everybody here, I thought that the image would just work.

I tried to use next-on-netlify and that doesn't seem to work either. Maybe the serverless handlers that are outputted also don't have the processor?

This post helped me understand and compare next/image and next-optimized-images
https://dev.to/jameswallis/next-image-and-next-optimized-images-a-brief-comparison-4c4i

Any solution to this?

@Jaynam07: I ended up not using next/image, but instead using next-optimized-images. I didn't find any other solution right now, I'm hoping it will be supported at some point (or at least Netlify adds support to next-on-netlify).

We'll need to add something like this to packages/next/export/index.ts:

  if (!options.buildExport) {
    const isDefaultImageLoader =
      !nextConfig.images.loader || nextConfig.images.loader === 'default'
    if (isDefaultImageLoader) {
      Log.error(
        "next export cannot be used with Next.js' default image loader, as it relies on `next start`."
      )
      // stop export ...
    }
  }

However, it's tricky because we cannot error for projects that don't use next/image at all鈥攖his would be a breaking change.

So I take it the Next Image component will generate the correct URLs/srcsets from Cloud providers which have their own loader. In which case, next export and next/image will be fine.

For those of us serving from a CMS which does not have its own loader in Next/Image, can we expect them to be added in the future? Many CMS CDNs also have on-the-fly image optimization.

As it stands, Cloudinary/Imgix/Akamai loaders are baked into the component, but it wouldn't really be feasible to add loaders for all the other providers like that.

We'll need to add something like this to packages/next/export/index.ts:

  if (!options.buildExport) {
    const isDefaultImageLoader =
      !nextConfig.images.loader || nextConfig.images.loader === 'default'
    if (isDefaultImageLoader) {
      Log.error(
        "next export cannot be used with Next.js' default image loader, as it relies on `next start`."
      )
      // stop export ...
    }
  }

However, it's tricky because we cannot error for projects that don't use next/image at all鈥攖his would be a breaking change.

That will show an error during next export I presume, but what about actually generate the images during the next export (and not just for next start)?

Yeah - ideally this would both be a noisy failure and also not-completely-broken... I think it's a good idea to both:

  1. Generate a warning/error on export (since you are going to lose a bunch of the features like automatic resizing and translation into webp). This will let the developer know they're probably making a mistake.

  2. But also fix the static export so that the component generates a functional <img> tag instead of the broken one it now outputs.

We'll need to add something like this to packages/next/export/index.ts:

  if (!options.buildExport) {
    const isDefaultImageLoader =
      !nextConfig.images.loader || nextConfig.images.loader === 'default'
    if (isDefaultImageLoader) {
      Log.error(
        "next export cannot be used with Next.js' default image loader, as it relies on `next start`."
      )
      // stop export ...
    }
  }

However, it's tricky because we cannot error for projects that don't use next/image at all鈥攖his would be a breaking change.

That will show an error during next export I presume, but what about actually generate the images during the next export (and not just for next start)?

This will slow the build process, but a great idea. Better to implement with a separate option in the config file to optimize images during export.

Well, so no plans to support build-time generation of optimized images so that next export聽works properly?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  路  3Comments

rauchg picture rauchg  路  3Comments

kenji4569 picture kenji4569  路  3Comments

formula349 picture formula349  路  3Comments

sospedra picture sospedra  路  3Comments