Merge branch 'cloneDeepSymbols' of https://github.com/MrDoomBringer/a…

…pollo-client into cloneDeepSymbols

.circleci/config.yml

@@ -7,22 +7,8 @@ jobs:
     steps:
       - checkout
       - run: npm run ci:precheck
-      - restore_cache:
-          keys:
-            # When lock file changes, use increasingly general patterns to
-            # restore cache
-            - npm-v3-{{ .Branch }}-{{ checksum "package-lock.json" }}
-            - npm-v3-{{ .Branch }}-
-            - npm-v3-
       - run: npm version
       - run: npm ci
-      - save_cache:
-          key: npm-v3-{{ .Branch }}-{{ checksum "package-lock.json" }}
-          paths:
-            # This should cache the npm cache instead of node_modules, which is
-            # needed because npm ci actually removes node_modules before
-            # installing to guarantee a clean slate.
-            - ~/.npm
       - run: npm run bundlesize
 
   Tests:
@@ -31,22 +17,8 @@ jobs:
     steps:
       - checkout
       - run: npm run ci:precheck
-      - restore_cache:
-          keys:
-            # When lock file changes, use increasingly general patterns to
-            # restore cache
-            - npm-v3-{{ .Branch }}-{{ checksum "package-lock.json" }}
-            - npm-v3-{{ .Branch }}-
-            - npm-v3-
       - run: npm version
       - run: npm ci
-      - save_cache:
-          key: npm-v3-{{ .Branch }}-{{ checksum "package-lock.json" }}
-          paths:
-            # This should cache the npm cache instead of node_modules, which is
-            # needed because npm ci actually removes node_modules before
-            # installing to guarantee a clean slate.
-            - ~/.npm
       - run:
           name: Jest suite with coverage
           command: npm run test:ci

config/bundlesize.ts

@@ -0,0 +1,26 @@
+import { readFileSync } from "fs";
+import { join } from "path";
+import { gzipSync } from "zlib";
+import bytes from "bytes";
+
+const gzipBundleByteLengthLimit = bytes("31.85KB");
+const minFile = join("dist", "apollo-client.min.cjs");
+const minPath = join(__dirname, "..", minFile);
+const gzipByteLen = gzipSync(readFileSync(minPath)).byteLength;
+const overLimit = gzipByteLen > gzipBundleByteLengthLimit;
+
+const message = `Minified + GZIP-encoded bundle size for ${
+  minFile
+} = ${
+  bytes(gzipByteLen, { unit: "KB" })
+}, ${
+  overLimit ? "exceeding" : "under"
+} limit ${
+  bytes(gzipBundleByteLengthLimit, { unit: "KB" })
+}`;
+
+if (overLimit) {
+  throw new Error(message);
+} else {
+  console.log(message);
+}

docs/source/api/link/apollo-link-rest.md

@@ -23,7 +23,7 @@ With `apollo-link-rest`, you can call your endpoints inside your GraphQL queries
 To get started, first install Apollo Client and any `peerDependencies` we need:
 
 ```bash
-npm install --save @apollo/client apollo-link-rest graphql qs
+npm install --save @apollo/client apollo-link-rest graphql graphql-anywhere qs
 ```
 
 After this, you're ready to setup the Apollo Client instance:

docs/source/config.json

@@ -40,7 +40,7 @@
       "Local-only fields": "/local-state/managing-state-with-field-policies",
       "Reactive variables": "/local-state/reactive-variables",
       "Client-side schema": "/local-state/client-side-schema",
