feat(gatsby): allow referencing derived types in schema customization

[pieh]

Changes:

• bump to get fix in graphql-compose ( fix: don't try to instantiate GraphQLType when getting name of named type composer graphql-compose/graphql-compose#373 )
• swap schema printer to use TypeComposers instead of graphql-js types - we do print schema before all "derived types" (such as our various filter and sort inputs etc) are created. This meant we couldn't ever reference such derived types and be able to print schema, because at the time of printing the type doesn't exist yet (causing printing to throw). I did try initially moving printing to after we create derived types but this changed too many things - it started printing everything and then we were getting exceptions that we try to create types reserved for Gatsby -

  gatsby/packages/gatsby/src/schema/schema.js

  Lines 591 to 607 in d846f89

  	const checkIsAllowedTypeName = name => {
  	invariant(
  	name !== `Node`,
  	`The GraphQL type \`Node\` is reserved for internal use.`
  	)
  	invariant(
  	!name.endsWith(`FilterInput`) && !name.endsWith(`SortInput`),
  	`GraphQL type names ending with "FilterInput" or "SortInput" are ` +
  	`reserved for internal use. Please rename \`${name}\`.`
  	)
  	invariant(
  	![`Boolean`, `Date`, `Float`, `ID`, `Int`, `JSON`, `String`].includes(name),
  	`The GraphQL type \`${name}\` is reserved for internal use by ` +
  	`built-in scalar types.`
  	)
  	assertValidName(name)
  	}

  )
• minor fix when we apply deprecation on sort fields that use arguments

[sc-46064]

[pieh]

all snapshot changes are additive - I expanded tests to include more cases

[pieh]

Github doesn't show full picture in the diff by default as rest of the code is few lines below but this change is because

gatsby/packages/gatsby/src/schema/types/sort.ts

Lines 67 to 78 in d846f89

	Object.keys(fields).forEach(fieldName => {
	const fieldConfig = fields[fieldName]
	const sortable =
	typeComposer instanceof UnionTypeComposer ||
	typeComposer instanceof ScalarTypeComposer
	? undefined
	: typeComposer.getFieldExtension(fieldName, `sortable`)
	if (sortable === SORTABLE_ENUM.NOT_SORTABLE) {
	return
	} else if (sortable === SORTABLE_ENUM.DEPRECATED_SORTABLE) {
	deprecationReason = `Sorting on fields that need arguments to resolve is deprecated.`
	}

In particular on line 77 once a field is marked as deprecated, all the remaining fields in current iteration are also deprecated

For example:

type Foo {
  field1: Int # this is fine
  field2(arg1: Int): Int # this sets `deprecationReason`
  field3: Int # this should be fine, but currently marked as deprecated
}

[LekoArts]

Does this fix #31523 ?

[pieh]

Most likely, yes - at least comments about fields that don't have arguments but still causing this deprecation to show up

[pieh]

I can move this to separate PR as this change is not dependend on rest of this PR, I did add it here as this warning was part of "issues" I encountered when working on rest of the changes here. The main problem for me was that Graphiql was not autosuggesting fields due to them being deprecated, but it was still working if I manually typed them in

[LekoArts]

Can stay in imo, I was just curious :)

[pieh]

TS was complaining, because all possible types in NamedTypeComposer were handled. Also we never actually passed typeName to this function

[wardpeet]

Added some questions around typings