-
Notifications
You must be signed in to change notification settings - Fork 2k
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
esModuleInterop is (should not be) required #1977
Comments
I faced the same issue under [email protected] and found that setting |
@KeithGillette But I agree - I feel like this is a regression - if anyone really wants me to/asks nicely - I can bisect to figure out when this regression was introduced. |
Actually, upon review of the release notes https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html - this might not be an entirely bad idea. That said, it is technically a breaking change, so... that said, fixing the breakage seems to be fairly trivial. (I hope? I am not an expert in ES module systems). |
On a second thought, These options are enabled by {
"compilerOptions": {
"target": "es5",
"module": "commonjs",
"strict": true,
"esModuleInterop": true
}
} |
Relates-to or duplicated-by #1977, #2519, #2521 (and more). Thanks so much for opening this originally. The important thing here is that the consuming project needs to adopt It may be possible to avoid the type errors on an existing project by enabling |
all works good, but when I try to start my server inside the docker, I had this "Error: socket hang up" in postman and this in the console also, API doesn't work on the AWS apollo-server-core: 2.14.0 Does someone have any solution? |
It is one thing for a project to have this, another for a library. All downstream consumers are forced into this setting. To the extent that the library is consumed by other libraries this makes it harder for the community to adopt ES modules proper. I would generally say popular TS libraries should make effort to avoid forcing this option. If it is hard to do so in this case though then maybe not worth it for @abernix. We're grappling with the fallout on |
I need to chime in here and say this logic seems sensible from first glance, but it is not correct
The field is there for compatibility sake, not because CommonJS is somehow being prescribed as the preferred choice by TypeScript. TypeScript correctly follows the ES Module standard, which uses Meanwhile, Node came about before the ES Modules standard was finalized, so they chose the CommonJS standard. Many npm packages were thus created which use Anyways, the future of the language is ES Modules, so everyone should be moving away from CommonJS. Heck even Node.js is starting to transition towards the industry standard ES Modules, and you can bet Deno officially recommends ES Modules and not CommonJS. I doubt Node will ever deprecate their CommonJS support due to their dogmatic adherence to backwards compatibility, but really they should since the JavaScript language has evolved to now have an official standard for modules. ApolloGraphQL should only force all direct and transitive consumers to require If this project wants to correctly not force |
Though IMO, |
I think it's certainly reasonable to consider re-visiting this since this is now several years old, but I would suggest opening a new issue or finding a issue that is open/still open. One hunch is that it might fit well into a larger story around shipping native ECMAScript alongside CJS, or might at least pair well with that work? (e.g., #5627). |
Leaving this for future people who may wander upon this looking for guidance. The TS 2.7 release notes were mentioned upthread, but it's worth calling out that quote from those notes (emphasis theirs):
|
Building without enabling the
esModuleInterop
compiler option:While enabling
esModuleInterop
resolves the issue, I feel it should not be needed? Enabling it requires that all other imports where there is no default export to be updated too (import * as x
vsimport x
). Making this change just for one package seems a bit intrusive. But I may be missing something here though.Related issues: https://github.com/apollographql/apollo-server/issues?utf8=%E2%9C%93&q=is%3Aissue+esModuleInterop
I'm using the latest versions of everything:
The text was updated successfully, but these errors were encountered: