-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add esModuleInterop? #8
Comments
Is it really needed when the TS package is native ESM? I remember using that flag in the past and it caused a lot of problems. |
It’s probably primarily needed when importing a CJS module or exporting as a CJS module, but overall it seems like it’s the ESM setup that the TS team intends to be its default but for extreme backwards compatibility reasons doesn’t dare to change into the default |
Taking a look on the tsconfig recommended bases is interesting here. The baseline and NodeJS 12 version both include When taking a look on the deno base Personally: As soon as one module has |
Does anyone know the TypeScript teams intention here? I’ve tried to figure it out at it all pointed me to |
ESM-code: TS-code: They should both really be the same, but yeah, that would probably require all users of the types to also adopt |
esModuleInterop breaks exports node usage when importing your module. In short it lets you The flag should probably only be used in projects that are not meant to be imported or uploaded to npm. Unfortunately I don't have an alternative solution, you'll have to look in TypeScript's repo to find how they're dealing with it. Webpack for example recently added support for the createRequire pattern, so tools are slowly catching up. |
From: https://www.typescriptlang.org/tsconfig#esModuleInterop @fregante It's still the recommended option by the TypeScript team and its still as far as I can tell their intended fix for becoming more interoperable with the ESM landscape. Is there a bug tracking the behavior you are mentioning? If not, can you mentioning it in microsoft/TypeScript#41139 and/or a dedicated issue? The current limbo situation of |
Since this is still open, I want to reiterated that this is likely still a bad idea as a default.
My rule for this:
I think more context can be found in: |
To make things even more interesting, TypeScript 4.5 looks likely to add two new Purpose of those are to eg. ensure that And most relevant to this thread:
|
🎉
😰 That seems to contradict the first part. Does that mean that the information I posted is outdated? I think node was exactly the problem back then. Maybe the issue was CJS transpilation, which isn't the default in this configuration anymore 🤔 |
I know that @bmeck asked a possibly relevant question over there (microsoft/TypeScript#44501 (comment)) referencing a comment he made to my very issue that I started our thread here with |
|
This shipped and since this config now uses Actual code in TS for it: https://github.com/microsoft/TypeScript/blob/2bcfed01f3458996e71ce37af43e3495cb7e4950/src/compiler/utilities.ts#L6428-L6438 |
I think this is fine because the "node16" config I think is annoyingly strict so this kind of interop doesn't really cause issues. 👍 |
See microsoft/TypeScript#41139
As stated in https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html#support-for-import-d-from-cjs-from-commonjs-modules-with---esmoduleinterop:
Should make TS and ESM work better together.
The text was updated successfully, but these errors were encountered: