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

External fragments are not pulled into the query document using the loader. #53

Closed
un33k opened this issue Feb 23, 2017 · 10 comments
Closed
Assignees

Comments

@un33k
Copy link

un33k commented Feb 23, 2017

The fragments are not pulled into the query document using the loader.

Example:

# ContactFragment.gql
fragment Contact on ContactType {
    phone
    email
}
# UserInfo.gql
fragment UserInfo on UserInfoType {
    id
    name
    contact {
        address
        ...Contact
    }
}
# User.gql
query User($email: String) {
  user(email: $email) {
    ...UserInfo
  }
}
# Users.gql
query Users($emails: [String]) {
  users(emails: $emails) {
    ...UserInfo
  }
}
// Both of the following Nodes fail when used with apollo client.
The error is: `Unknown fragment \"UserInfo\".`

const UserQueryNode: DocumentNode = require('graphql-tag/loader!../../graphql/User.gql');
const UsersQueryNode: DocumentNode = require('graphql-tag/loader!../../graphql/Users.gql');

The apollo-codegen handles the above scenario well when generating the schema.ts file.
However, graphql-tag/loader is unable to insert the fragments in this example.

One thing to notice is that graphql-tag/loader works well when the fragments are also located in the same file as the query that is referencing them.

The fragments should be pulled in via the loader, however, that is not the case as per this issue.

So, we need the fragments to be in separate files and apollo-codegen handles them properly when compiling the schema.ts. We just have to ensure that the loader in this module is also properly including them in each query.

=====
Version:
"graphql-tag": "^1.2.4",
node: 6.9.5
os: darwin x64

@czert
Copy link
Contributor

czert commented Feb 23, 2017

You can use the new import syntax, as in:

#import "./UserInfo.gql"
query Users($emails: [String]) {
...

Does that help?

@un33k
Copy link
Author

un33k commented Feb 25, 2017

@czert -- Not working - This is run under Angular CLI & Webpack. With no access to modify Webpack's config to add the loader, Webpack errors saying it doesn't know how to load the (fragment) file.

Only if the loader could invoke itself to load the fragments recursively, all would work fine.

I believe that this line may be the culprit.

@czert
Copy link
Contributor

czert commented Feb 25, 2017

@un33k setting up webpack so that it uses graphql-tag/loader for all *.gql imports should help, i think.

@un33k
Copy link
Author

un33k commented Feb 25, 2017

@czert as I mentioned above, Webpack config is handled by Angular CLI. So at this time, there is no way to pass the loader option to Webpack.

@espoal
Copy link

espoal commented May 4, 2017

I think it might be related to this
#76

@jnwng
Copy link
Contributor

jnwng commented May 9, 2017

also related to #64 and failing test PR submitted here: #65

@jnwng jnwng self-assigned this May 9, 2017
@jnwng
Copy link
Contributor

jnwng commented May 16, 2017

@un33k without using the #import syntax, there's no way for us to be able to pull in the required fragment definition - with the webpack loader, each document is treated (and compiled) separately, with no knowledge of previous iterations.

in particular, we have trouble with the case where the webpack loader compiles a graphql document which includes a fragment that we have not yet discovered; there's no way for us to "wait" until the entire tree of modules has been crawled to then fulfill the fragment definition. i had some thoughts around having a webpack plugin that could handle resolving across the entire project, but it would lead to duplicate fragments (and in general felt like a lot of work).

the newest version of [email protected] has a few fixes for the webpack loader, so its possible that that may resolve this as well. going to close this with the recommendation to use the #import syntax (which just falls back to the normal "require" resolution)

@jnwng jnwng closed this as completed May 16, 2017
@un33k
Copy link
Author

un33k commented Jul 22, 2017

@jnwng if the loader does batch processing, then there is no need for any inclusion tags. On the first pass, it loads all files and caches all fragments & actions. Then it loops through the actions and populates the fragments. In the case of duplicates, a flag can be set to let the last win or raise an error. This is done at the start of your app, and only once.

@ravishivt
Copy link

Same issue here. I was able to add the graphql-tag/loader to Angular CLI's webpack build without ejecting using ngx-build-plus.

webpack.partial.js:

module.exports = {
  module: {
    rules: [
      {
        test: /\.(graphql|gql)$/,
        exclude: /node_modules/,
        loader: 'graphql-tag/loader',
      },
    ],
  },
};

@gustavonikov
Copy link

gustavonikov commented Aug 22, 2022

Guys, I'm having a problem using this loader as well, I'm trying to pre-process the queries using webpack, but, seems that the fragment import is not working, gonna share my problem if anyone has any idea of what is going on:

My fragment filefragment.graphql:

image

My query file query.graphql:

image

My webpack config file (using rails webpack to import):

image

image

Still doesn't recognize the fragment saying: 'Unknown fragment autoCompleteFields'

EDIT: saw that the error is thrown by this function:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants