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

Type extension does not work #42

Open
pie6k opened this Issue Jan 11, 2018 · 14 comments

Comments

Projects
None yet
@pie6k

pie6k commented Jan 11, 2018

Assume

main.graphql

# import * from "./User.graphql"
type Query {
  apiVersion: String!
}

User.graphql

type User {
  name: String!
}
extend type Query {
  me: User!
}

In resulting compiled schema Query has only version. There is no me field added.

@kbrandwijk

This comment has been minimized.

Contributor

kbrandwijk commented Jan 11, 2018

This is a limitation coming from graphql: graphql/graphql-js#922. I believe that extend definitions should be taken into consideration, but there has not been any recent activity on actually making that happen.

@Huvik

This comment has been minimized.

Huvik commented Jan 15, 2018

I would like it too, it could be great feature 👍

@marktani

This comment has been minimized.

marktani commented Jan 15, 2018

A similar but different use case is extending imported types (like User) by a field:

# import * from "./User.graphql"
extend type User {
  extraField: String!
}

Does this work?

@kbrandwijk

This comment has been minimized.

Contributor

kbrandwijk commented Jan 15, 2018

No that's the same situation. The extend definition is simply ignored by graphql when we read in the schema. This is something that needs to be implemented by graphql-js first. We use parse() from graphql to read in the schema.

@schickling

This comment has been minimized.

Member

schickling commented Jan 15, 2018

@IvanGoncharov any idea when this functionality will land?

@pie6k

This comment has been minimized.

pie6k commented Jan 15, 2018

Good use case of this could be having many files in project extending query and mutation type as it would lead to well organized, modular files structure.

@mwoelk

This comment has been minimized.

Contributor

mwoelk commented Jan 16, 2018

Right now we can simulate the behavior at least for Query-, Mutation- and Subscription-Type by importing like:

# import Query.* from a.graphql
# import Query.* from b.graphql

Take a look at the following test cases:

@IvanGoncharov

This comment has been minimized.

IvanGoncharov commented Jan 16, 2018

@IvanGoncharov any idea when this functionality will land?

@schickling As always then somebody implements it 😄
Note: graphql/graphql-js#1199 introduce a big change in how extend works so it's better to wait until it either merged or rejected.

@divyenduz

This comment has been minimized.

Contributor

divyenduz commented Jan 29, 2018

Another use case for this would be to extend and add "future" stuff (say, that Prisma is yet to implement like prisma/prisma#60).

Currently, I am copying the original type from prisma.graphql and adding "future" fields to it but this will make that chunk of code more beautiful 👍

@mjdickinson

This comment has been minimized.

mjdickinson commented Feb 1, 2018

I need this too. I have managed to work around by just loading .graphql files myself and passing an array of strings to makeExecutableSchema() (and using extend type Query etc. to avoid multiple declaration errors). graphql-tools and graphql seem to handle the type extensions fine.

@ACollectionOfAtoms

This comment has been minimized.

ACollectionOfAtoms commented Feb 8, 2018

I got around this in the following way (though it may be a pain to refactor once extend is fixed up):

in A.graphql

type A {
    name: String!
}

type Query { # notice all we have to do is omit 'extend'
   AbyName(name: String!): A
}

in schema.graphql

# import * from 'A.graphql'
# and import the whole thing as above

type Query {
   someRootQuery(thing: String!): A
}

So this way each file can be modular in that they will contain all their own Querys and Mutations etc.

@Grmiade

This comment has been minimized.

Grmiade commented May 19, 2018

Any news about extend compatibility in this package?

...
import { importSchema } from 'graphql-import'

const server = new GraphQLServer({
    context,
    resolvers: {
      Employee: {
        test: () => 'okok',
      },
      Query: {
        employee: (_root, args, context, info) => {
          return context.myBinding.query.employee(args, info)
        },
      },
    },
    typeDefs: [importSchema('./src/schema.graphql'), `extend type Employee { test: String }`],
  })

If I use extend feature outside the graphql-import scope, it works

@james-ff

This comment has been minimized.

james-ff commented Sep 13, 2018

I think @Grmiade has correctly identified the issue in the last comment. In my use case I am following guides on merging schemas https://www.apollographql.com/docs/graphql-tools/schema-stitching.html. This requires a typeDefs definition that only contains 'extend type' blocks to effectively bridge two schemas.

const linkTypeDefs = `extend type FirstSchemaEntity { test: SecondSchemaEntity }`

When used in literal form as in the above comment it works. But it doesn't work and errors when the extend typeDefs definition is imported via importSchema, in the below example.

const linkTypeDefs = importSchema('./linkTypeDefs.graphql')
@JulienKode

This comment has been minimized.

JulienKode commented Nov 10, 2018

Any update or workaround ?

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