Skip to content
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

Error: "Module '"[...]/@types/react/index"' can only be default-imported using the 'allowSyntheticDefaultImports' flag" #7741

Closed
devrelm opened this issue Feb 20, 2021 · 4 comments · Fixed by #7742

Comments

@devrelm
Copy link
Contributor

devrelm commented Feb 20, 2021

Intended outcome:

I should be able to import @apollo/client without needing allowSyntheticDefaultImports or esModuleInterop set in my tsconfig.

Actual outcome:

When I import @apollo/client without the allowSyntheticDefaultImports and esModuleImports flags set in my tsconfig, I get a series of errors like this:

../../node_modules/@apollo/client/react/context/ApolloConsumer.d.ts:1:8 - error TS1259: Module '"/path/to/project/node_modules/@types/react/index"' can only be default-imported using the 'allowSyntheticDefaultImports' flag

1 import React from 'react';
         ~~~~~

  ../../node_modules/@types/react/index.d.ts:65:1
    65 export = React;
       ~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'allowSyntheticDefaultImports' flag.

Similar errors are produced for both react and zen-observable.

How to reproduce the issue:

To Reproduce:

  1. Install @apollo/client, graphql, and @types/react in a typescript-based repo
  2. Import from @apollo/client (I reproduced with ApolloConsumer, but it should also be reproducible with imports)
  3. Compile the file that imports from @apollo/client using the typescript compiler

Reproduction Example:

  1. Clone https://github.com/devrelm/apollo-client-synthetic-defaults-example
  2. Run yarn run tsc

Versions

  System:
    OS: macOS 10.15.7
  Binaries:
    Node: 12.18.3 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.6 - /usr/local/bin/npm
  Browsers:
    Chrome: 88.0.4324.182
    Firefox: 85.0.1
    Safari: 14.0.2
  npmPackages:
    @apollo/client: ^3.3.11 => 3.3.11

Other Notes

It looks like this has already been brought up a few times but hasn't been totally fixed yet:

  • Fix zen-observable import #7004 PR: "Fix zen-observable import" - closed as the author ended up adding allowSyntheticDefaultImports to fix the error
  • TypeScript error when using client without react #7005 Issue: "TypeScript error when using client without react" - Still open, but I don't think this is necessarily a duplicate issue, as that one is about not using react and so has additional possible solutions. This present issue cannot be solved the same way since I actually do want to use react.
  • 78bc4bc tried to fix the issue, but it was reverted by @benjamn in 113475b with the message This reverts commit [78bc4bc], which caused more problems than it solved.

I'll try to get a PR in to fix the issue, but it would be nice to know how the fix "caused more problems than it solved" so that I could avoid any of the same pitfalls.

devrelm pushed a commit to devrelm/apollo-client that referenced this issue Feb 20, 2021
Fixes apollographql#7741

Using `import React from 'react'` causes issues when the import makes
its way into the d.ts file. Users without `esModuleInterop: true` or
`allowSyntheticDefaultImports: true` (or `skipLibCheck: true`) in
their tsconfig files will get errors from typescript about not being
able to default-import using that syntax.

This PR fixes the specific imports that would cause issues due to
their types being re-exported in `@apollo/client`'s types.
devrelm pushed a commit to devrelm/apollo-client that referenced this issue Feb 21, 2021
Fixes apollographql#7741

Using `import React from 'react'` causes issues when the import makes
its way into the d.ts file. Users without `esModuleInterop: true` or
`allowSyntheticDefaultImports: true` (or `skipLibCheck: true`) in
their tsconfig files will get errors from typescript about not being
able to default-import using that syntax.

This PR fixes the specific imports that would cause issues due to
their types being re-exported in `@apollo/client`'s types.
devrelm pushed a commit to devrelm/apollo-client that referenced this issue Feb 21, 2021
Fixes apollographql#7741

Using `import React from 'react'` causes issues when the import makes
its way into the d.ts file. Users without `esModuleInterop: true` or
`allowSyntheticDefaultImports: true` (or `skipLibCheck: true`) in
their tsconfig files will get errors from typescript about not being
able to default-import using that syntax.

This PR fixes the specific imports that would cause issues due to
their types being re-exported in `@apollo/client`'s types.
devrelm pushed a commit to devrelm/apollo-client that referenced this issue Feb 23, 2021
Fixes apollographql#7741

Using `import React from 'react'` causes issues when the import makes
its way into the d.ts file. Users without `esModuleInterop: true` or
`allowSyntheticDefaultImports: true` (or `skipLibCheck: true`) in
their tsconfig files will get errors from typescript about not being
able to default-import using that syntax.

This PR fixes the specific imports that would cause issues due to
their types being re-exported in `@apollo/client`'s types.
devrelm pushed a commit to devrelm/apollo-client that referenced this issue Feb 23, 2021
Fixes apollographql#7741

Using `import React from 'react'` causes issues when the import makes
its way into the d.ts file. Users without `esModuleInterop: true` or
`allowSyntheticDefaultImports: true` (or `skipLibCheck: true`) in
their tsconfig files will get errors from typescript about not being
able to default-import using that syntax.

This PR fixes the specific imports that would cause issues due to
their types being re-exported in `@apollo/client`'s types.
benjamn pushed a commit to devrelm/apollo-client that referenced this issue Mar 5, 2021
Fixes apollographql#7741

Using `import React from 'react'` causes issues when the import makes
its way into the d.ts file. Users without `esModuleInterop: true` or
`allowSyntheticDefaultImports: true` (or `skipLibCheck: true`) in
their tsconfig files will get errors from typescript about not being
able to default-import using that syntax.

This PR fixes the specific imports that would cause issues due to
their types being re-exported in `@apollo/client`'s types.
benjamn pushed a commit that referenced this issue Mar 5, 2021
Fixes #7741.

Using `import React from 'react'` causes issues when the import makes
its way into the d.ts file. Users without `esModuleInterop: true` or
`allowSyntheticDefaultImports: true` (or `skipLibCheck: true`) in
their tsconfig files will get errors from typescript about not being
able to default-import using that syntax.

This PR fixes the specific imports that would cause issues due to
their types being re-exported in `@apollo/client`'s types.
@benjamn
Copy link
Member

benjamn commented Mar 5, 2021

@devrelm Alas, I think #7742 is affected by the same "problems" that led to my reverting 7584ae9. Clearly I should have left better notes about why that didn't work the last time, and you were right to wonder about the reasoning.

While I agree with the goals behind this issue and #7742, switching to namespace imports seems to confuse bundlers like Rollup, which have trouble figuring out that properties like React.createContext really are exposed on the React namespace object. For example, here's what our Rollup example app prints at build time:

(!) Missing exports
https://rollupjs.org/guide/en/#error-name-is-not-exported-by-module
../../../../dist/react/context/ApolloContext.js
createContext is not exported by ../../../../node_modules/react/index.js
3: var cache = new (canUseWeakMap ? WeakMap : Map)();
4: export function getApolloContext() {
5:   var context = cache.get(React.createContext);
                                   ^
6: 
7:   if (!context) {
../../../../dist/react/context/ApolloContext.js
createContext is not exported by ../../../../node_modules/react/index.js
 6: 
 7:   if (!context) {
 8:     context = React.createContext({});
                        ^
 9:     context.displayName = 'ApolloContext';
10:     cache.set(React.createContext, context);
../../../../dist/react/context/ApolloContext.js
createContext is not exported by ../../../../node_modules/react/index.js
 8:     context = React.createContext({});
 9:     context.displayName = 'ApolloContext';
10:     cache.set(React.createContext, context);
                        ^
11:   }
../../../../dist/react/context/ApolloConsumer.js
createElement is not exported by ../../../../node_modules/react/index.js
4: export var ApolloConsumer = function (props) {
5:   var ApolloContext = getApolloContext();
6:   return React.createElement(ApolloContext.Consumer, null, function (context) {
                  ^
7:     "production" === "production" ? invariant(context && context.client, 28) : invariant(context && context.client, 'Could not find "client" in the context of ApolloConsumer. ' + 'Wrap the root component in an <ApolloProvider>.');
8:     return props.children(context.client);
../../../../dist/react/context/ApolloProvider.js
createElement is not exported by ../../../../node_modules/react/index.js
 6:       children = _a.children;
 7:   var ApolloContext = getApolloContext();
 8:   return React.createElement(ApolloContext.Consumer, null, function (context) {
                   ^
 9:     if (context === void 0) {
10:       context = {};
../../../../dist/react/context/ApolloProvider.js
createElement is not exported by ../../../../node_modules/react/index.js
18: 
19:     "production" === "production" ? invariant(context.client, 29) : invariant(context.client, 'ApolloProvider was not passed a client instance. Make ' + 'sure you pass in your client via the "client" prop.');
20:     return React.createElement(ApolloContext.Provider, {
                     ^
21:       value: context
22:     }, children);

I don't currently know of a good solution for this problem, so please let me know if you have any insights. Unfortunately, since these errors would cause problems for existing applications, while this issue (#7741) is one that existing applications are already coping with (for better or worse), I think we might have to revert PR #7742 if we can't find a better solution.

benjamn referenced this issue Mar 5, 2021
This reverts commit 78bc4bc, which caused
more problems than it solved.
@benjamn benjamn mentioned this issue Mar 5, 2021
@benjamn

This comment has been minimized.

@benjamn
Copy link
Member

benjamn commented Mar 9, 2021

@devrelm Okay, thankfully I was able to resolve the Rollup problem just by tweaking the rollup.config.js file in 16b08e1, so I withdraw my concerns about #7742. While I was at it, I also added some more details to the CHANGELOG.md: e280fe2

@hwillson
Copy link
Member

A fix for this is coming in @apollo/client@3.4, which will be published soon. Thanks!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants