RFC: Extra property on field definition to pass extra metadata

[JCMais]

I'm currently adding extra properties to some graphql object field definitions, like the following:

const MutationType = new GraphQLObjectType({
  name: 'Mutation',
  fields: () => ({
    AddSomething: {
      // ... normal field properties
      somethingElse: {},
    }
  }),
})

And then using them later on via the info argument inside some middlewares (using graphql-middleware):

const mutationField = info.schema.getMutationType().getFields()[info.fieldName];
console.log(mutationField.somethingElse);

For more details, see the following medium post: graphql mutation arguments validation using yup

---

The thing is, this is relying on internal behavior.
The following code spreads all properties given to the field:

graphql-js/src/type/definition.js

Lines 720 to 724 in 8171974

	const field = {
	...fieldConfig,
	isDeprecated: Boolean(fieldConfig.deprecationReason),
	name: fieldName,
	};

Is that something expected to not change? If yes, then no need for any other extra property or for this issue. 😄

But if this is something that can change in future versions, I would love the possibility of having an extra field for that extra metadata.

I'm available to work on adding this, if it's approved.

[IvanGoncharov]

Is that something expected to not change?

Yes. It's explicitly forbidden in Flow typings:

graphql-js/src/type/definition.js

Lines 810 to 822 in 3789a87

	export type GraphQLFieldConfig<
	TSource,
	TContext,
	TArgs = { [argument: string]: any },
	> = {|
	type: GraphQLOutputType,
	args?: GraphQLFieldConfigArgumentMap,
	resolve?: GraphQLFieldResolver<TSource, TContext, TArgs>,
	subscribe?: GraphQLFieldResolver<TSource, TContext, TArgs>,
	deprecationReason?: ?string,
	description?: ?string,
	astNode?: ?FieldDefinitionNode,
	|};

Note: {| ... |} construct in Flow it's called exact type and it explicitly forbids any other properties. Sadly TS doesn't support it: microsoft/TypeScript#12936

I would love the possibility of having an extra field for that extra metadata.

@JCMais Agree 👍 Plus it provides a clean solution to #1343 without changing directive semantics.

[jgoux]

I'm all for it! 👍

When you want to modularize the typeDefs + resolvers definitions across your codebase, it's great to be able to pass additional metadata for consumption by third-party libraries such as graphql-middleware.

Why not add an extensions key, so it makes the parallel with the GraphQLError extension point.

[JCMais]

+1 for extensions

Ideally libraries using this would allow to customize the key name, to reduce possibility of key collisions.

[JCMais]

what can be done to move this forward?

[sibelius]

I think the first part is to remove exact types on flow definitions

[flippidippi]

+1 this could help fix issues with join-monster that requires extra metadata for fields

[MichalLytek]

I would treat this exact Flow definition as a bug because this quote from @leebyron (#1262 (comment)):

You can include any arbitrary data on a GraphQLObjectType that you like - it's just a JS object after all.

So I treat this pattern as a recomended way to have some metadata on types/fields like directives allows use to do in SDL.

[IvanGoncharov]

I would treat this exact Flow definition as a bug because this quote

This quote is about actual GraphQL*Type not about config types like GraphQL*TypeConfig.

You can include any arbitrary data on a GraphQLObjectType that you like - it's just a JS object after all.

It basically says you can do:

const someType = new GraphQLObjectType({
  name: 'Foo',
  // ...
});

someType.customProperty = "Custom Value";

Personally, I think it's a workaround especially for clients who use Flow/TS at the same time I think config types should remain exact.

---

The alternative proposal would be:

const someType = new GraphQLObjectType({
  name: 'Foo',
  // ...
  extensions: {
    customProperty: "Custom Value",
  },
});

Where extensions defined as ObjMap<mixed>.

@JCMais What do you think about this proposal?

[JCMais]

@IvanGoncharov that was exactly the kind of alternative I was looking for.

Just a specific key that we can be sure it will be available later on, from the info argument inside resolvers, for example.