Latest release broke Next.js project with mixed CJS/ESM modules

The issue is reproducible by creating a starter Next.js app (using either the pages or the app router), and creating the following files:

First, a regular ESM module that imports and uses react-select

/* file: components/Select.jsx */

import Select from "react-select";

const options = [
  { value: "chocolate", label: "Chocolate" },
  { value: "strawberry", label: "Strawberry" },
  { value: "vanilla", label: "Vanilla" },
];

export const MyComponent = () => <Select options={options} />;

Then, a CJS module requires it and re-exports it (in my real-world use case, this module actually does something with the component rather than just re-exporting the original one, but that's not relevant here)

/* file: components/Select2.js */
const { MyComponent } = require("./select");

module.exports = {
  MyComponent,
};

And finally, a page imports and renders it

/* file: pages/testingPage.jsx */

import { MyComponent } from "../comps/select2.js";

export default () => (
  <>
    <MyComponent />
  </>
);

This results in an Invalid Component error (expected ... but got undefined) error, but only during server-side rendering. If we tell Next to only render this on the client, it works fine.

This worked fine before 5.7.3.

Trying to dig in a bit more, I discovered that in the generated server bundle (inside the .next dir) imports to react-select were being compiled to dynamic import() calls (the ones that resolve to promises), whereas in versions before 5.7.3 it got compiled to normal require calls, as expected.

Reproduce the issue in a starter Next.js app using components/Select.jsx, components/Select2.js, and pages/testingPage.jsx. Compare the generated server bundle in .next between 5.7.3 and an earlier version, focusing on react-select imports becoming dynamic import() calls. Done means the mixed CJS/ESM example renders successfully during server-side rendering.