RFC: Extra property on field definition to pass extra metadata

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: https://github.com/graphql/graphql-js/blob/81719749e01f030cfb3a01a97e7e4bfc534bb08f/src/type/definition.js#L720-L724

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]

It took longer than I planned but I finally merged it in #2097 Thanks for patience 🙇 I will try to cut release today/tomorrow

[IvanGoncharov]

Should we mutate this object later (by using (schema.getType(“typeName”) as GraphQLObjectType).getFields()[“fieldName”].complexity = 5;) or is it safe to rely on …fieldConfig behavior in that case?

@19majkel94 It should work fine as a workaround until we ship an extensions solution however no long-term guarantees afterward.

I will work on adding immutable extensions into types, fields, args and enum values on next week so we will be able to ship it in 14.2.0.