Graphql-code-generator: Types not being generated for gql files with imports

[joshlam]

Note that this is using 1.4.1-alpha-906f6449.78

Describe the bug

It looks like files that import other fragments aren't getting types generated.

Config:

overwrite: true
schema: path/to/schema
documents: src/**/*.gql
generates:
    codegen/graphql.d.ts:
        plugins:
            - 'typescript'
            - 'typescript-operations'
        config:
            namingConvention:
                enumValues: keep
                typeNames: change-case#pascalCase
            preResolveTypes: true
            typesPrefix: I
    codegen/graphql.schema.json:
        plugins:
            - 'fragment-matcher'

If I have two files

src/fragments/clickEventInfo.gql:

fragment clickEventInfo on ClickEvent {
  __typename
  .
  .
  .
}

and
src/fragments/blah.gql:

#import 'src/fragments/clickEventInfo.gql'

fragment blah on Blah {
  clickEvent {
    ...clickEventInfo
  }
}

A type will only be generated for the IClickEventInfoFragment.

Expected behavior

Types to be generated for all documents

[dotansimha]

@joshlam you are using graphql-import, right? I think the syntax should be:

# import clickEventInfo from './clickEventInfo.gql'

Can you please test it?

And even without graphql-import, I think it should work because your are specifying src/**/*.gql and it should catch both files.

[joshlam]

@dotansimha we're using graphql-tag. Tried with relative imports and still not generating. It works fine in v1.4.0, so I'll bisect through the changes between the 1.4.1 prerelease and that version to try to identify the culprit

[dotansimha]

@joshlam any update?
I think it might be related to the change we did in graphql-toolkit recently.
Can you please try 1.4.1-alpha-33fb5f7e.75? (this is before the changes)

[joshlam]

@dotansimha doesn't seem to be the culprit

[dotansimha]

@joshlam
Just tested it. Seems like graphql-import doesn't work with fragments and queries now.

When I'm using *.gql - everything is loaded, so the #import is not relevant at all because the glob matches everything.

When I'm telling the codegen to use 1.gql only, and use import - it doesn't work because the codegen doesn't know about the existence of this fragments, and graphql-import returns an error.

Not sure why it worked before. @joshlam can you please provide a work reproduction? it will be easier to compare the changes.

[jacobheric]

On a related note, we've been testing out the most recent alpha versions (1.4.1-alpha-ad8ddfd9.92 and a few before it) and we've noticed that Typescript React Apollo HOC & Component generation no longer works for any query that imports a fragment. An example query def that no longer works:

#import "./UsersPrefs.gql"

query UserPrefs {
  userPrefs {
    ...UserPrefs
  }
}

This was working fine for us in 1.4.0.

If it helps, I removed the import and HOC/Component generation worked (but of course the query no longer does).

Let me know if you want me to file a separate issue as this is a bit different than the parent as Typescript defs are still working for these, just not the React Apollo stuff.

[dotansimha]

@jacobheric it happens only with imports, right?
I'm not sure what has changed since then. which library is the one that added #import syntax before? it wasn't graphql-import for sure, because it doesn't support GraphQL operations, only schemas.

Using new Source and parse from graphql doesn't seem to support this syntax.

[jacobheric]

@dotansimha, yes we only experience this problem when we use #import in our *.gql fragment and query defs. That syntax is supported by a graphql-tag webpack loader as described here: https://www.apollographql.com/docs/react/recipes/webpack/.

FWIW, I think it has something to do with the upgrade to graphql-toolkit to v0.4.0 or subsequent fixes. The last time HOC/Component generation worked for us is prior to https://github.com/dotansimha/graphql-code-generator/pull/2183.

[dotansimha]

ok I think I figured it out. I think the #import syntax you used has no meaning for the codegen, but your glob pattern was broad enough to load the fragments as well. There was an issue in graphql-toolkit that was trying to load this file using graphql-import and this caused an error (because, it shouldn't handle those types of file), which caused the file to be ignored and not generated.

Fixed in: https://github.com/ardatan/graphql-toolkit/commit/433d3030bab9522b14ee43356f40dceb7b4fe3be

And will merge it to the codegen in: https://github.com/dotansimha/graphql-code-generator/pull/2299

Alpha is available as 1.4.1-alpha-0d9fbe39.93, can you please try it? @joshlam @jacobheric

[jacobheric]

@dotansimha, thanks for looking into it! I tested against 1.4.1-alpha-0d9fbe39.93 and we still get no HOC/component generation whenever #import exists in our query/fragment .gql files.

[dotansimha]

You are right, @jacobheric , the document is detected and it seems like something is not passing it correctly to the plugin. I'm trying to fix.

[dotansimha]

Managed to fix that in https://github.com/dotansimha/graphql-code-generator/commit/680e7b3941fbea29074120eeb5470ba424adddcd

@jacobheric try: 1.4.1-alpha-680e7b39.95

[jacobheric]

@dotansimha, tested our app against 1.4.1-alpha-680e7b39.95 and all React Apollo HOC & Component generations worked even when they contained the graphql-tag webpack loader #import syntax. Thanks for the quick fix!

[joshlam]

@dotansimha, works great on this end too 👍thanks! 🙇

[dotansimha]

Fixed in 1.5.0 🎉