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

Using link/schema and @graphql-tools/schema in combination and bundled by webpack results in "Cannot use GraphQLSchema from another module or realm" #7184

Closed
stoically opened this issue Oct 17, 2020 · 2 comments · Fixed by #7185

Comments

@stoically
Copy link
Contributor

stoically commented Oct 17, 2020

Intended outcome:

Using SchemaLink with @graphql-tools/schema's makeExecutableSchema works as expected when bundled with webpack

Actual outcome:

Error: Cannot use GraphQLSchema "[object GraphQLSchema]" from another module or realm.

It seems that link/schema pulls in CommonJS instead of ESM when bundled with webpack, so it's different classes.

Related issue in the @graphql-tools repo: ardatan/graphql-tools#1790

How to reproduce the issue:

Minimal repo: https://github.com/stoically/apollo-client-link-schema-webpack

Fix

Instead of directly reaching into graphql like so

import { execute } from 'graphql/execution/execute';
import { GraphQLSchema } from 'graphql/type/schema';

import from the top level, like so

import { execute, GraphQLSchema } from 'graphql';

Though, I guess the actual fix would be to dive into webpack and check what's going wrong

Workaround

webpack.config.js

const path = require("path")

  resolve: {
    alias: {
      "graphql/execution/execute": path.resolve(
        __dirname,
        "./node_modules/graphql/execution/execute.mjs"
      ),
      "graphql/validation/validate": path.resolve(
        __dirname,
        "./node_modules/graphql/validation/validate.mjs"
      ),
    },

Other things I tried which didn't work out

Versions

System:
OS: Linux 5.4 Ubuntu 20.04.1 LTS (Focal Fossa)
Binaries:
Node: 12.18.4 - ~/.nvm/versions/node/v12.18.4/bin/node
Yarn: 1.22.10 - ~/.nvm/versions/node/v12.18.4/bin/yarn
npm: 6.14.8 - ~/.nvm/versions/node/v12.18.4/bin/npm
Browsers:
Chrome: 86.0.4240.75
Firefox: 81.0.2
npmPackages:
@apollo/client: 3.3.0-beta.13 => 3.3.0-beta.13

stoically added a commit to stoically/apollo-client that referenced this issue Oct 17, 2020
@stoically stoically changed the title SchemaLink pulls in CommonJS instead of ESM when bundled with webpack which leads to Error: Cannot use GraphQLSchema Using link/schema and @graphql-tools/schema in combination results in "Cannot use GraphQLSchema from another module or realm" Oct 18, 2020
@stoically stoically changed the title Using link/schema and @graphql-tools/schema in combination results in "Cannot use GraphQLSchema from another module or realm" Using link/schema and @graphql-tools/schema in combination and bundled by webpack results in "Cannot use GraphQLSchema from another module or realm" Oct 18, 2020
benjamn pushed a commit to stoically/apollo-client that referenced this issue Oct 19, 2020
benjamn added a commit to stoically/apollo-client that referenced this issue Oct 19, 2020
Since we don't control the contents of this package, and nested
subdirectories within the graphql package do not have their own
package.json files with "main" and "module" entry points (like our
`@apollo/client/*` sub-packages do), it is unfortunately not safe to reach
into the package to import specific items, as demonstrated by apollographql#7184.

This could cause a bundle size regression for bundlers that do not perform
any tree-shaking, but it's the responsibility of the graphql package
maintainers to support selective sub-package imports if they want to.
Until that happens, @apollo/client must import from the graphql package in
the only supported way: directly from the top-level package.
benjamn pushed a commit that referenced this issue Oct 19, 2020
Since we don't control the contents of the graphql package, and
nested subdirectories within the graphql package do not have their
own package.json files with "main" and "module" entry points (like
our @apollo/client/* sub-packages do), it is unfortunately not safe
to reach into the package to import specific items, as demonstrated
by #7184.

This change could cause a bundle size regression for bundlers that
do not perform any tree-shaking, but it's the responsibility of the graphql
package maintainers to support selective sub-package imports, if they
want to. Until that happens, @apollo/client must import from the graphql
package in the only supported way: directly from the top-level package.
@benjamn
Copy link
Member

benjamn commented Oct 19, 2020

@stoically You can test the changes from #7185 using @apollo/[email protected]. Given that this version appears to fix your reproduction (thanks for that!), we will publish the same changes in v3.2.5 soon, unless you have any remaining reservations.

@stoically
Copy link
Contributor Author

@benjamn Works as expected with 3.3.0-beta.14 for me. Thanks for the fast turnaround and for broadening the scope of the PR including an insightful commit comment! No remaining reservations on my end.

@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.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants