Merge remote-tracking branch 'origin/master' into next-api

.vscode/settings.json

@@ -4,6 +4,7 @@
   "editor.insertSpaces": true,
   "editor.rulers": [110],
   "editor.wordWrapColumn": 110,
+  "prettier.semi": true,
   "files.trimTrailingWhitespace": true,
   "files.insertFinalNewline": true,
   "prettier.singleQuote": true,

CHANGELOG.md

@@ -2,7 +2,33 @@
 
 ### vNEXT
 
-* ...
+### v2.19.0
+
+* Also recreate `astNode` property for fields, not only types, when recreating schemas. [PR #580](https://github.com/apollographql/graphql-tools/pull/580)
+* Fix `delegateToSchema.js` to accept and move forward args with zero or false values [PR #586](https://github.com/apollographql/graphql-tools/pull/586)
+
+### v2.18.0
+
+* Fix a bug where inline fragments got filtered in merged schemas when a type implemented multiple interfaces [PR #546](https://github.com/apollographql/graphql-tools/pull/546)
+* IEnumResolver value can be a `number` type [PR #568](https://github.com/apollographql/graphql-tools/pull/568)
+
+### v2.17.0
+
+* Include `astNode` property in schema recreation [PR #569](https://github.com/apollographql/graphql-tools/pull/569)
+
+### v2.16.0
+
+* Added GraphQL Subscriptions support for schema stitching and `makeRemoteExecutableSchema` [PR #563](https://github.com/apollographql/graphql-tools/pull/563)
+* Make `apollo-link` a direct dependency [PR #561](https://github.com/apollographql/graphql-tools/pull/561)
+* Update tests to use `[email protected]` docstring format [PR #559](https://github.com/apollographql/graphql-tools/pull/559)
+
+### v2.15.0
+
+* Validate query before delegation [PR #551](https://github.com/apollographql/graphql-tools/pull/551)
+
+### v2.14.1
+
+* Add guard against invalid schemas being constructed from AST [PR #547](https://github.com/apollographql/graphql-tools/pull/547)
 
 ### v2.14.0
 
@@ -177,7 +203,7 @@ Update to add support for `[email protected]`, and drop versions before `0.11` from t
 
 * Removed testing on Node 5 ([@DxCx](https://github.com/DxCx) in [#129](https://github.com/apollostack/graphql-tools/pull/129))
 
-* Changed GraphQL typings requirment from peer to standard ([@DxCx](https://github.com/DxCx) in [#129](https://github.com/apollostack/graphql-tools/pull/129))
+* Changed GraphQL typings requirement from peer to standard ([@DxCx](https://github.com/DxCx) in [#129](https://github.com/apollostack/graphql-tools/pull/129))
 
 * Change the missing resolve function validator to show a warning instead of an error ([@nicolaslopezj](https://github.com/nicolaslopezj) in [#134](https://github.com/apollostack/graphql-tools/pull/134))
 

README.md

@@ -34,7 +34,10 @@ type Author {
   id: ID! # the ! means that every author object _must_ have an id
   firstName: String
   lastName: String
-  posts: [Post] # the list of Posts by this author
+  """
+  the list of Posts by this author
+  """
+  posts: [Post]
 }
 
 type Post {

designs/connectors.md

@@ -37,7 +37,7 @@ In this example, an author has multiple posts, and each post has one author.
 
 Here's an illustration for how connectors and models would look like for this example if Authors and Posts were stored in MySQL, but view counts in MongoDB:
 
-![Connectors are database-specfic, models are application-specific](connector-model-diagram.png)
+![Connectors are database-specific, models are application-specific](connector-model-diagram.png)
 
 
 The Posts model connects to both SQL and MongoDB. Title, text and authorId come from SQL, the view count comes from MongoDB.
@@ -60,7 +60,7 @@ Both batching and caching are more important in GraphQL than in traditional endp
 
 Models are the glue between connectors - which are backend-specific - and GraphQL types - which are app-specific. They are very similar to models in ORMs, such as Rails' Active Record.
 
-Let's say for example that you have two types, Author and Post, which are both stored in MySQL. Rather than calling the MySQL connector directly from your resolve funcitons, you should create models for Author and Post, which use the MongoDB connector. This additional level of abstraction helps separate the data fetching logic from the GraphQL schema, which makes reusing and refactoring it easier.
+Let's say for example that you have two types, Author and Post, which are both stored in MySQL. Rather than calling the MySQL connector directly from your resolve functions, you should create models for Author and Post, which use the MongoDB connector. This additional level of abstraction helps separate the data fetching logic from the GraphQL schema, which makes reusing and refactoring it easier.
 
 In the example schema above, the Authors model would have the following methods:
 ```

docs/source/generate-schema.md

@@ -17,7 +17,10 @@ const typeDefs = `
     id: Int!
     firstName: String
     lastName: String
-    posts: [Post] # the list of Posts by this author
+    """
+    the list of Posts by this author
+    """
+    posts: [Post]
   }
 
   type Post {
@@ -279,19 +282,29 @@ const typeDefs = [`
 
 <h2 id="descriptions">Descriptions &amp; Deprecations</h2>
 GraphiQL has built-in support for displaying docstrings with markdown syntax. You can easily add docstrings to types, fields and arguments like below:
+
 ```
-# Description for the type
+"""
+Description for the type
+"""
 type MyObjectType {
-  # Description for field
+  """
+  Description for field
+  Supports multi-line description
+  """
   myField: String!
 
   otherField(
-    # Description for argument
+    """
+    Description for argument
+    """
     arg: Int
   )
 
   oldField(
-    # Description for argument
+    """
+    Description for argument
+    """
     arg: Int
   ) @deprecated(reason: "Use otherField instead.")
 }

docs/source/mocking.md

@@ -13,7 +13,7 @@ Let's take a look at how we can mock a GraphQL schema with just one line of code
 
 [See a complete runnable example on Launchpad.](https://launchpad.graphql.com/98lq7vz8r)
 
-To start, let's grab the schema definition string from the `makeExecutableSchema` example [in the "Generating a schema" article](/tools/graphql-tools/generate-schema.html#example).
+To start, let's grab the schema definition string from the `makeExecutableSchema` example [in the "Generating a schema" article](./generate-schema.html#example).
 
 ```js
 import { makeExecutableSchema, addMockFunctionsToSchema } from 'graphql-tools';

docs/source/remote-schemas.md

@@ -39,7 +39,7 @@ A link is a function capable of retrieving GraphQL results. It is the same way t
   Link API
 </h3>
 
-Since graphql-tools supports using a link for the network layer, the API is the same as you would write on the client. To learn more about how Apollo Link works, check out the [docs](https://apollo-links-docs.netlify.com/links); Both GraphQL and Apollo Links have slightly varying concepts of what `context` is used for. To make it easy to use your GraphQL context to create your Apollo Link context, `makeRemoteExecutableSchema` attaches the context from the graphql resolver onto the link context under `graphqlContext`.
+Since graphql-tools supports using a link for the network layer, the API is the same as you would write on the client. To learn more about how Apollo Link works, check out the [docs](https://www.apollographql.com/docs/link/); Both GraphQL and Apollo Links have slightly varying concepts of what `context` is used for. To make it easy to use your GraphQL context to create your Apollo Link context, `makeRemoteExecutableSchema` attaches the context from the graphql resolver onto the link context under `graphqlContext`.
 
 Basic usage
 

docs/source/resolvers.md

@@ -42,9 +42,9 @@ fieldName(obj, args, context, info) { result }
 
 These arguments have the following meanings and conventional names:
 
-1. `obj`: The object that contains the result returned from the resolver on the parent field, or, in the case of a top-level `Query` field, the `rootValue` passed from the [server configuration](/tools/apollo-server/setup.html). This argument enables the nested nature of GraphQL queries.
+1. `obj`: The object that contains the result returned from the resolver on the parent field, or, in the case of a top-level `Query` field, the `rootValue` passed from the [server configuration](/docs/apollo-server/setup.html). This argument enables the nested nature of GraphQL queries.
 2. `args`: An object with the arguments passed into the field in the query. For example, if the field was called with `author(name: "Ada")`, the `args` object would be: `{ "name": "Ada" }`.
-3. `context`: This is an object shared by all resolvers in a particular query, and is used to contain per-request state, including authentication information, dataloader instances, and anything else that should be taken into account when resolving the query. If you're using Apollo Server, [read about how to set the context in the setup documentation](/tools/apollo-server/setup.html).
+3. `context`: This is an object shared by all resolvers in a particular query, and is used to contain per-request state, including authentication information, dataloader instances, and anything else that should be taken into account when resolving the query. If you're using Apollo Server, [read about how to set the context in the setup documentation](/docs/apollo-server/setup.html).
 4. `info`: This argument should only be used in advanced cases, but it contains information about the execution state of the query, including the field name, path to the field from the root, and more. It's only documented in the [GraphQL.js source code](https://github.com/graphql/graphql-js/blob/c82ff68f52722c20f10da69c9e50a030a1f218ae/src/type/definition.js#L489-L500).
 
 ### Resolver result format
@@ -178,7 +178,7 @@ Modules and extensions built by the community.
 
 Composition library for GraphQL, with helpers to combine multiple resolvers into one, specify dependencies between fields, and more.
 
-When developing a GraphQL server, it is common to perform some authorization logic on your resolvers, usually based on the context of a request. With `graphql-resolvers` you can easily accomplish that and still make the code decoupled - thus testable - by combining multiple sigle-logic resolvers into one.
+When developing a GraphQL server, it is common to perform some authorization logic on your resolvers, usually based on the context of a request. With `graphql-resolvers` you can easily accomplish that and still make the code decoupled - thus testable - by combining multiple single-logic resolvers into one.
 
 The following is an example of a simple logged-in authorization logic:
 

docs/source/scalars.md

@@ -208,11 +208,8 @@ You can use it in your schema anywhere you could use a scalar:
 
 ```graphql
 type Query {
-  # As a return value
-  favoriteColor: AllowedColor
-
-  # As an argument
-  avatar(borderColor: AllowedColor): String
+  favoriteColor: AllowedColor # As a return value
+  avatar(borderColor: AllowedColor): String # As an argument
 }
 ```
 
@@ -249,11 +246,8 @@ const typeDefs = `
   }
 
   type Query {
-    # As a return value
-    favoriteColor: AllowedColor
-
-    # As an argument
-    avatar(borderColor: AllowedColor): String
+    favoriteColor: AllowedColor # As a return value
+    avatar(borderColor: AllowedColor): String # As an argument
   }
 `;
 

docs/source/schema-stitching.md

@@ -112,7 +112,7 @@ You won't be able to query `User.chirps` or `Chirp.author` yet however, because
 
 So what should these resolvers look like?
 
-When we resolve `User.chirps` or `Chirp.author`, we want to delegate to the revelant root fields. To get from a user to its chirps for example, we'll want to use the `id` of the user to call `chirpsByAuthorId`. And to get from a chirp to its author, we can use the chirp's `authorId` field to call into `userById`.
+When we resolve `User.chirps` or `Chirp.author`, we want to delegate to the relevant root fields. To get from a user to its chirps for example, we'll want to use the `id` of the user to call `chirpsByAuthorId`. And to get from a chirp to its author, we can use the chirp's `authorId` field to call into `userById`.
 
 Resolvers specified as part of `mergeSchema` have access to a `delegate` function that allows you to delegate to root fields.
 
@@ -220,7 +220,7 @@ resolvers: mergeInfo => ({
 
 #### mergeInfo and delegate
 
-`mergeInfo` currenty is an object with one property - `delegate`. It looks like this:
+`mergeInfo` currently is an object with one property - `delegate`. It looks like this:
 
 ```js
 type MergeInfo = {

package.json

@@ -1,6 +1,6 @@
 {
   "name": "graphql-tools",
-  "version": "2.15.0-alpha.1",
+  "version": "2.19.0",
   "description": "Useful tools to create and manipulate GraphQL schemas.",
   "main": "dist/index.js",
   "typings": "dist/index.d.ts",
@@ -49,34 +49,34 @@
   "homepage": "https://github.com/apollostack/graphql-tools#readme",
   "dependencies": {
     "apollo-utilities": "^1.0.1",
+    "apollo-link": "^1.0.0",
     "deprecated-decorator": "^0.1.6",
+    "graphql-subscriptions": "^0.5.6",
     "uuid": "^3.1.0"
   },
   "peerDependencies": {
     "graphql": "^0.11.0 || ^0.12.0"
   },
   "devDependencies": {
-    "@types/chai": "4.0.4",
+    "@types/chai": "4.0.10",
     "@types/graphql": "0.11.7",
     "@types/mocha": "^2.2.44",
     "@types/node": "^8.0.47",
     "@types/uuid": "^3.4.3",
     "@types/zen-observable": "^0.5.3",
-    "apollo-link": "^1.0.0",
     "body-parser": "^1.18.2",
     "chai": "^4.1.2",
     "express": "^4.16.2",
     "graphql": "^0.12.3",
-    "graphql-subscriptions": "^0.5.4",
     "graphql-type-json": "^0.1.4",
     "istanbul": "^0.4.5",
     "iterall": "^1.1.3",
     "mocha": "^4.0.1",
     "prettier": "^1.7.4",
-    "remap-istanbul": "0.9.5",
+    "remap-istanbul": "0.9.6",
     "rimraf": "^2.6.2",
     "source-map-support": "^0.5.0",
     "tslint": "^5.8.0",
-    "typescript": "2.6.1"
+    "typescript": "2.6.2"
   }
 }

src/Interfaces.ts

@@ -52,7 +52,7 @@ export type ITypeDefinitions = ITypedef | ITypedef[];
 export type IResolverObject = {
   [key: string]: IFieldResolver<any, any> | IResolverOptions;
 };
-export type IEnumResolver = { [key: string]: string };
+export type IEnumResolver = { [key: string]: string | number };
 export interface IResolvers {
   [key: string]:
     | (() => any)