This is another attempt at solving #40891 following the discussion starting with #40892 (comment). The previous attempt is #40892 and I made a different PR because they're different solutions and have pros and cons.

This PR adds an option "importInterop" to package.json. When enabled, import statements in that package will behave slightly different with respect to default exports if the imported module is CJS.

• When the imported module defines module.exports.__esModule as a truthy value, the value of module.exports.default is used as the default export.
• Otherwise, module.exports is used as the default export. (existing behavior)

It allows better interoperation between full ES modules and CJS modules
transformed from ES modules by Babel or tsc. Consider the following
example:

// Transformed from:
// export default "Hello";
Object.defineProperty(module.exports, "__esModule", { value: true });
module.exports.default = "Hello";

When imported from the following module:

import greeting from "./hello.cjs";
console.log(greeting);

with the following package.json:

{
  "type": "module",
  "importInterop": true
}

Then it will print "Hello".

Fixes: #40891

Unlike the previous approach, it doesn't (and doesn't intend to) change the default behavior. It still solves the problem illustrated in #40891 because only ESM → CJS boundaries are problematic and such boundaries will most likely emerge when the importing package is migrating from CJS to ESM. Even if the imported package is inactive, it is easy to configure the importing package as it is the package that is migrating to ESM.

I used getPackageScopeConfig to retrieve package.json. I think it is a reliable one because it is already used in #path/to/alias imports. I'm unsure about its performance implication, but the effect is limited to ESM → CJS edges.