Teach prettier/graphql about formatting fragment variables.

[adek05]

Fragment variables are an experimental extension to GraphQL schema.
Formatting should follow the same rules as formatting an OperationDefinition node,

hence code is the same.

• I’ve added tests to confirm my change works.
• (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory)
• (If the change is user-facing) I’ve added my changes to the CHANGELOG.unreleased.md file following the template.
• I’ve read the contributing guidelines.

✨Try the playground for this PR✨

[lydell]

Do you think it would be bad to enable this by default and removing the option?

[adek05]

Not really, gql parser should be robust enough to not cause issues. If this feature gets deleted in the future we will pick it up and fix when upgrading graphql-js dependency.

It is strictly a superset of existing language so should work fine. Not sure what is the sentiment about using something that is experimental.

[j-f1]

In the JS parser, we support (I believe) all the syntax proposals Babel does, so I think we should do the same here.

[j-f1]

Can you add a test with multiple fragment variables so the variable section is forced to break onto multiple lines?

[j-f1]

Sorry to not have asked for all these things at once. How are the fragment variables specified when using the fragment? Does there need to be printing support for that too?

[adek05]

They are now defined on the root operation definition through a query transformation at build time. You don’t set them at fragment spreads as of yet, so no extra work is necessary at this point

[duailibe]

In the JS parser, we support (I believe) all the syntax proposals Babel does, so I think we should do the same here.

The problem is if any of those proposals get deleted in the future (or maybe they stop working eventually). Prettier will either have to continue to support those (unfortunate) or stop formatting user's code (which is unfortunate for users). We already carry the burden of having to support both of decorator proposals.

For this PR, I think we should do it and, if this doesn't get added to the language, let's hope the parser continues to support it for a while

[j-f1]

Should we have a policy that semver doesn’t apply to stage-x JS features?

[duailibe]

@j-f1 What?

[vjeux]

@duailibe we need this for our GraphQL usage at Facebook. Would it be possible to get it merged? Thanks!

[j-f1]

@duailibe referring to your previous comment above about supporting experimental features. I was wondering if we should have a policy that we’ll stay up to date with breaking changes to proposals for JS in minor versions.

[duailibe]

@adek05 Thanks!

@vjeux I'll cut a release today or tomorrow

[vjeux]

Thanks!