Type 'ArrayBuffer' is not assignable to type 'string'. when using local image.

[adriangalilea]

Bug report

Following the example to use a local file I get:

Type 'ArrayBuffer' is not assignable to type 'string'.ts(2322)
index.d.ts(2869, 9): The expected type comes from property 'src' which is declared here on type 'DetailedHTMLProps<ImgHTMLAttributes<HTMLImageElement>, HTMLImageElement>'

Seems to work fine tho

Reproduction

Following the guide using local images

export async function GET(request: Request) {
  const imageData = await fetch(
    new URL("./logo-black.png", import.meta.url),
  ).then((res) => res.arrayBuffer());

  return new ImageResponse(
    (
      <div
        style={{
          display: "flex",
          background: "#f6f6f6",
          width: "100%",
          height: "100%",
          flexDirection: "column",
          justifyContent: "center",
          alignItems: "center",
        }}
      >
        <img width="256" height="256" src={imageData} />
      </div>
    ),
    {
      width: 1200,
      height: 630,
    },
  );
  
}

Additional Context

Latest next.js version and og/image

[souporserious]

I tried overriding the global JSX namespace to add the ArrayBuffer type, but couldn't get it to work. It's a little more verbose, but you can base64 it to turn it into a string to get around this type error:

<img
  width="256"
  height="256"
  src={`data:image/png;base64,${Buffer.from(imageData).toString('base64')}`}
/>

Not ideal, but alternatively you can use any:

<img src={imageData as any} />

[shuding]

Yeah this is unfortunately something Satori can't work around. If it provides a .d.ts to allow Buffer/ArrayBuffer values for img tag's src field, it will be a global TypeScript override and will affect other JSX code.

Unless TS gives us a way to affect global types of a scoped value (e.g. JSX values passed into satori(...)), there's nothing Satori can do here.

[adriangalilea]

@shuding https://vercel.com/docs/functions/og-image-generation/og-image-examples#using-a-local-image
This link seems to be broken, in any case, considering it can not be fixed, my suggestion is to add a disclaimer in the docs, wherever they are now.