Nextjs fails to detect ESM modules correctly when using exports in package.json

[Pagebakers]

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 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000
Binaries:
  Node: 16.16.0
  npm: 8.11.0
  Yarn: 1.22.15
  pnpm: 7.5.2
Relevant packages:
  next: 12.2.4
  eslint-config-next: 12.2.4
  react: 18.2.0
  react-dom: 18.2.0

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

Describe the Bug

Next.js fails to resolve sub dependencies correctly and tries to load CJS from ESM modules, causing the build to fail.

SyntaxError: Named export 'theme' not found. The requested module '@chakra-ui/react' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

@chakra-ui/react a dependency of @saas-ui/react

Saas UI uses exports definition in package.json to define package entries and exports the ESM module as default.

{
  "exports": {
    ".": {
      "require": "./dist/index.js",
      "default": "./dist/index.modern.mjs"
    },
    "./src": {
      "default": "./src/index.ts"
    }
  },
  "main": "./dist/index.js",
  "module": "./dist/index.modern.mjs",
  "types": "./dist/index.d.ts"
}

Removing exports or changing default to import fixes the issue.

However I think Next.js should handle this correctly.

Expected Behavior

Next.js resolves all packages correctly as ESM.

Link to reproduction

https://github.com/msnegurski/test-saas-ui

To Reproduce

1. Clone the repo.
2. npm i
3. npm run dev

Make sure @saas-ui/react@1.2.x is installed (not 1.3)

_NEXT-1381

[Pagebakers]

After some more testing the .mjs extension seems to cause issues, renaming the esm files to .js resolves the issues.

[balazsorban44]

Thanks, I was first going to suggest upgrading the packages to 1.3 as it seems to have been fixed, but I saw that you are the maintainer, so you are likely here to get an answer why saas-js/saas-ui@f6ec7dc was needed.

When ESM resolution is enabled, the work is handed off to the Node.js resolver:

The general rule is that conditions should be from most specific to least specific in object order.

Given that import and require are mutually exclusive on the same specificity level and default is just a fallback (the least specific), I assume require gets picked instead of default as it's higher specificity. I think it's correct to assume that require and import should always be used together.

All examples I have seen define both import and require.

Webpack's guidelines also suggest avoiding default:

Avoid the default export. It's handled differently between tooling.

Resources:

• https://webpack.js.org/guides/package-exports/#conditions
• https://webpack.js.org/guides/package-exports/#guidelines
• https://nodejs.org/api/packages.html#conditional-exports
• https://nodejs.org/api/esm.html#resolver-algorithm

[Pagebakers]

Thanks @balazsorban44

This issue is related to: chakra-ui/chakra-ui#6436

Chakra UI uses .js extension for ESM modules. Any other package that depends on Chakra UI and uses .mjs extension for ESM modules will run into this error. Renaming all .mjs files to .js in @saas-ui/react ultimately resolved it for now, but this is more a workaround then a solution imho.

I looked into framer as well, which had a similar issue open with Next.js last year. They are using require (.js) and default (.mjs) without any issues, so that doesn't seem to be the problem.

#30750

Here to proposed solution was to use .mjs.

I'm not sure what is going on, but anyway the compiler behaviour changes based on which extension is used for ESM modules, while the package.json definitions are the same, as well as the code of the modules.

[balazsorban44]

As far as I can tell, Framer does not have require or default, but 🤔:

"type": "module",
"exports": {
  ".": "./build/index.js",
  "./package.json": "./package.json",
  "./*": "./build/*"
},

https://unpkg.com/browse/framer@2.1.3/package.json

[balazsorban44]

Sorry, probably the wrong package above. framer-motion has this:

"exports": {
".": {
  "require": "./dist/cjs/index.js",
  "import": {
    "types": "./dist/index.d.ts",
    "default": "./dist/es/index.mjs"
  },
  "default": "./dist/cjs/index.js"
  },
"./package.json": "./package.json"
},

https://unpkg.com/browse/framer-motion@7.0.0/package.json

So actually they use both import and require.

[Pagebakers]

Ok, my bad I misread this yesterday.

Then we can agree using both 'import' and 'require' is the way to go, leaves us only with the question why the compiler behaves different with .js and .mjs file extensions for es modules.

[balazsorban44]

Do you mean saas-js/saas-ui@a43204d?

If you want to signal Node.js to treat your .js files as ESM, you need to set type: "module" at the top level.

The "type" field defines the module format that Node.js uses for all .js files that have that package.json file as their nearest parent.

https://nodejs.org/api/packages.html#type

UPDATE:

Oh, it's the other way around. 🤔 You fixed it by going from .mjs to .js. Hmm.

Also, If using .mjs, the type config is ignored:

Regardless of the value of the "type" field, .mjs files are always treated as ES modules and .cjs files are always treated as CommonJS.

[Pagebakers]

So if no .mjs are found (even though type = module , or 'import' is defined, it will always treat the package as cjs?

[Pagebakers]

So if no .mjs are found (even though type = module , or 'import' is defined, it will always treat the package as cjs?

[balazsorban44]

Not sure yet, will have to investigate further.