next/image not working when using in esm projects

[yanush]

Verify canary release

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

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.17.1
      npm: 9.6.7
      Yarn: N/A
      pnpm: N/A
    Relevant Packages:
      next: 13.4.20-canary.12
      eslint-config-next: 13.4.19
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.2.2
    Next.js Config:
      output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

https://github.com/yanush/nextjs_issue_20230830

To Reproduce

• Create a new nextjs app:
  npx create-next-app@latest

Using the following options:

• TypeScript: No

• EsLint: Yes

• Tailwind CSS: No

• src/ directory: No

• App Router: Yes

• import Alias: No

• Edit package.json and add:
  "type": "module",

Edit next.config.js file to match esm:

/** @type {import('next').NextConfig} */
const nextConfig = {}

export default nextConfig;

• try to run project using npm run dev

Describe the Bug

I get these errors:
Warning: React.jsx: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: object.

Check your code at page.js:19.
Warning: React.jsx: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: object.

The errors referring to lines that contain Image Tags

Notice:

• Using the legacy Image works fine (Changing page.js import to: import Image from 'next/legacy/image')

• Changing the project to commonjs also seems to solve the issue

Both of these fixes are not ideal for me

Expected Behavior

Should be working fine with the new image and don't throw errors

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_NEXT-1774

[devjiwonchoi]

type: module is not implemented yet, so for now modify next.config.js as next.config.mjs.
#29935

[yanush]

It was working just fine in previous versions of next.js 13.
Was there any recent change that made it not to work again?

[devjiwonchoi]

@yanush Which specific version was working?

[yanush]

@devjiwonchoi version 13.3.4 with experimental appDir true was working fine, but I'm not sure whether this version was using the legacy image by default

[yanush]

Any updates on this matter?
I hate having to use the legacy image just to keep using esm projects

[karlhorky]

Interesting, we have a working "type": "module" project here which also uses the <Image /> component from next/image:

• https://github.com/upleveled/preflight-test-project-next-js-passing/blob/47c457e8cbeb12ea210f327733be4307822ac464/package.json#L5
• https://github.com/upleveled/preflight-test-project-next-js-passing/blob/47c457e8cbeb12ea210f327733be4307822ac464/next.config.js
• https://github.com/upleveled/preflight-test-project-next-js-passing/blob/47c457e8cbeb12ea210f327733be4307822ac464/app/page.tsx#L1

[karlhorky]

Workaround 1: next/dist/client/image-component import path

Import the <Image> component directly from next/dist/client/image-component:

-import Image from 'next/image';
+import { Image } from 'next/dist/client/image-component';

Workaround 2: .default import property

Assign Image to the .default property of the import

-import Image from 'next/image';
+import ImageModule from 'next/image';

+const Image = ImageModule.default;

export default function Page() {
  return <Image ... />

This works because Image is a CommonJS module, and is not completely unwrapped:

console.log('Image', Image);
// Image { unstable_getImgProps: [Getter], default: [Getter] }

Workaround 3: unstable_getImgProps

Use unstable_getImgProps instead of Image:

-import Image from 'next/image';
+import { unstable_getImgProps } from 'next/image';

export default function Page() {
-  return <Image ... />
+  const { props: imgProps } = unstable_getImgProps({
+    src: '/vercel.svg',
+    alt: 'Vercel Logo',
+    width: 100,
+    height: 24,
+    priority: true,
+  });
+  return <img {...imgProps} />

Workaround 4: Switch page to TypeScript

Change page.js to page.tsx - with TypeScript the <Image /> component does not fail.

[karlhorky]

So I upgraded the original reproduction to next@14.0.3-canary.5 (latest canary at time of writing) and can still confirm the bug when using a JavaScript page via page.js:

1. "type": "module" in package.json
2. app/page.js (JavaScript, not TypeScript)
3. Usage of <Image /> from 'next/image'
4. 💥 Error: Unsupported Server Component type: {...}

Seems like a JS compiler bug?

Updated reproduction PR here:

yanush/nextjs_issue_20230830#1

app/page.js (broken)

app/fixed/page.tsx (fixed) - same code

[karlhorky]

Ah interesting, since this unstable_getImgProps (introduced in #51205 by @styfle ) is also being returned, maybe this creates this problem with ESM:

import Image from 'next/image'; // in ESM project with "type": "module" in package.json

console.log('Image', Image);
// Image { unstable_getImgProps: [Getter], default: [Getter] }

[yanush]

@karlhorky, Thanks for all your suggestions and workaround attempts!

[karlhorky]

Just thinking, one way to get compatibility here without a larger CJS -> ESM transition would be to *also* export a named export for these cases.

Then the following would "just work" in ESM with "type": "module" projects:

import { Image } from 'next/image';

To be clear, for users who want to stay with the default export, the following would still work:

import Image from 'next/image';

cc @feedthejim @shuding would the team be open for such a change? (backwards compatible)

cc @remcohaszing because we were talking about lacking ESM support in Next.js and using named exports

[remcohaszing]

While I personally prefer named exports, I also believe there should be only one way to use an export. Adding a named export is a workaround. There is a deeper problem, this issue is just a symptom. Also it affects pretty much all Next.js exports, not just next/image.

A library (defined as something you import, e.g. next), should not rely on esModuleInterop if it’s compiled to CommonJS.

What really needs to happen, is that code like this:

import React from 'react'

export function unstable_getImgProps() {
  // …
}

export interface ImageProps {
  // …
}

export default function Image(props: ImageProps): React.ReactElement {
  // …
}

needs to be transformed to export = syntax and a namespace.

import * as React from 'react'

namespace Image {
  export function unstable_getImgProps() {
    // …
  }

  export interface ImageProps {
    // …
  }

  // This is for strict backwards compatibility. It’s not needed for typical Next.js users.
  export { Image as default }
}

function Image(props: ImageProps): React.ReactElement {
  // …
}

export = Image

Or go a step further and enable verbatimModuleSyntax:

import React = require('react')

namespace Image {
  export function unstable_getImgProps() {
    // …
  }

  export interface ImageProps {
    // …
  }

  // This is for strict backwards compatibility. It’s not needed for typical Next.js users.
  export { Image as default }
}

function Image(props: ImageProps): React.ReactElement {
  // …
}

export = Image

---

P.s. If Vercel is invested in supporting ESM/TypeScript (which means fixing this), I am for hire to fix this on a freelance contract.