Do not remove custom directives from the model

[lastmjs]

It looks like custom directives that I place into my model are removed in the generated schema. The definitions are not removed, which is nice, but not very useful without keeping the directives themselves. It would be great if custom directives placed in the model could be kept in the generated schema. This was a major pain point with Prisma and implementing permissions with custom directives. They were removed, causing me to have to write a parser to place them back in so that I could have my directives executed against the generated schema, which I imagine is desirable for a variety of use cases.

[wtrocki]

Critical issue. Going to be resolved in the next release

[craicoverflow]

We are using printSchema to convert the schema object to a string before writing to a file. It seems to be expected behaviour that custom directives are not added.

We should use something other than printSchema for this.

[wtrocki]

GraphQL-Toolkit has printSchema with directives.
https://gist.github.com/arjun-kava/0bd38e0c8feec360284677b1ee31728a

Generally, if we were using GraphQL-Compose for that purpose (as everywhere else) we will be fine.

Marking as a critical bug that should be easy to fix.

[craicoverflow]

Directives are getting removed from fields in SchemaComposer. When we add the schema string or object to the constructor as we do now (see example below) then the final schema will have directive definitions, but no directives in use.

import { SchemaComposer } from 'graphql-compose'
import { loadSchemaSync } from '@graphql-toolkit/core';

const schema = loadSchemaSync(`directive @test(
  reason: String = "No longer supported"
) on FIELD_DEFINITION | ENUM_VALUE

type ModifyMe {
  id: ID! @test(reason: "asjdk")
}

type Query {
  hello: ModifyMe
}`, { loaders: [] })

const schemaComposer = new SchemaComposer(schema);

const schemaStr = schemaComposer.toSDL({ exclude: ['ID', 'String', 'Int', 'Boolean', 'Float'] })

console.log(schemaStr)

This can be resolved by adding typedefs string separately:

const schemaString = `directive @test(
  reason: String = "No longer supported"
) on FIELD_DEFINITION | ENUM_VALUE

type ModifyMe {
  id: ID! @test(reason: "asjdk")
}

type Query {
  hello: ModifyMe
}`;

const schemaComposer = new SchemaComposer();

schemaComposer.addTypeDefs(schemaString)

However this method only take a string argument whereas we are operating on a GraphQLSchema object.

The best approach here is operate on a string schema always in Graphback so that we can use addTypeDefs.

For code generation this can be a very minimal change in the CLI, by changing loadSchema(model) to loadSchema(model, 'string'):

graphback/packages/graphback-cli/src/components/generate.ts

Line 74 in 2756b29

const schemaDocument = await project.loadSchema(model);

For runtime this would be a breaking change, since the runtime API accepts string or object, however loading the model from the template should go away in #1071

[wtrocki]

This sounds like good bug to log for graphql-compose. Operating on SDL strings in plugin executor mean that every plugin will need to build schema from SDL which is not ideal.

[craicoverflow]

I've logged graphql-compose/graphql-compose#246

[nodkz]

Should be fixed in [email protected]

Related test case https://github.com/graphql-compose/graphql-compose/blob/master/src/__tests__/github_issues/246-test.js