Next 14: Specified module format (CommonJs) is not matching the module format of the source code (EcmaScript Modules) #2579

dominik-sfl · 2024-05-28T06:01:30Z

dominik-sfl
May 28, 2024

In my newly installed next.js app (14.2.3), using create-t3-app, I get the following error when I import jotai's Provider & wrap it around its children:

⨯ ModuleBuildError: ./node_modules/jotai/esm/react.mjs/proxy.js
Specified module format (CommonJs) is not matching the module format of the source code (EcmaScript Modules)
The CommonJs module format was specified in the package.json that is affecting this source file or by using an special extension, but Ecmascript import/export syntax is used in the source code.
The module was automatically converted to an EcmaScript module, but that is in conflict with the specified module format. Either change the "type" field in the package.json or replace EcmaScript import/export syntax with CommonJs syntas in the source file.
In some cases EcmaScript import/export syntax is added by an transform and isn't actually part of the source code. In these cases revisit transformation options to inject the correct syntax.

Simply by doing this:

<html
      lang="en"
      className={`font-sans ${GeistMono.variable} ${noto_sans.variable}`}
    >
        <body>
          <TRPCReactProvider>
            <Provider>
              {children}
            </Provider>
          </TRPCReactProvider>
        </body>
    </html>

TS Config (default t3 tsconfig)

{
  "compilerOptions": {
    /* Base Options: */
    "esModuleInterop": true,
    "skipLibCheck": true,
    "target": "es2022",
    "allowJs": true,
    "resolveJsonModule": true,
    "moduleDetection": "force",
    "isolatedModules": true,

    /* Strictness */
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "checkJs": true,

    /* Bundled projects */
    "lib": ["dom", "dom.iterable", "ES2022"],
    "noEmit": true,
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "jsx": "preserve",
    "plugins": [{ "name": "next" }],
    "incremental": true,

    /* Path Aliases */
    "baseUrl": ".",
    "paths": {
      "~/*": ["./src/*"]
    }
  },
  "include": [
    ".eslintrc.cjs",
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx",
    "**/*.cjs",
    "**/*.js",
    ".next/types/**/*.ts"
  ],
  "exclude": ["node_modules"]
}

Anyone know what's going on here? :/

dai-shi · 2024-05-29T00:17:00Z

dai-shi
May 29, 2024
Maintainer

Hm, I've never seen such an error message. Would you be able to create a reproduction with StackBlitz?

10 replies

matzkoh Jun 19, 2024

@dai-shi

I installed version 2.8.3 and tested it multiple times by adding and removing "type": "commonjs", from node_modules/jotai/package.json. It worked when I removed it!

dai-shi Jun 19, 2024
Maintainer

Oh, that's very very great to know!

Now I wonder if it's turbo's issue. Would anyone like to report it to them?

The rationale is publint warns it: https://publint.dev/rules#use_type

saoudi-h Dec 20, 2024

Oh, that's very very great to know!

Now I wonder if it's turbo's issue. Would anyone like to report it to them?

The rationale is publint warns it: https://publint.dev/rules#use_type

Hi,

I opened an issue on the Next.js repo issue:74062

The Next.js team has already proposed a fix, and it might resolve this incompatibility

dai-shi Dec 20, 2024
Maintainer

Thanks!

saoudi-h Dec 20, 2024

No problem!

danimrangelb · 2024-05-30T07:12:02Z

danimrangelb
May 30, 2024

Same here! @dominik-sfl are you using turbo?

0 replies

sansan-sakura · 2024-06-05T03:06:51Z

sansan-sakura
Jun 5, 2024

I got the same error using turbo. @dominik-sfl @danimrangelb Has anyone solved this issue?

0 replies

mikko-kohtala · 2024-06-06T15:25:52Z

mikko-kohtala
Jun 6, 2024

We got the same error when upgrading from 2.8.0 to 2.8.1. Happens also with the latest 2.8.3. We are using turbo.

Kind of big project, but most of the dependencies are at the latest. Some notable deps:

"next": "14.2.3",
"next-auth": "5.0.0-beta.19",
trpc @ 11.0.0-rc.390

Happy to answer any questions.

1 reply

dai-shi Jun 9, 2024
Maintainer

when upgrading from 2.8.0 to 2.8.1

That's great info.
v2.8.0 works, and v2.8.1 breaks it, right?

https://github.com/pmndrs/jotai/releases/tag/v2.8.1
Unfortunately, I'm not sure which change can be related.

https://github.com/pmndrs/jotai/pull/2563/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R147
Maybe, the update of esbuild can be something?

dai-shi · 2024-06-19T12:19:06Z

dai-shi
Jun 19, 2024
Maintainer

I made a draft PR to remove the type field in package.json, but we don't plan to merge it as of now: #2626

9 replies

dai-shi Oct 17, 2024
Maintainer

For now, I keep updating #2626 if that helps.

Does anybody know if Next 15 rc does something different?

theogravity Oct 17, 2024

It does not do anything differently - we're on next 15 RC

dai-shi Oct 18, 2024
Maintainer

That's unfortunate. Did anyone file an issue in the next repo?

lamualfa Dec 13, 2024

For now, I keep updating #2626 if that helps.

Does anybody know if Next 15 rc does something different?

