Format documents with 'prettier' (#174)

Author: benjie

.gitignore

@@ -59,3 +59,15 @@ typings/
 
 # Visual Studio project specific, machine local files
 .vs/
+
+# Standard ignores from wg-template
+*.swp
+*~
+.*.haste_cache.*
+.DS_Store
+npm-debug.log
+/build
+/public
+/gh-pages
+yarn.lock
+package-lock.json

.prettierignore

@@ -0,0 +1,4 @@
+# PRs to Working Group documents should be minimal effort - no need to force formatting compliance
+/working-group/
+# To maintain the expressiveness of the original poster, we do not auto-format RFCs
+/rfcs/

INTERESTED_DEVELOPERS.md

@@ -1,73 +1,88 @@
 # Interested Developers
 
-## Want to get involved? 
+## Want to get involved?
 
-If you're interested in this spec and helping contribute to it, you can get involved with the following steps:
+If you're interested in this spec and helping contribute to it, you can get
+involved with the following steps:
 
-1. Read the [Roadmap](ROADMAP.md) which outlines the planned development of this spec.
-2. See [Agendas](working-group/agendas) for upcoming meetings of the GraphQL-over-HTTP working group.  Given our world-wide span over many timezones, we are doing an experiment of attempting to advance the spec with fewer meetings and more asynchronous communication.  During this experiment, please reach out over slack and github.
+1. Read the [Roadmap](ROADMAP.md) which outlines the planned development of this
+   spec.
+2. See [Agendas](working-group/agendas) for upcoming meetings of the
+   GraphQL-over-HTTP working group. Given our world-wide span over many
+   timezones, we are doing an experiment of attempting to advance the spec with
+   fewer meetings and more asynchronous communication. During this experiment,
+   please reach out over slack and github.
 3. Add yourself to `List of Developers` below.
-4. Find our working group on the [GraphQL Foundation slack community](https://slack.graphql.org) in the [graphql-over-http channel](https://graphql.slack.com/archives/CRTKLUZRT).
+4. Find our working group on the
+   [GraphQL Foundation slack community](https://slack.graphql.org) in the
+   [graphql-over-http channel](https://graphql.slack.com/archives/CRTKLUZRT).
 
 ## List of Developers
 
-This list helps us keep track people that are interested in taking decisions of the specification of GraphQL over HTTP.
+This list helps us keep track people that are interested in taking decisions of
+the specification of GraphQL over HTTP.
 
-If you want to be listed here, open a PR with your information, just order yourself by username.
+If you want to be listed here, open a PR with your information, just order
+yourself by username.
 
+- @abernix
+  - Company/Project/Repo: https://github.com/apollographql/apollo-server,
+    https://github.com/apollographql/apollo-client
+  - Reason: Interested in client/server spec
+- @balshor
+  - Company/Project/Repo: https://github.com/linkedin
+  - Reason: Interested in a common HTTP spec
+- @benjie
+  - Company/Project/Repo: https://github.com/graphql/graphiql,
+    https://github.com/graphile/postgraphile
+  - Reason: Interested in a common HTTP spec
+- @deinok
+  - Company/Project/Repo: https://github.com/graphql-dotnet/graphql-client
+  - Reason: Interested in client/server on C# stack
+- @enisdenjo
+  - Company/Project/Repo: https://github.com/domonda,
+    https://github.com/bhidapa, https://github.com/enisdenjo/graphql-ws
+  - Reason: Interested in a common subscriptions spec
+- @erikwittern
+  - Company/Project/Repo: https://github.com/graphql/libgraphqlparser,
+    https://github.com/IBM/openapi-to-graphql
+  - Reason: Interested in client/server in JavaScript/C++
+- @ghmcadams
+  - Company/Project/Repo: https://github.com/ghmcadams
+  - Reason: Interested in a common HTTP spec
+- @jaydenseric
+  - Company/Project/Repo:
+    https://github.com/jaydenseric/graphql-multipart-request-spec
+  - Reason: Interested in multipart request spec
+- @maraisr
+  - Company/Project/Repo: https://github.com/maraisr/meros
+  - Reason: Interested in common incremental delivery spec
+- @michaelstaib
+  - Company/Project/Repo: https://github.com/ChilliCream/hotchocolate
+  - Reason: Interested in client/server in JavaScript/C++/C#
+- @mike-marcacci
+  - Company/Project/Repo: https://github.com/boltline
+  - Reason: Interested in client/server spec
+- @mmatsa
+  - Company/Project/Repo: https://github.com/graphql/libgraphqlparser
+  - Reason: Interested in client/server in C++
+- @sjparsons
+  - Company/Project/Repo: PayPal & Braintree https://github.com/sjparsons
+  - Reason: Interested in common spec
+- @spawnia
+  - Company/Project/Repo: https://github.com/nuwave/lighthouse
+  - Reason: Interested in client/server in PHP
+- @sungam3r
+  - Company/Project/Repo: https://github.com/graphql-dotnet/server
+  - Reason: Interested in client/server spec
+- @glennblock
+  - Company/Project/Report: https://github.com/microsoft
+  - Reason: Interested in a common HTTP spec, and in adoption of emerging HTTP
+    standards like HTTP SEARCH
+- @hemanth
+  - Company/Project/Repo: PayPal https://github.com/hemanth
+  - Reason: Interested in a common HTTP spec and common subscriptions spec.
 
-* @abernix
-  * Company/Project/Repo: https://github.com/apollographql/apollo-server, https://github.com/apollographql/apollo-client
-  * Reason: Interested in client/server spec
-* @balshor
-  * Company/Project/Repo: https://github.com/linkedin
-  * Reason: Interested in a common HTTP spec
-* @benjie
-  * Company/Project/Repo: https://github.com/graphql/graphiql, https://github.com/graphile/postgraphile
-  * Reason: Interested in a common HTTP spec
-* @deinok
-  * Company/Project/Repo: https://github.com/graphql-dotnet/graphql-client
-  * Reason: Interested in client/server on C# stack
-* @enisdenjo
-  * Company/Project/Repo: https://github.com/domonda, https://github.com/bhidapa, https://github.com/enisdenjo/graphql-ws
-  * Reason: Interested in a common subscriptions spec
-* @erikwittern
-  * Company/Project/Repo: https://github.com/graphql/libgraphqlparser, https://github.com/IBM/openapi-to-graphql
-  * Reason: Interested in client/server in JavaScript/C++
-* @ghmcadams
-  * Company/Project/Repo: https://github.com/ghmcadams
-  * Reason: Interested in a common HTTP spec 
-* @jaydenseric
-  * Company/Project/Repo: https://github.com/jaydenseric/graphql-multipart-request-spec
-  * Reason: Interested in multipart request spec
-* @maraisr
-  * Company/Project/Repo: https://github.com/maraisr/meros
-  * Reason: Interested in common incremental delivery spec
-* @michaelstaib
-  * Company/Project/Repo: https://github.com/ChilliCream/hotchocolate
-  * Reason: Interested in client/server in JavaScript/C++/C#
-* @mike-marcacci
-  * Company/Project/Repo: https://github.com/boltline
-  * Reason: Interested in client/server spec
-* @mmatsa
-  * Company/Project/Repo: https://github.com/graphql/libgraphqlparser
-  * Reason: Interested in client/server in C++
-* @sjparsons
-  * Company/Project/Repo: PayPal & Braintree https://github.com/sjparsons
-  * Reason: Interested in common spec
-* @spawnia
-  * Company/Project/Repo: https://github.com/nuwave/lighthouse
-  * Reason: Interested in client/server in PHP
-* @sungam3r
-  * Company/Project/Repo: https://github.com/graphql-dotnet/server
-  * Reason: Interested in client/server spec
-* @glennblock
-  * Company/Project/Report: https://github.com/microsoft
-  * Reason: Interested in a common HTTP spec, and in adoption of emerging HTTP standards like HTTP SEARCH
-* @hemanth
-  * Company/Project/Repo: PayPal https://github.com/hemanth
-  * Reason: Interested in a common HTTP spec and common subscriptions spec.
-  
 ### CC Helper
 
 `@abernix @balshor @benjie @deinok @erikwittern @jaydenseric @michaelstaib @mike-marcacci @mmatsa @sjparsons @spawnia @sungam3r @enisdenjo`

README.md

@@ -1,42 +1,72 @@
 > **Stage 0: Preliminary**
-> 
-> This spec is in a preliminary stage of active development, and can change a lot before reaching `Draft` stage.  For more information, please see the [Roadmap](ROADMAP.md) or [how to get involved](INTERESTED_DEVELOPERS.md).
 >
-> You can find our community in the [graphql-over-http channel](https://discord.com/channels/625400653321076807/863141924126588958) on the [GraphQL Foundation Discord](https://discord.graphql.org).
+> This spec is in a preliminary stage of active development, and can change a
+> lot before reaching `Draft` stage. For more information, please see the
+> [Roadmap](ROADMAP.md) or [how to get involved](INTERESTED_DEVELOPERS.md).
+>
+> You can find our community in the
+> [graphql-over-http channel](https://discord.com/channels/625400653321076807/863141924126588958)
+> on the [GraphQL Foundation Discord](https://discord.graphql.org).
 
 ---
 
 # GraphQL over HTTP
 
 **Introduction**
 
-HTTP is the most common choice as the client-server protocol when using GraphQL because of its ubiquity.
-However the [GraphQL specification](https://graphql.github.io/graphql-spec/) deliberately does not specify the transport layer.
+HTTP is the most common choice as the client-server protocol when using GraphQL
+because of its ubiquity. However the
+[GraphQL specification](https://graphql.github.io/graphql-spec/) deliberately
+does not specify the transport layer.
 
-The closest thing to an official specification is the article [Serving over HTTP](https://graphql.org/learn/serving-over-http/).
-Leading implementations on both client and server have mostly upheld those best practices and thus established
-a de-facto standard that is commonly used throughout the ecosystem.
+The closest thing to an official specification is the article
+[Serving over HTTP](https://graphql.org/learn/serving-over-http/). Leading
+implementations on both client and server have mostly upheld those best
+practices and thus established a de-facto standard that is commonly used
+throughout the ecosystem.
 
-This specification is intended to fill this gap by specifying how GraphQL should be served over HTTP.
-The main intention of this specification is to provide interoperability between different client libraries, tools
-and server implementations.
+This specification is intended to fill this gap by specifying how GraphQL should
+be served over HTTP. The main intention of this specification is to provide
+interoperability between different client libraries, tools and server
+implementations.
 
 **Spec Location**
 
-The GraphQL over HTTP specification is edited in the [spec-md markdown file](./spec/GraphQLOverHTTP.md).
+The GraphQL over HTTP specification is edited in the
+[spec-md markdown file](./spec/GraphQLOverHTTP.md).
 
-In the future, we plan that you would be able to view the generated form of the specification as well.
+In the future, we plan that you would be able to view the generated form of the
+specification as well.
 
 ### Contributing to this repo
 
-This repository is managed by EasyCLA. Project participants must sign the free ([GraphQL Specification Membership agreement](https://preview-spec-membership.graphql.org) before making a contribution. You only need to do this one time, and it can be signed by [individual contributors](https://individual-spec-membership.graphql.org/) or their [employers](https://corporate-spec-membership.graphql.org/).
+This repository is managed by EasyCLA. Project participants must sign the free
+([GraphQL Specification Membership agreement](https://preview-spec-membership.graphql.org)
+before making a contribution. You only need to do this one time, and it can be
+signed by
+[individual contributors](https://individual-spec-membership.graphql.org/) or
+their [employers](https://corporate-spec-membership.graphql.org/).
 
-To initiate the signature process please open a PR against this repo. The EasyCLA bot will block the merge if we still need a membership agreement from you.
+To initiate the signature process please open a PR against this repo. The
+EasyCLA bot will block the merge if we still need a membership agreement from
+you.
 
-You can find [detailed information here](https://github.com/graphql/graphql-wg/tree/main/membership). If you have issues, please email [[email protected]](mailto:[email protected]).
+You can find
+[detailed information here](https://github.com/graphql/graphql-wg/tree/main/membership).
+If you have issues, please email
+[[email protected]](mailto:[email protected]).
 
-If your company benefits from GraphQL and you would like to provide essential financial support for the systems and people that power our community, please also consider membership in the [GraphQL Foundation](https://foundation.graphql.org/join).
+If your company benefits from GraphQL and you would like to provide essential
+financial support for the systems and people that power our community, please
+also consider membership in the
+[GraphQL Foundation](https://foundation.graphql.org/join).
 
 ---
+
 Copyright Joint Development Foundation Projects, LLC, GraphQL Series.<br>
-[graphql.org](https://graphql.org) | [Spec](https://spec.graphql.org) | [GitHub](https://github.com/graphql/graphql-over-http) | [GraphQL Foundation](https://foundation.graphql.org) | [Code of Conduct](https://code-of-conduct.graphql.org) | [Discord](https://discord.com/channels/625400653321076807/863141924126588958) | [Store](https://store.graphql.org)
+[graphql.org](https://graphql.org) | [Spec](https://spec.graphql.org) |
+[GitHub](https://github.com/graphql/graphql-over-http) |
+[GraphQL Foundation](https://foundation.graphql.org) |
+[Code of Conduct](https://code-of-conduct.graphql.org) |
+[Discord](https://discord.com/channels/625400653321076807/863141924126588958) |
+[Store](https://store.graphql.org)

ROADMAP.md

@@ -2,20 +2,24 @@
 
 ## Mission
 
-_Provide a specification that allows GraphQL clients and servers with different implementations and technology stacks to interact freely over HTTP if both client and server are compliant._
+_Provide a specification that allows GraphQL clients and servers with different
+implementations and technology stacks to interact freely over HTTP if both
+client and server are compliant._
 
 ## Guiding principles
 
 - Development is based on use cases
 - Strive for backwards-compatible progress
-  - Servers supporting later versions of this spec should support clients using earlier versions of this spec.
+  - Servers supporting later versions of this spec should support clients using
+    earlier versions of this spec.
 
 ## Version 1.0
 
-After significant meetings, the Working Group has come to consensus that a first version of this spec should
-introduce some key changes over the prior existing uses of GraphQL over HTTP.
-This first version _might_ also codify existing prior common usages of GraphQL over HTTP.
-In layout and structure version 1.0 should lay a foundation for future development and standardization.
+After significant meetings, the Working Group has come to consensus that a first
+version of this spec should introduce some key changes over the prior existing
+uses of GraphQL over HTTP. This first version _might_ also codify existing prior
+common usages of GraphQL over HTTP. In layout and structure version 1.0 should
+lay a foundation for future development and standardization.
 
 ### Scope
 
@@ -28,7 +32,8 @@ In layout and structure version 1.0 should lay a foundation for future developme
 ### Actions
 
 - Move to the GraphQL Foundation
-- Set of running examples of ~5 of the most popular servers/clients with a standard, minimal GraphQL schema
+- Set of running examples of ~5 of the most popular servers/clients with a
+  standard, minimal GraphQL schema
 - Test suite to automate testing of GraphQL servers compliance with the spec
   - Can be applied to examples of popular server or public GraphQL APIs
 - Results of popular libraries and APIs compliance with current spec
@@ -43,42 +48,52 @@ Future versions of the spec may include these concepts:
 
 - Caching
 - Batching
-- Versioning mechanism for servers/clients to communicate what versions they support
-- Modularity - A way to communicate what features (and possibly versions) of the HTTP spec are supported by a server
+- Versioning mechanism for servers/clients to communicate what versions they
+  support
+- Modularity - A way to communicate what features (and possibly versions) of the
+  HTTP spec are supported by a server
 - Persisted queries
 - Multipart requests (file uploads)
 - Submit MIME type application/graphql+json to IANA
-- New HTTP SEARCH method and how it could be used https://tools.ietf.org/html/draft-snell-search-method-01
+- New HTTP SEARCH method and how it could be used
+  https://tools.ietf.org/html/draft-snell-search-method-01
 
 ## Stages
 
-The process of writing this specification may proceed according this rough outline of stages.
-We are currently in the *Preliminary Stage*.
+The process of writing this specification may proceed according this rough
+outline of stages. We are currently in the _Preliminary Stage_.
 
 ### Stage 0: Preliminary
 
-In the *Preliminary Stage*, things may change rapidly and no one should count on any particular
-detail remaining the same.
+In the _Preliminary Stage_, things may change rapidly and no one should count on
+any particular detail remaining the same.
 
-- If a PR has no requests for changes for 2 weeks then it should be merged by one of the maintainers
-- If anyone has an objection later, they just open a PR to make the change and it goes through the same process
+- If a PR has no requests for changes for 2 weeks then it should be merged by
+  one of the maintainers
+- If anyone has an objection later, they just open a PR to make the change and
+  it goes through the same process
 - Optional: When there is lots of consensus but not 100% full consensus then:
-   - We might merge the consensus-view and debate modifying it in parallel
-   - Anyone can extract the non-controversial part and make a separate PR
+  - We might merge the consensus-view and debate modifying it in parallel
+  - Anyone can extract the non-controversial part and make a separate PR
 
-When the spec seems stable enough, the working group would promote it to *Proposal Stage*.
+When the spec seems stable enough, the working group would promote it to
+_Proposal Stage_.
 
 ### Stage 1: Proposal
 
-In the *Proposal Stage*, things can still change but it is reasonable to start implementations.
+In the _Proposal Stage_, things can still change but it is reasonable to start
+implementations.
 
-- Before release of the spec, in "Draft" stage, we have to review the spec and review all open PRs
+- Before release of the spec, in "Draft" stage, we have to review the spec and
+  review all open PRs
 - Every merge to master would need strong consensus
 - Only changes that address concerns
 - Implementers could start trying things
 
-After the spec and open PRs are reviewed and there is strong consensus, the working group would promote it to *Draft Stage*.
+After the spec and open PRs are reviewed and there is strong consensus, the
+working group would promote it to _Draft Stage_.
 
 ### Stage 2: Draft
 
-This corresponds to the general [GraphQL Draft Stage](https://github.com/graphql/graphql-spec/blob/master/CONTRIBUTING.md#stage-2-draft)
+This corresponds to the general
+[GraphQL Draft Stage](https://github.com/graphql/graphql-spec/blob/master/CONTRIBUTING.md#stage-2-draft)

cspell.yml

@@ -0,0 +1,16 @@
+language: en-US
+ignoreRegExpList:
+  # Posessives
+  - /[a-z]{2,}'s/
+words:
+  # Terms of art
+  - endianness
+  - interoperation
+  - monospace
+  - openwebfoundation
+  - parallelization
+  - structs
+  - subselection
+  # Software
+  - ical
+  # Fictional characters / examples