the conclusion from the meeting was to use module patching wherever possible

Problem

JavaScript has two major standards of organizing modules:

CommonJS (CJS) modules, one introduced by the creator of Node.js
ECMA Script Modules (ESM/MJS), one introduced by the standardization committee

ESM is supposed to supersede CJS over time, right now we work with projects that contain dependencies supporting either of them or both.

The interoperability problem is a question on how to ensure that we can use different ESM and CJS dependencies at the same time without compability issues.

If a Next.js project uses the app directory, Next.js will change the SWC loader options for code within the API routes, as explained here: https://github.com/vercel/next.js/blob/2af1e784c290eba505b2de76ab0e83eb110cf30e/packages/next/src/build/webpack-config.ts#L669

We found a problem with one library called libphonenumber-js that, depending on the running environment, is either imported as a CJS module or an ESM one.

The problems seems to be manyfold.

The package.json file available for this library on NPM contains both main and exports definitions
The library contains code that “fixes” the issue with the babel’s default export issue: https://www.npmjs.com/package/babel-plugin-add-module-exports
The problem doesn’t happen at all if a Next.js project doesn’t use the app router