TS should provide a way to patch buggy package.json files of dependents (ESM use of "moduleResolution": "nodenext" is not plausible during transition from CJS to ESM)

[rosskevin]

Bug Report

🔎 Search Terms

ESM
project.json main
exports

🕗 Version & Regression Information

4.7.2 this is new and experimental according to the handbook

⏯ Playground Link

https://github.com/rosskevin/ts-esm-workspaces/tree/apollo-exports

💻 Code

"moduleResolution": "nodenext" vs "moduleResolution": "node" for modules targeting pure ESM output is not possible because ANY dependency that does not meet the standard e.g. properly defined exports will fail to build.

🙁 Actual behavior

We can use "moduleResolution": "node" to build a project with non-ESM dependencies, but we cannot use "moduleResolution": "nodenext" to build a project with any non-ESM dependency. IF you use "moduleResolution": "node", you MUST FAKE main behavior for typescript project references to build. This causes a multiplier effect of bad signals that a CJS main is present when that is clearly not the case.

If you have one single dependency that does not meet the spec, your build will fail and you cannot use "moduleResolution": "nodenext".

If a project has hundreds of dependencies, the likelihood it has A SINGLE DEPENDENCY that does not meet the ESM exports standard IS INCREDIBLY HIGH!

🙂 Expected behavior

In order to facilitate a transition to pure ESM modules, typescript should hybridize moduleResolution to allow a distinct transition period wherein faulty ESM targeted modules are allowed to be recognized, similar to node resolution.

@reference #49266 (comment)
@cc @milesj @weswigham

Ultimately, it seems like typescript MUST DECIDE TO BECOME an interop to allow for this transition period from CJS to ESM, otherwise it is bound to cause immense pain, 100x, to the community. Typescript is the vessel to mediate this issue, and I request they seek this as a primary goal. I agree that this is not to spec, but what about a flag? HOW did esModuleInterop come to pass? I request the same consideration. esmInterop: true should be a thing, shouldn't it?

[weswigham]

HOW did esModuleInterop come to pass?

To interoperate with babel modules. And babel designed it with the intent it would interoperate with real esm modules. But it doesn't, because of some parts of the node module interop scheme (like being completely unable to import esm synchronously). So, years of people planning to try to be compatible with what node can do just now and, ultimately, failing. :)

[weswigham]

faulty ESM targeted modules are allowed to be recognized, similar to node resolution

node resolution doesn't have considerations like this - it just reflects the commonjs resolution algorithm circa node 10 or so. It pretty much reflects how your code will behave in old node.

[weswigham]

I've changed the title and tagging of this issue to reflect what I think the OP is essentially asking for. I'm not too bullish on something built into TS, though, since upstreaming a fix to the buggy package would be ideal, and following that, you could always patch the buggy package.json locally with something like patch-package. I don't think there's too much we could offer beyond this - export maps are just somewhat complicated and easily misused.