squoosh crash on static import png

[akomm]

What version of Next.js are you using?

11.0.1

What version of Node.js are you using?

14.15.0

What browser are you using?

firefox

What operating system are you using?

linux

How are you deploying your application?

other

Describe the Bug

static import of png:

Error: `unwrap_throw` failed
    at <anonymous>:wasm-function[168]:0x165c5
    at decode (<anonymous>:wasm-function[7]:0x9e7c)

$ grep unwrap_throw -r node_modules
binary file: node_modules/next/dist/next-server/server/lib/squoosh/png/squoosh_png_bg.wasm
binary file: node_modules/next/dist/next-server/server/lib/squoosh/png/squoosh_oxipng_bg.wasm

Expected Behavior

no error

To Reproduce

statically import a png file and use the import in jsx/tsx code

[akomm]

It does not affect all PNG files it seems. Had to many different bugs last few days, currently no time debugging another one (this one comes just after another one fixed with the static import of images and right into the next bug ;( )
If you can't find the reason, I might come back later when I have the time. I hope the info is enough though...

[akomm]

Might be this: GoogleChromeLabs/squoosh#1057

[velvetkevorkian]

I'm also seeing this in Ubuntu in WSL as we upgrade to Next 11.0.1 -- even images that don't throw an error in the build process are showing up with encoding errors in the browser.

As a workaround it looks like you can disable static images in next.config.js

  images: {
    // https://github.com/vercel/next.js/issues/26527
    disableStaticImages: true,
  },

and use Webpack asset modules instead, e.g.

webpack: (config) => {
    const assetRegex = new RegExp(`.(png|jpe?g|gif|woff|woff2|ico|svg)$`)

    config.module.rules.push({
      test: assetRegex,
      type: 'asset/resource',
      generator: {
        filename: './static/assets/[name]-[contenthash].[ext]',
      },
    })

    return config
  }

[ipy]

Thanks to @velvetkevorkian 's solution, while using TypeScript I have to use additional loaders to conform the new typings defined for images.

    const assetRegex = new RegExp(`.(png|jpe?g|gif|woff|woff2|ico|svg)$`);
    config.module.rules.push({
      test: assetRegex,
      use: [
        {
          loader: 'string-replace-loader',
          options: {
            search: 'export default (.*)',
            replace: (_, src) =>
              `export default { src: ${src.replace(/;$/, '')} }`,
            flags: 'm',
          },
        },
        {
          loader: 'url-loader',
          options: { outputPath: './static/assets/' },
        },
      ],
      type: 'javascript/auto',
    });

import img from 'path/to/image.png';

<img src={img.src} />

[dperetti]

I think it may have to do with the image ratio.

Both jpg and png images below make the build crash.

When using the jpg image, the error is:

Error: Call retries were exceeded

When using the png image, the error is:

Error: `unwrap_throw` failed
    at <anonymous>:wasm-function[168]:0x165c5
    at encode (<anonymous>:wasm-function[9]:0xbdf5)

[dperetti]

Kudos to @leerob 👍

yarn add next@canary sharp

Fixes the issue for me.

[akomm]

@dperetti AFAIK it adds an option to use an alternative transformer. Because I'v looked through canary pre-release change-logs and so far did not see fix for this in general. Obviously this option is nice for those who are blocked by this issue!

Regarding this issue:

If it is related to the previously linked issue, nextjs team could fix this generally, by bumping squoosh version used.

[styfle]

This has been fixed in v11.1.3-canary.46.

You can try it out today with yarn add next@canary, thanks!

[jakelazaroff]

Just a heads up, I don't think bumping squoosh solved the issue, at least on macOS. Here's a minimal test case with next@11.1.3-canary.68: https://codesandbox.io/s/weathered-rain-5lpnh (note that you have to download as a zip and run yarn build, unless there's some way to do that in CodeSandbox that I'm unaware of).

If you yarn add sharp and then yarn build, it works.

[KevinShiCA]

FYI this seems to be broken on next@11.1.3-canary.97 again, even with sharp installed. Going back to next@11.1.3-canary.68 as suggested by @jakelazaroff fixes it.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.