consider not deprecating typeInfo and getFieldDef options to validate function and TypeInfo constructor

https://github.com/graphql/graphql-js/blob/e1726dfea66979bfe7ad1c0b0834613e4b6ce4b4/src/validation/validate.ts#L44-L45 https://github.com/graphql/graphql-js/blob/e1726dfea66979bfe7ad1c0b0834613e4b6ce4b4/src/utilities/TypeInfo.ts#L66-L67

From what I understand, by preserving these options, we add the ability for a server to add custom meta fields such as __fulfilled or __directive and still validate properly.

[IvanGoncharov]

As agreed I reverted both PRs until we discussed it on a WG.

As soon as https://github.com/graphql/graphql-js/pull/85 is merged, I will add an agenda item to discuss this further at the next WG.

Please go ahead, I merged https://github.com/graphql/graphql-js-wg/pull/85 I suggest having two separate discussions:

1. Should we allow 3rd-party (not part of the official RFC process) non-spec compliant customizations? Disclaimer: I’m fully against it.
2. What to do with getFieldDef?

I think we need a policy on question 1 since we already had a similar discussion about adding hooks to the parser, executor, etc. Otherwise, we will have this type of disagreement every time someone wants to add or remove a legacy hook (we still have a few of them).

[IvanGoncharov]

Thanks for addressing this. In general, a hook should not be removed in my opinion until a satisfactory replacement method for customization is introduced.

@yaacovCR This hook was clearly marked as “experimental” and later “deprecated”. Moreover, before deprecation, it said “You should never need to use it.”. Please see: https://github.com/graphql/graphql-js/commit/825ebd312269decd0ac3872a3346d85d5cb6e262#

So no replacements were promised. If this feature had a use case for “spec compliant” implementation it made sense to provide some alternative but from what I see it doesn’t. Moreover, I reconsider my position and think that by providing “compromise functionality” we just shifting this discussion down the road.

So instead of mixing two discussions, I want to solve the core question we have at hand: Is supporting non-compliant GraphQL implementations a valid use case for graphql-js? I added a separate agenda item to discuss just it. I don’t think discussing the technicalities of getFieldDefFn makes sense before we have the answer to that question.