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 [email protected] (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.

[karlhorky]

Would be amazing if full ESM support was fixed in Next.js 👍 Maybe Vercel would sponsor this (considerable) effort

Originally, "type": "module" support was added by @timneutkens in this PR:

• Add support for "type": "module" in package.json #33637

Basic support for ESM with TypeScript 'NodeNext' or 'Node16' module resolution added by @loettz here:

• Add support for tsconfig 'nodenext' | 'node16' #44177

But since then, there have been a number of issues, pull requests and discussions showing problems with ESM support (sometimes in combination with the TypeScript 'NodeNext' or 'Node16' module resolution), just a small sampling:

• (this issue) next/image not working when using in esm projects #54777
• Custom cache handler doesn't work with ESM #58509
• next/lib/find-config does not support ESM config files #34448
• Next incorrectly requires the common.js version of the package when ES version is present #37419
• feat: use ESM-CJS interoperable import in find-config #34451
• Switch to .cjs PostCSS config #58380
• fix: make typescript imports work with nodenext module resolution #50357
• [NEXT-782] dynamic import() with node16 .js extensions cannot be resolved #46678
• moduleResolution: nodenext | node16 doesn't work #41189

cc @kachkaev @cseas because you have also been active in some issues and discussions

[karlhorky]

If this work to make the next package ESM-ready for most cases were to go ahead, I would suggest also including the following tools as part of the verification:

Are The Types Wrong? by @andrewbranch

publint by @bluwy

[karlhorky]

Oh and it would be great if new end to end tests were added to verify continued ESM support as time goes on and new features get added.

Ideas for end to end tests:

1. A "type": "module" project mixing JavaScript and TypeScript with some commonly-used patterns such as importing next/image, next/link, including Tailwind CSS + PostCSS configuration
2. Usage of some static analysis tooling on published package artifacts such as the command line packages publint and @arethetypeswrong/cli

[karlhorky]

@huozhi thanks for the fix in #59852

I can confirm that [email protected] resolves the Unsupported Server Component type error, at least with next/image 🙌 :

---

Broken with [email protected] (Unsupported Server Component type error)

CodeSandbox demo: https://codesandbox.io/p/devbox/esm-js-import-bug-w-next-image-14-0-5-canary-24-773jvq?file=%2Fpnpm-lock.yaml%3A10%2C62

---

Working with [email protected]

CodeSandbox demo: https://codesandbox.io/p/devbox/esm-js-import-bug-w-next-image-14-0-5-canary-25-x58yz8?file=%2Fpnpm-lock.yaml%3A10%2C62

[github-actions]

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