Expose some way to set swc's noInterop

[cprussin]

Goals

1. Expose some way to set swc's noInterop setting.

Non-Goals

1. Make noInterop a default (or make it easy / obvious to set or supported in any serious capacity)

Background

Currently, using Typescript's nodenext module resolution strategy is not feasible with next.js. The root of the problem is:

• swc's interop mode hoists exports under the .default key up to the root of the module if the .__esModule property is set on a cjs module.
• Typescript follows Node's resolution strategy when using nodenext (that's the purpose of the setting after all), and in particular this means it does not hoist regardless of the presence of .__esModule.
• Next.js doesn't expose any way to set swc options, or any way to set noInterop to disable the interop behavior.

As a result, even if someone was OK with adding .default to a bunch of imported stuff, they still couldn't use the nodenext resolution strategy.

There is a workaround, which involves doing something like this every time someone imports a default export from a cjs package that has the .__esModule property set:

import _x from "x";
const x = _x as unknown as typeof _x.default;

But that's far from ideal and isn't really accurate (it's kind of lying to typescript about what's happening here).

This issue is a pain point for a few reasons:

• The nodenext resolution strategy forces some things like specifying extensions, explicitly declaring index.js, etc. It's super easy (and Typescript recommends) to use nodenext in non-bundled environments. However, since next doesn't support it, it's easy to accidentally write a bunch code that then cannot easily be later moved into a node package that is built with nodenext if such a need arises. Being able to turn it on now makes code more amenable to such reorganizations.
• Using nodenext is a great way to help find issues with typings & with the ESM distribution of dual-distributed packages and help fix those issues (which go unnoticed when using the node resolution strategy).

Proposal

Expose some option that ends up setting noInterop in getBaseSWCOptions. Probably something obtuse and dangerous sounding, like experimental.unsupportedDisableSwcInteropIKnowWhatImDoingAndWontRequestSupport or whatever.

I'm happy to contribute the change but would like advice on if it would be accepted.