-      "Local resolvers (deprecated)": "/local-state/local-resolvers"
+      "Local resolvers": "/local-state/local-resolvers"
     },
     "Development & Testing": {
       "Developer tools": "/development-testing/developer-tooling",

docs/source/development-testing/static-typing.md

@@ -572,3 +572,64 @@ export const withCharacter = graphql<InputProps, Response, {}, Prop>(HERO_QUERY,
   })
 });
 ```
+
+## Using `TypeDocumentNode`
+
+In TypeScript, all APIs that take `DocumentNode` parameters may alternatively take `TypeDocumentNode<Data, Variables>`. This type has the same JavaScript representation but allows the APIs to infer the data and variable types instead of requiring you to specify types explicitly at the call site. This technique could allow us to modify the [`useQuery` example](#usequery) above to use type inference:
+
+```tsx
+import React from 'react';
+import { useQuery, gql, TypedDocumentNode } from '@apollo/client';
+
+interface RocketInventoryData {
+  rocketInventory: RocketInventory[];
+}
+
+interface RocketInventoryVars {
+  year: number;
+}
+
+const GET_ROCKET_INVENTORY: TypedDocumentNode<RocketInventoryData, RocketInventoryVars> = gql`
+  query GetRocketInventory($year: Int!) {
+    rocketInventory(year: $year) {
+      id
+      model
+      year
+      stock
+    }
+  }
+`;
+
+export function RocketInventoryList() {
+  const { loading, data } = useQuery(
+    GET_ROCKET_INVENTORY,
+    { variables: { year: 2019 } }
+  );
+  return (
+    <div>
+      <h3>Available Inventory</h3>
+      {loading ? (
+        <p>Loading ...</p>
+      ) : (
+        <table>
+          <thead>
+            <tr>
+              <th>Model</th>
+              <th>Stock</th>
+            </tr>
+          </thead>
+          <tbody>
+            {data && data.rocketInventory.map(inventory => (
+              <tr>
+                <td>{inventory.model}</td>
+                <td>{inventory.stock}</td>
+              </tr>
+            ))}
+          </tbody>
+        </table>
+      )}
+    </div>
+  );
+}
+
+```

docs/source/local-state/local-resolvers.mdx

@@ -1,11 +1,11 @@
 ---
-title: Local resolvers (deprecated)
+title: Local resolvers
 description: Manage local data with GraphQL like resolvers
 ---
 
-> ⚠️ **DEPRECATION WARNING:** Local resolvers are still available in Apollo Client 3, but they are deprecated. We recommend using field policies instead, as described in [Local-only fields](./managing-state-with-field-policies/).
+> 📄 **NOTE:** We recommend using field policies instead of local resolvers as described in [Local-only fields](./managing-state-with-field-policies/).
 >
-> Local resolver support will be removed from the core of Apollo Client in a future major release, but in a future major release it will be possible to achieve the functionality of local resolvers using an `ApolloLink`, as described in [this issue](https://github.com/apollographql/apollo-client/issues/10060).
+> Local resolver support will be moved out of the core of Apollo Client in a future major release. The same or similar functionality will be available via `ApolloLink`, as described in [this issue](https://github.com/apollographql/apollo-client/issues/10060).
 
 We've learned how to manage remote data from our GraphQL server with Apollo Client, but what should we do with our local data? We want to be able to access boolean flags and device API results from multiple components in our app, but don't want to maintain a separate Redux or MobX store. Ideally, we would like the Apollo cache to be the single source of truth for all data in our client application.
 
@@ -1086,4 +1086,4 @@ The idea of using client side resolvers to manage local state was first introduc
 
 To help address limitations in the local resolver API, we have designed and implemented a new approach for managing local state in Apollo Client 3.0, that works as a direct extension of the cache. Field policies and reactive variables not only help provide a better developer experience from an API use and functionality point of view, but they also improve performance and provide a more reliable foundation for local state management. Re-thinking local state handling with the Apollo Client cache in mind has helped reduce a large number of local state bugs caused by local resolvers being a few too many layers removed from the cache internals.
 
-The [managing state with field policies](./managing-state-with-field-policies) section goes into more detail around what Apollo Client 3's new local state management capabilities look like. We highly recommend reviewing and considering the use of these new API's as a replacement for local resolvers. Local resolvers are still supported in Apollo Client 3, but should be considered deprecated. Local resolver functionality will be removed in a future major version of Apollo Client.
+The [managing state with field policies](./managing-state-with-field-policies) section goes into more detail around what Apollo Client 3's new local state management capabilities look like. We highly recommend reviewing and considering the use of these new API's as a replacement for local resolvers. Local resolvers are still supported in Apollo Client 3 but will be moved out of the core module in a future major release.

docs/source/local-state/local-state-management.mdx

@@ -57,12 +57,12 @@ Whenever the value of a reactive variable changes, Apollo Client automatically d
 
 [Get started with reactive variables](./reactive-variables)
 
-## Local resolvers (deprecated)
+## Local resolvers
 
 > Available in Apollo Client >= 2.5
 
 In earlier versions of Apollo Client, you define **local resolvers** to populate and modify local-only fields. These resolvers are similar in structure and purpose to the [resolvers that your GraphQL server defines](/apollo-server/data/resolvers/).
 
-This functionality is still available in Apollo Client 3, but it is deprecated.
+This functionality is still available in Apollo Client 3, but will be moved out of the core module in a future major release.
 
 [Learn more about local resolvers](./local-resolvers)