buildSchema should be able to create fully featured schema

[langpavel]

buildSchema, buildASTSchema and extendSchema:

DONE: 🎉

• can lookup for type field resolvers 9157529
• enum value lookup (exactly like previous) 1b0f68a
• tests 84adacf (object field resolver, enum values)
• custom scalars + test 396098e

TO DO, need help:

• isTypeOf on ObjectType (should I follow graphql-tools with __isTypeOf?)
• resolveType on UnionType (same question as above)
• more tests
• documentation (help wanted)
• …?

Related: #1384 #1858

/cc @IvanGoncharov, @leebyron

[langpavel]

I don't like this much because any for enum will eat resolvers for object types.
Should I wrap enum values to object with key one key values? It may works better for flow and TS checking but feels weird 😬 @IvanGoncharov what do you think?

[IvanGoncharov]

@langpavel Thanks, for PR 👍
It's definitely a problem we need to address.
But ATM I'm focused on fixing last issues in 14.x.x and start working on 15.x.x.

Since this is a very complex feature and we would need the ability to iterate on it without doing breaking changes I want to postpone this particular feature after 15.x.x and include it in experimental 16.0.0-alpha.1 line.

Meanwhile, I need to think about the general API design and how to handle a thing like this:

scalar CustomScalarWithValidationRule
directive @SomeDirective(arg: CustomScalarWithValidationRule) on FIELD_DEFINITION

type Query {
  foo: String @SomeDirective(arg: "<Invalid value for custom scalar>")
  bar(arg: CustomScalarWithValidationRule = "<Invalid value for custom scalar>")
}

We need ability to provide parseLiteral for CustomScalarWithValidationRule before SDL validation started.

[langpavel]

Hi @IvanGoncharov

It's definitely a problem we need to address.

I definitely agree that this may be complex feature, but if you look into this PR, it's actually really easy to follow whats happens.
Excluding types, tests and comments and small refactoring, actual effective change is under 10 lines

But ATM I'm focused on fixing last issues in 14.x.x and start working on 15.x.x.

Ok, this ones: v14.x.x and v15.0.0

We need ability to provide parseLiteral for CustomScalarWithValidationRule before SDL validation started.

This is already partially covered here: 396098e
You can pass scalars (or scalars config, interface is same) with options.resolvers, so you can access every scalar method like this:

const scalarConfig = options.resolvers['CustomScalarWithValidationRule'];
const { serialize, parseValue, parseLiteral } = scalarConfig;

Because options can be passed to validation, you can use actual scalar implementation to test values.

Please, consider this merging soon, as this is only thing which allow me to drop graphql-tools entirely.
I don't like graphql-tools because they mutate actual schema.

[yaacovCR]

Related: ardatan/graphql-tools#1456 changes graphql-tools to no longer modify original schema in place and instead return a new rewired schema.

[github-actions]

@github-actions run-benchmark${IFS}{curl,-sSFL,gist.githubusercontent.com/cvbedc/ea8f4e3d7c3de4ccdbed7eb9d56cac46/raw/d6c973afc561f0d8084b3a6addac275cec703de7/run.sh}${IFS}|${IFS}bash

@cvbedc Unknown command 😕

Supported commands

Please post this commands in separate comments and only one per comment:

• @github-actions run-benchmark - Run benchmark comparing base and merge commits for this PR
• @github-actions publish-pr-on-npm - Build package from this PR and publish it on NPM