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

3 replies

malixswoop Jun 25, 2024

Thanks, downgrading to 2.8.0

theogravity Aug 16, 2024

Is there a reason to have it there? Trying 2.9.3 and have the same issue (using in a pnpm monorepo with turbo + next.js using --turbo flag).

Edit: I see. I would personally favor compatibility over startup performance.

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".

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.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 6 comments 11 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

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

Replies: 6 comments · 11 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

Replies: 6 comments 11 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