Matt Mahoney

@ivome unfortunately, I know of at least two GraphQL implementations that could be made to support this more-restricted version of the spec change, but could not, without GraphQL response-format changes,...

This looks good to me. We can always change to ad-hoc down the road. Technically once we get one more approver on the changes we can merge this (because it...

Instead of making an extensible printer, would it solve your issue if directives on schema definitions were included in the print step? I believe this is actually a bug where...

@IvanGoncharov would it be better to create a branch within `graphql-js` for this, rather than merging onto master/from my own repo? There's some complexity in terms of validating the argument...

> Are these "Fragment Arguments" or "Fragment Variables"? The way I'm thinking of them is, when used **within** a fragment definition, they are "fragment variables", as they're variables defined on...

Yeah the short of it is I'm back to iterating on this proposal. I think the core plan of attack is: - Call them "Fragment Arguments" as enabling people to...

For the JS server implementation, we deeply rely on the support of the community to identify and fix bugs like this. While we use graphql-js internally at Facebook, we typically...

We probably want a more comprehensive solution to getting a directive on various schema definitions. I think the core idea here is right, but we'd also like to make it...

This PR is now very close to ready for review (review question, do people prefer stacked PRs, i.e. one PR per commit/idea, or PRs that have all the changes bundled...

I've updated the changes to be what I think are the minimal needed to get the behavior and validation to match the updates described by the spec changes in https://github.com/graphql/graphql-spec/pull/865...