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?

7 replies

matzkoh Jun 14, 2024

I used pkg.csb.dev to identify which commit introduced this error. Everything worked fine up until before #2548.

cjimmy Jun 17, 2024

sorry, i'm not very familiar with turbo.

Turbopack is a webpack replacement, used by Nextjs, but not yet generally available. However, it appears that it will be the default bundler in the near future for Nextjs. So, this particular issue may not be worth addressing now, but it will be a larger issue within the next year (my guess).

See also: #2579 (reply in thread)

I can confirm that downgrading to jotai 2.8.0 works with turbopack

Can you check if this works for you?

I still get the same issue on the minimal repro when I install #2555 and run pnpm dev --turbo

dai-shi Jun 18, 2024
Maintainer

Thanks a lot, guys. I didn't expect #2548 changed something significant.
Can you dig it a deeper and find what exactly causes the problem?

Perhaps adding "commonjs"? https://github.com/pmndrs/jotai/pull/2548/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R5

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

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

pitkane · 2024-06-06T15:25:52Z

pitkane
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

7 replies

dai-shi Aug 16, 2024
Maintainer

https://publint.dev/rules#use_type

Node.js v21.1.0 adds a new --experimental-detect-module, which can be used to automatically run ES modules when ESM syntax can be detected. Node.js hopes to make detection enabled by default in the future. Detection increases startup time, so Node is encouraging everyone — especially package authors — to add a type field to package.json, even for the default "type": "commonjs".

gpxl-dev Oct 17, 2024

I also hit this and would prefer not to have to downgrade.

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?

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

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

Replies: 9 comments · 21 replies

dai-shi May 29, 2024 Maintainer

dai-shi Jun 18, 2024 Maintainer

dai-shi Jun 19, 2024 Maintainer

dai-shi Jun 9, 2024 Maintainer

dai-shi Jun 19, 2024 Maintainer

dai-shi Aug 16, 2024 Maintainer

dai-shi Oct 17, 2024 Maintainer

dai-shi Oct 18, 2024 Maintainer

Replies: 9 comments 21 replies

dai-shi
May 29, 2024
Maintainer

dai-shi Jun 18, 2024
Maintainer

dai-shi Jun 19, 2024
Maintainer

dai-shi Jun 9, 2024
Maintainer

dai-shi
Jun 19, 2024
Maintainer

dai-shi Aug 16, 2024
Maintainer

dai-shi Oct 17, 2024
Maintainer

dai-shi Oct 18, 2024
Maintainer