Add NoSchemaIntrospectionCustomRule

[danielrearden]

#2597

[IvanGoncharov]

@danielrearden Thanks, looks very tidy and match the style of other rules 👍

I give it more though and technically __typename is also introspection field so we can't call it NoIntrospectionFields 😞
Also, we have other fields that can leak similar info for example Apollo federation has _service that returns SDL.
So I more incline towards more generic rules like:

• https://eslint.org/docs/rules/no-restricted-properties
• https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/ban-types.md
• etc.

Also, I think in this case being able to customize error messages would be very helpful.

But I'm not sure if I'm overcomplicating it or not so I need more time to think.
Meanwhile, if you have time you can work on #2601 which is very similar to this one.

[IvanGoncharov]

@danielrearden Actually scratch it this rule is very short so config for the more generic rule would be more longer that rule itself.
So back the initial question, __typename is also introspection field so we need to change rule name.
How about BanIntrospectionQueriesRule?

[danielrearden]

How about BanIntrospectionQueriesRule?

@IvanGoncharov That makes sense. Would NoIntrospectionQueriesRule be more inline with the existing rule names?

[IvanGoncharov]

Would NoIntrospectionQueriesRule be more inline with the existing rule names?

@danielrearden Generally, yes. But in this case, we forbid something that is totally valid and you ban it because of your own preference/requirements not even because it represents best practice.
Speaking of this can you please expand description with some strong wording asking not to use this rule unless it's absolutely necessary.

[danielrearden]

@IvanGoncharov

• Changed name to ProhibitIntrospectionQueriesRule
• Updated rule logic to just check the field type
• Moved rule to /rules/optional
• Updated comment to include usage warning
• Added test for non-standard introspection fields -- ended up using expectValidationRulesWithSchema anyway so I wouldn't have to touch the harness schema
• Had to build schema programmatically since buildSchema doesn't support using introspection types for fields

The use of introspection types with user-defined fields is unconventional but I don't believe it's prohibited by the spec. Since the rule just tests the field's type, it's possible it would also throw in the event a non-standard introspection field like that was requested. I think that behavior lines up with the intent behind the rule.

[danielrearden]

@IvanGoncharov Ok, that should be all of it 😓

[IvanGoncharov]

@danielrearden Forget about this one.
But it too late in my timezone so I will go to 🛌 and will check it tomorrow.

P.S. It's totally okay to ping in comments after you addressed all review comments.
Moreover actually makes my life easier since I don't need to check all current PRs to see their statuses 😄

[IvanGoncharov]

@danielrearden I merged #2608 so now buildSchema should work fine can you please use it instead.