add support for eviction of field names by arguments

CHANGELOG.md

@@ -47,6 +47,9 @@
 - **[BREAKING]** Apollo Client will no longer deliver "stale" results to `ObservableQuery` consumers, but will instead log more helpful errors about which cache fields were missing. <br/>
   [@benjamn](https://github.com/benjamn) in [#6058](https://github.com/apollographql/apollo-client/pull/6058)
 
+- **[BREAKING]** `ApolloError`'s thrown by Apollo Client no longer prefix error messages with `GraphQL error:` or `Network error:`. To differentiate between GraphQL/network errors, refer to `ApolloError`'s public `graphQLErrors` and `networkError` properties. <br/>
+  [@lorensr](https://github.com/lorensr) in [#3892](https://github.com/apollographql/apollo-client/pull/3892)
+
 - `InMemoryCache` now supports tracing garbage collection and eviction. Note that the signature of the `evict` method has been simplified in a potentially backwards-incompatible way. <br/>
   [@benjamn](https://github.com/benjamn) in [#5310](https://github.com/apollographql/apollo-client/pull/5310)
 
@@ -73,14 +76,15 @@
 
 - `InMemoryCache` now has a method called `modify` which can be used to update the value of a specific field within a specific entity object:
   ```ts
-  cache.modify(cache.identify(post), {
+  cache.modify({
     comments(comments: Reference[], { readField }) {
       return comments.filter(comment => idToRemove !== readField("id", comment));
     },
-  });
+  }, cache.identify(post));
   ```
   This API gracefully handles cases where multiple field values are associated with a single field name, and also removes the need for updating the cache by reading a query or fragment, modifying the result, and writing the modified result back into the cache. Behind the scenes, the `cache.evict` method is now implemented in terms of `cache.modify`. <br/>
   [@benjamn](https://github.com/benjamn) in [#5909](https://github.com/apollographql/apollo-client/pull/5909)
+  and [#6178](https://github.com/apollographql/apollo-client/pull/6178)
 
 - `InMemoryCache` provides a new API for storing client state that can be updated from anywhere:
   ```ts

CONTRIBUTING.md

@@ -74,3 +74,127 @@ It’s important that every piece of code in Apollo packages is reviewed by at l
 4. **No unnecessary or unrelated changes.** PRs shouldn’t come with random formatting changes, especially in unrelated parts of the code. If there is some refactoring that needs to be done, it should be in a separate PR from a bug fix or feature, if possible.
 5. **Code has appropriate comments.** Code should be commented, or written in a clear “self-documenting” way.
 6. **Idiomatic use of the language.** In TypeScript, make sure the typings are specific and correct. In ES2015, make sure to use imports rather than require and const instead of var, etc. Ideally a linter enforces a lot of this, but use your common sense and follow the style of the surrounding code.
+
+## Development
+
+### Building
+
+**Build Apollo Client once:**
+
+```
+npm run build
+```
+
+**Build and watch for file changes:**
+
+```
+npm run watch
+```
+
+### Testing
+
+**Run all tests once:**
+
+```
+npm run test
+```
+
+**Run all tests in watch mode:**
+
+```
+npm run test:watch
+```
+
+**Run specific tests:**
+
+Call jest directly making sure to pass in the jest config, and use its `testRegex` option:
+
+```
+jest --config ./config/jest.config.js --testRegex __tests__/useQuery.test.tsx
+```
+
+### Wiring a checkout into an application
+
+It can be useful to link an Apollo Client checkout into an application, to test how Apollo Client development changes impact a real app. We'll use the [Apollo fullstack tutorial application](https://github.com/apollographql/fullstack-tutorial) to demonstrate this.
+
+> **Note:** The fullstack tutorial updates for Apollo Client 3 haven't been merged into `master` yet, so for now we'll use the tutorial's `apollo-client-3` branch.
+
+1) Clone and install Apollo Client.
+
+```
+git clone https://github.com/apollographql/apollo-client.git
+cd apollo-client
+npm i
+cd ..
+```
+
+> From this point forward `[apollo-client-root]` represents the root directory of your Apollo Client checkout (e.g. `/some/path/apollo-client`).
+
+2) Clone and install the fullstack tutorial.
+
+```
+git clone https://github.com/apollographql/fullstack-tutorial.git
+cd fullstack-tutorial
+git checkout apollo-client-3
+cd final/server
+npm i
+cd ../client
+npm i
+```
+
+> From this point forward `[fullstack-tutorial-root]` represents the root directory of your Fullstack Tutorial checkout (e.g. `/some/path/fullstack-tutorial`).
+
+3) Link the application's `@apollo/client` package to your Apollo Client checkout's compiled files.
+
+```
+# ... assuming still in [fullstack-tutorial-root]/final/client from step 2
+cd node_modules/@apollo
+rm -Rf ./client
+ln -s [apollo-client-root]/dist client
+```
+
+4) If using React, prevent a duplicate React version lookup error by telling your application to use Apollo Client's React version.
+
+```
+# ... assuming still in [fullstack-tutorial-root]/final/client/node_modules/@apollo from step 3
+cd ..
+rm -Rf ./react ./react-dom
+ln -s [apollo-client-root]/node_modules/react
+ln -s [apollo-client-root]/node_modules/react-dom
+```
+
+5) Start the fullstack tutorial.
+
+Server:
+
+```
+# ... assuming still in [fullstack-tutorial-root]/final/client/node_modules from step 4
+cd ../../server
+npm start
+```
+
+Client:
+
+```
+# ... in a separate terminal window
+cd [fullstack-tutorial-root]/final/client
+npm start
+```
+
+6) Start building Apollo Client and watching for file changes.
+
+```
+# ... in a separate terminal window
+cd [apollo-client-root]
+npm run watch
+```
+
+7) Verify Apollo Client changes show up in the fullstack tutorial.
+
+```
+# ... assuming still in [apollo-client-root] from step 6
+cd src
+echo "console.log('it worked');" >> index.ts
+```
+
+Visit http://localhost:3000/ and open your browsers dev console. After the Apollo Client rebuild finishes, you should see `it worked` in the console.

ROADMAP.md

@@ -6,12 +6,13 @@ Apollo Client is a framework for consuming a data graph and binding it to a user
 
 ## Apollo Client 3.0
 
-**Completion date:** Full RC available end of October 2019
+**Completion date:** RC available May 2020
 
 At a high level, the next major version of Apollo Client (roughly referred to as Apollo Client 3) aims to:
 
 * Prune outdated and overlapping API surface areas
 * Redesign the core caching layer
+* Introduce a simplified/improved local state API
 * Simplify the product's packaging
 
 ### Goals
@@ -78,9 +79,11 @@ Apollo Client 3 will feature simplified packaging for easier use and smaller bun
 
 Although we don’t have concrete timelines for the next set of work, we think these are the next challenges to tackle, ordered by priority:
 
-* Redesign Apollo Client's network layer
+* React Suspense + data fetching support
+* CLI based tooling to support things like compiling queries at build time
+* Improving/revamping Apollo Client's SSR story
+* Redesigning Apollo Client's network layer
   * We're planning out a simplified but flexible network layer that removes `Observable`'s from the `ApolloLink` API in favor of language primitives. This will simplify custom building, trim bundles, and better support multiple responses.
 * Supporting `@defer` and `@stream`
 * Fragment-based API for component isolation
-* Improved local state API
 * Cache segmenting