ESM interoperability issue (default.default export)

[JulianKingman]

Environment

 System:
    OS: macOS 14.6.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 84.56 MB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.20.4 - ~/.nvm/versions/node/v18.20.4/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v18.20.4/bin/yarn
    npm: 10.7.0 - ~/.nvm/versions/node/v18.20.4/bin/npm
    pnpm: 9.10.0 - ~/.nvm/versions/node/v18.20.4/bin/pnpm
    bun: 1.1.0 - ~/.bun/bin/bun
    Watchman: 2024.08.26.00 - /opt/homebrew/bin/watchman
  Browsers:
    Brave Browser: 123.1.64.122
    Chrome: 125.0.6422.142
    Safari: 17.6
  npmPackages:
    next: latest => 14.2.14 
    next-auth: latest => 4.24.8 
    react: ^18.3.1 => 18.3.1 

Reproduction URL

https://github.com/CollaborativeEconomics/monorepo/tree/next-auth-esm-issue

Describe the issue

When importing next-auth through several layers of ESM packages, when it reaches the nextJS app, default exports arrive wrapped in an object like this: { default: defaultExport }

After many dead ends and hours of searching, I found a concise explanation of what the issue is: evanw/esbuild#1719 (comment)

I'm not 100% sure what the solution is, but it seems that next-auth is getting compiled to CJS with __esModule set to true, which causes unpredictable behavior, depending on which compiler is handling it.

How to reproduce

I'm currently experiencing this in my monorepo. Run npx turbo install && npx turbo build in the root directory, you will see the build fails because CredentialsProvider is importing as { default: [Function function] }, rather than [Function function].

Expected behavior

Expected behavior would be that it imports the default without wrapping it. This appears to be a quirk of Webpack, and I'm working on how to work around it, but the fundamental solution appears to be in changing the way the package (next-auth) is compiled.

Additional info:

https://arethetypeswrong.github.io/?p=next-auth%404.24.8

[balazsorban44]

Hi, for backwards compatibility reasons, changing a module output format is a breaking change, so we cannot change this for v4.

V5 however is distributed as ESM-only and you could expect no such interop issues.

https://arethetypeswrong.github.io/?p=next-auth%405.0.0-beta.22

No plans of ever supporting CJS again. It's the past. Packages should put it behind their back and follow one standard. 🌶️

[JulianKingman]

Agreed! The irony is that this issue prevented me from moving my project to ESM only 😕

That said, there should be a way to make this a non-breaking change, by just adding an extra export. I'm not sure what settings would need to change, but as it says here, you would replace code like this:

Object.defineProperty(exports, "__esModule", { value: true });
exports.default = function f() {
  /* ... */
};

with code like this:

Object.defineProperty(exports, "__esModule", { value: true });
function f() {
  /* ... */
}
module.exports = f;
module.exports.default = f;

This compatibility pattern has an odd effect where f.default.default.default... out to infinity is equal to f, but nonetheless, all runtimes and bundlers will bind a default import of the module to a callable f.

If you're open to it I can see what's needed and make a PR