Do not warn about legacy __configs__ name

[kassens]

We currently don't have a good way to silence warnings for legacy field names staring with __. This silences the two offenders used internally at Facebook until we find a way to clean them up from the schema or ignore them when parsing an existing schema.

[wincent]

Rather than put an FB-specific hack in the reference implementation, I'd much rather see us come up with a mechanism you could use to add exceptions to a whitelist. (Or failing that, a way of opting out of this validation.) It wouldn't need to be pretty, ergonomic or easy (we don't want to make opting out too easy), just possible. What do you think?

[kassens]

Thoughts on how to do this? I'd like to avoid passing a flag through the call stack, which I'd argue pollutes this implementation even more then a small special case.

I could add a flag on assertValidName? Something like require('graphql').assertValidName.WARN = false, but that relies on calling that before loading the schema and mutating a module.

[leebyron]

IMHO we should create warnings if you're creating a schema manually for runtime, but not create warnings if you're hydrating a schema from an introspection result. It's pretty useless for tools like graphiql or codegen systems to issue these warnings that are really in place for first-time schema construction.

Threading a variable through everything feels ugly, but so setting a global value :/

[leebyron]

For example, maybe in buildClientSchema or buildASTSchema we can set some global context flag to ignore warnings?

[leebyron]

I think most ideally validating a schema and constructing a schema can be separated into two separate functions. That would also improve schema construction performance by not running this validation inline every time. Perhaps schema validation could them be run as part of the all-inclusive graphql function.

[wincent]

For reference, #719 is the issue tracking the separation of warnings according to runtime construction vs introspection.