@dai-shi Error when using jotai in Next.js 15.0.4-canary.52 & 15.1.1-canary.2 (I've tried 2 versions):

⨯ ./node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/jotai/esm/react.mjs/proxy.js
Specified module format (CommonJs) is not matching the module format of the source code (EcmaScript Modules)
The CommonJs module format was specified in the package.json that is affecting this source file or by using an special extension, but Ecmascript import/export syntax is used in the source code.
The module was automatically converted to an EcmaScript module, but that is in conflict with the specified module format. Either change the "type" field in the package.json or replace EcmaScript import/export syntax with CommonJs syntas in the source file.
In some cases EcmaScript import/export syntax is added by an transform and isn't actually part of the source code. In these cases revisit transformation options to inject the correct syntax.



./node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/jotai/esm/react/utils.mjs/proxy.js
Specified module format (CommonJs) is not matching the module format of the source code (EcmaScript Modules)
The CommonJs module format was specified in the package.json that is affecting this source file or by using an special extension, but Ecmascript import/export syntax is used in the source code.
The module was automatically converted to an EcmaScript module, but that is in conflict with the specified module format. Either change the "type" field in the package.json or replace EcmaScript import/export syntax with CommonJs syntas in the source file.
In some cases EcmaScript import/export syntax is added by an transform and isn't actually part of the source code. In these cases revisit transformation options to inject the correct syntax.

dai-shi Dec 13, 2024
Maintainer

It looks like a different error message we've been discussing.
I'm not sure but /proxy.js has .js extension, which might be a problem. If it were .mjs, the "type" field doesn't matter.

theogravity · 2024-08-16T22:18:32Z

theogravity
Aug 16, 2024

I was able to edit out "type": "commonjs" using the pnpm package patcher:

https://pnpm.io/cli/patch

Doing this fixed it.

2 replies

mycolaos Oct 16, 2024

You edited jotai package.json?

guseggert Oct 23, 2024

Similarly for NPM I used patch-package.

Go into node_modules/jotai/package.json, remove the "type": "commonjs" line
Run npx patch-package jotai --exclude nothing to create the patch file
Add "postinstall": "patch-package" to package.json

cchin25 · 2024-10-16T11:01:23Z

cchin25
Oct 16, 2024

Just for anyone googling, just ran into this with next 14.2.4 and jotai 2.10.1 when using the --turbo flag when running dev.

4 replies

jonathanwilke Oct 22, 2024

Yeah same for me with the latest version of Next.js (15.0.0). Were you able to resolve this with the --turbo flag?

sleeporsmile Oct 23, 2024

Yeah same for me with the latest version of Next.js (15.0.0). Were you able to resolve this with the --turbo flag?

same issue

cchin25 Oct 23, 2024

Yeah same for me with the latest version of Next.js (15.0.0). Were you able to resolve this with the --turbo flag?

I was unable to, but tbh I didn't put much effort into it. At the time I just ended up removing the --turbo flag. Ultimately for unrelated reasons I switched to Zustand.

songkeys Oct 29, 2024

I removed the --turbo flag and it's still the same.

SebasScript · 2024-11-01T06:37:34Z

SebasScript
Nov 1, 2024

Also ran into same issue spinning up a new Next.js 15.0.2 using Turbo in dev mode.
Downgrading Jotai to 2.8.0 as mentioned earlier in the thread gets around the type error as workaround

0 replies

songkeys · 2024-11-06T21:18:57Z

songkeys
Nov 6, 2024

To fix this using pnpm:

Prepare for patching:

pnpm patch jotai

Open package.json:

open node_modules/.pnpm_patches/[email protected]/package.json

Remove this line (L5):

{
  "name": "jotai",
  "description": "👻 Primitive and flexible state management for React",
  "private": false,
-  "type": "commonjs",
  "version": "2.10.1",
  "main": "./index.js",

Path this commit:

pnpm patch-commit 'node_modules/.pnpm_patches/[email protected]'

Now it should work though I don't know why.

See: https://pnpm.io/cli/patch

0 replies

8spw · 2024-12-19T12:37:14Z

8spw
Dec 19, 2024

That happens when you are using jotai in SSR, make sure put "use client" in top of component

1 reply

lubieowoce Dec 20, 2024

note that this is not required, jotai already includes a "use client" in their code -- this is just a workaround that happens to sidestep the next.js bug (specifically, the bug shouldn't be triggered if jotai is only ever imported from client modules). i'm hoping we'll have a fix merged/released soon, and then your "use client" may not be necessary anymore.

miruji · 2025-01-01T15:43:22Z

miruji
Jan 1, 2025

The only thing that helped me was using dynamic loading without ssr, which guarantees full operation on the client

0 replies

saoudi-h · 2025-01-08T13:28:20Z

saoudi-h
Jan 8, 2025

Hi everyone,

Just a quick update: this issue has been fixed in Next.js 15.1.4. No more workarounds or patches are needed.

Details here: Next.js PR #74608.

1 reply

lubieowoce Jan 8, 2025

I was going to post it here too, thanks :)
For the folks who are still on v14, we've also backported this fix (and others) in 14.2.23.

Uh oh!

Next 14: Specified module format (CommonJs) is not matching the module format of the source code (EcmaScript Modules) #2579

Uh oh!

Uh oh!

Replies: 12 comments · 28 replies

Uh oh!

dai-shi May 29, 2024 Maintainer

Uh oh!

Uh oh!

dai-shi Jun 19, 2024 Maintainer

Uh oh!

Uh oh!

dai-shi Dec 20, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dai-shi Jun 9, 2024 Maintainer

Uh oh!

dai-shi Jun 19, 2024 Maintainer

Uh oh!

dai-shi Oct 17, 2024 Maintainer

Uh oh!

Uh oh!

dai-shi Oct 18, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

dai-shi Dec 13, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 12 comments 28 replies

dai-shi
May 29, 2024
Maintainer

dai-shi Jun 19, 2024
Maintainer

dai-shi Dec 20, 2024
Maintainer

dai-shi Jun 9, 2024
Maintainer

dai-shi
Jun 19, 2024
Maintainer

dai-shi Oct 17, 2024
Maintainer

dai-shi Oct 18, 2024
Maintainer

dai-shi Dec 13, 2024
Maintainer