Merge branch 'master' into release-vNEXT

CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+### v2.3.1
+
+- Provide types for `graphql-upload` in a location where they can be accessed by TypeScript consumers of `apollo-server` packages. [ccf935f9](https://github.com/apollographql/apollo-server/commit/ccf935f9) [Issue #2092](https://github.com/apollographql/apollo-server/issues/2092)
+
 ### v2.3.0
 
 - **BREAKING FOR NODE.JS <= 8.5.0 ONLY**: To continue using Apollo Server 2.x in versions of Node.js prior to v8.5.0, file uploads must be disabled by setting `uploads: false` on the `ApolloServer` constructor options.  Without explicitly disabling file-uploads, the server will `throw` at launch (with instructions and a link to our documentation).
@@ -10,6 +14,8 @@
 
   **We intend to drop support for Node.js 6.x in the next major version of Apollo Server.**
 
+  For more information, see [PR #2054](https://github.com/apollographql/apollo-server/pull/2054) and [our documentation](https://www.apollographql.com/docs/apollo-server/v2/migration-file-uploads.html).
+
 ### v2.2.7
 
 - `apollo-engine-reporting`: When multiple instances of `apollo-engine-reporting` are loaded (an uncommon edge case), ensure that `encodedTraces` are handled only once rather than once per loaded instance. [PR #2040](https://github.com/apollographql/apollo-server/pull/2040)

docs/source/essentials/data.md

@@ -16,18 +16,18 @@ const { gql } = require('apollo-server');
 const { find, filter } = require('lodash');
 
 const schema = gql`
-type Book {
-  title: String
-  author: Author
-}
+  type Book {
+    title: String
+    author: Author
+  }
 
-type Author {
-  books: [Book]
-}
+  type Author {
+    books: [Book]
+  }
 
-type Query {
-  author: Author
-}
+  type Query {
+    author: Author
+  }
 `;
 
 const resolvers = {

docs/source/features/creating-directives.md

@@ -53,10 +53,11 @@ In order to apply this implementation to a schema that contains `@deprecated` di
 const { ApolloServer, gql } = require("apollo-server");
 
 const typeDefs = gql`
-type ExampleType {
-  newField: String
-  oldField: String @deprecated(reason: "Use \`newField\`.")
-}`;
+  type ExampleType {
+    newField: String
+    oldField: String @deprecated(reason: "Use \`newField\`.")
+  }
+`;
 
 const server = new ApolloServer({
   typeDefs,
@@ -96,11 +97,12 @@ const { ApolloServer, gql, SchemaDirectiveVisitor } = require("apollo-server");
 const { defaultFieldResolver } = require("graphql");
 
 const typeDefs = gql`
-directive @upper on FIELD_DEFINITION
+  directive @upper on FIELD_DEFINITION
 
-type Query {
-  hello: String @upper
-}`;
+  type Query {
+    hello: String @upper
+  }
+`;
 
 class UpperCaseDirective extends SchemaDirectiveVisitor {
   visitFieldDefinition(field) {
@@ -138,11 +140,12 @@ Suppose you've defined an object type that corresponds to a [REST](https://en.wi
 const { ApolloServer, gql, SchemaDirectiveVisitor } = require("apollo-server");
 
 const typeDefs = gql`
-directive @rest(url: String) on FIELD_DEFINITION
+  directive @rest(url: String) on FIELD_DEFINITION
 
-type Query {
-  people: [Person] @rest(url: "/api/v1/people")
-}`;
+  type Query {
+    people: [Person] @rest(url: "/api/v1/people")
+  }
+`;
 
 class RestDirective extends SchemaDirectiveVisitor {
   public visitFieldDefinition(field) {
@@ -173,13 +176,14 @@ Suppose your resolver returns a `Date` object but you want to return a formatted
 const { ApolloServer, gql, SchemaDirectiveVisitor } = require("apollo-server");
 
 const typeDefs = gql`
-directive @date(format: String) on FIELD_DEFINITION
+  directive @date(format: String) on FIELD_DEFINITION
 
-scalar Date
+  scalar Date
 
-type Post {
-  published: Date @date(format: "mmmm d, yyyy")
-}`;
+  type Post {
+    published: Date @date(format: "mmmm d, yyyy")
+  }
+`;
 
 class DateFormatDirective extends SchemaDirectiveVisitor {
   visitFieldDefinition(field) {
@@ -214,15 +218,16 @@ const formatDate = require("dateformat");
 const { defaultFieldResolver, GraphQLString } = require("graphql");
 
 const typeDefs = gql`
-directive @date(
-  defaultFormat: String = "mmmm d, yyyy"
-) on FIELD_DEFINITION
+  directive @date(
+    defaultFormat: String = "mmmm d, yyyy"
+  ) on FIELD_DEFINITION
 
-scalar Date
+  scalar Date
 
-type Query {
-  today: Date @date
-}`;
+  type Query {
+    today: Date @date
+  }
+`;
 
 class FormattableDateDirective extends SchemaDirectiveVisitor {
   public visitFieldDefinition(field) {
@@ -292,11 +297,12 @@ Here's how you might make sure `translate` is used to localize the `greeting` fi
 const { ApolloServer, gql, SchemaDirectiveVisitor } = require("apollo-server");
 
 const typeDefs = gql`
-directive @intl on FIELD_DEFINITION
+  directive @intl on FIELD_DEFINITION
 
-type Query {
-  greeting: String @intl
-}`;
+  type Query {
+    greeting: String @intl
+  }
+`;
 
 class IntlDirective extends SchemaDirectiveVisitor {
   visitFieldDefinition(field, details) {
@@ -519,27 +525,28 @@ const { GraphQLID } = require("graphql");
 const { createHash } = require("crypto");
 
 const typeDefs = gql`
-directive @uniqueID(
-  # The name of the new ID field, "uid" by default:
-  name: String = "uid"
-
-  # Which fields to include in the new ID:
-  from: [String] = ["id"]
-) on OBJECT
-
-# Since this type just uses the default values of name and from,
-# we don't have to pass any arguments to the directive:
-type Location @uniqueID {
-  id: Int
-  address: String
-}
+  directive @uniqueID(
+    # The name of the new ID field, "uid" by default:
+    name: String = "uid"
+
+    # Which fields to include in the new ID:
+    from: [String] = ["id"]
+  ) on OBJECT
+
+  # Since this type just uses the default values of name and from,
+  # we don't have to pass any arguments to the directive:
+  type Location @uniqueID {
+    id: Int
+    address: String
+  }
 
-# This type uses both the person's name and the personID field,
-# in addition to the "Person" type name, to construct the ID:
-type Person @uniqueID(from: ["name", "personID"]) {
-  personID: Int
-  name: String
-}`;
+  # This type uses both the person's name and the personID field,
+  # in addition to the "Person" type name, to construct the ID:
+  type Person @uniqueID(from: ["name", "personID"]) {
+    personID: Int
+    name: String
+  }
+`;
 
 class UniqueIdDirective extends SchemaDirectiveVisitor {
   visitObject(type) {

docs/source/features/mocking.md

@@ -15,9 +15,9 @@ This example demonstrates mocking a GraphQL schema with just one line of code, u
 const { ApolloServer, gql } = require('apollo-server');
 
 const typeDefs = gql`
-type Query {
-  hello: String
-}
+  type Query {
+    hello: String
+  }
 `;
 
 const server = new ApolloServer({
@@ -32,7 +32,7 @@ server.listen().then(({ url }) => {
 
 > Note: If `typeDefs` has custom scalar types, `resolvers` must still contain the `serialize`, `parseValue`, and `parseLiteral` functions
 
-Mocking logic simply looks at the type definitions and returns a string where a string is expected, a number for a number, etc. This provides the right shape of result. By default, when using mocks, any existing resolvers are ignored. See the ["Using existing resolvers with mocks"](#existing-resolvers) section below for more info on how to change this behavior. 
+Mocking logic simply looks at the type definitions and returns a string where a string is expected, a number for a number, etc. This provides the right shape of result. By default, when using mocks, any existing resolvers are ignored. See the ["Using existing resolvers with mocks"](#existing-resolvers) section below for more info on how to change this behavior.
 
 For more sophisticated testing, mocks can be customized to a particular data model.
 
@@ -44,10 +44,10 @@ In addition to a boolean, `mocks` can be an object that describes custom mocking
 const { ApolloServer, gql } = require('apollo-server');
 
 const typeDefs = gql`
-type Query {
-  hello: String
-  resolved: String
-}
+  type Query {
+    hello: String
+    resolved: String
+  }
 `;
 
 const resolvers = {
@@ -149,16 +149,16 @@ For some more background and flavor on this approach, read the ["Mocking your se
 
 The default behavior for mocks is to overwrite the resolvers already present in the schema. To keep the existing resolvers, set the `mockEntireSchema` option to false.
 
-> Note: mocking resolvers will not work if the `mocks` option is `false`, even if `mockEntireSchema` is true. 
+> Note: mocking resolvers will not work if the `mocks` option is `false`, even if `mockEntireSchema` is true.
 
 ```js line=26
 const { ApolloServer, gql } = require('apollo-server');
 
 const typeDefs = gql`
-type Query {
-  hello: String
-  resolved: String
-}
+  type Query {
+    hello: String
+    resolved: String
+  }
 `;
 
 const resolvers = {

docs/source/features/scalars-enums.md

@@ -36,17 +36,15 @@ const { ApolloServer, gql } = require('apollo-server');
 const GraphQLJSON = require('graphql-type-json');
 
 const schemaString = gql`
+  scalar JSON
 
-scalar JSON
-
-type Foo {
-  aField: JSON
-}
-
-type Query {
-  foo: Foo
-}
+  type Foo {
+    aField: JSON
+  }
 
+  type Query {
+    foo: Foo
+  }
 `;
 
 const resolveFunctions = {
@@ -92,17 +90,15 @@ const myCustomScalarType = new GraphQLScalarType({
 });
 
 const schemaString = gql`
+  scalar MyCustomScalar
 
-scalar MyCustomScalar
-
-type Foo {
-  aField: MyCustomScalar
-}
-
-type Query {
-  foo: Foo
-}
+  type Foo {
+    aField: MyCustomScalar
+  }
 
+  type Query {
+    foo: Foo
+  }
 `;
 
 const resolverFunctions = {
@@ -127,11 +123,12 @@ The goal is to define a `Date` data type for returning `Date` values from the da
 The following is the implementation of the `Date` data type. First, the schema:
 
 ```js
-const typeDefs = gql`scalar Date
+const typeDefs = gql`
+  scalar Date
 
-type MyType {
-   created: Date
-}
+  type MyType {
+    created: Date
+  }
 `
 ```
 
@@ -172,11 +169,12 @@ server.listen().then(({ url }) => {
 In this example, we follow the [official GraphQL documentation](http://graphql.org/docs/api-reference-type-system/) for the scalar datatype, which demonstrates how to validate a database field that should only contain odd numbers in GraphQL. First, the schema:
 
 ```js
-const typeDefs = gql`scalar Odd
+const typeDefs = gql`
+  scalar Odd
 
-type MyType {
+  type MyType {
     oddValue: Odd
-}
+  }
 `
 ```
 

docs/source/features/subscriptions.md

@@ -21,19 +21,22 @@ Subscriptions are another root level type, similar to Query and Mutation. To sta
 
 ```js line=2-4
 const typeDefs = gql`
-type Subscription {
-  postAdded: Post
-}
-type Query {
-  posts: [Post]
-}
-type Mutation {
-  addPost(author: String, comment: String): Post
-}
-type Post {
-  author: String
-  comment: String
-}
+  type Subscription {
+    postAdded: Post
+  }
+
+  type Query {
+    posts: [Post]
+  }
+
+  type Mutation {
+    addPost(author: String, comment: String): Post
+  }
+
+  type Post {
+    author: String
+    comment: String
+  }
 `
 ```
 
@@ -84,7 +87,7 @@ const server = new ApolloServer({
 });
 ```
 
-> `connection` contains various metadata, found [here](https://github.com/apollographql/subscriptions-transport-ws/blob/88970eaf6d2e3f68f98696de00631acf4062c088/src/server.ts#L312-L321). 
+> `connection` contains various metadata, found [here](https://github.com/apollographql/subscriptions-transport-ws/blob/88970eaf6d2e3f68f98696de00631acf4062c088/src/server.ts#L312-L321).
 
 As you can see Apollo Server 2.0 allows realtime data without invasive changes to existing code.
 For a full working example please have a look to [this repo](https://github.com/daniele-zurico/apollo2-subscriptions-how-to) provided by [Daniele Zurico](https://github.com/daniele-zurico/apollo2-subscriptions-how-to)