[graphql] [@apollo/client] add graphql libdef and integrate with @apollo/client

[joshuanapoli]

• Type of contribution: add libdef

Other notes:

• Add a module definition for "@apollo/client/utilities". This module has a CJS export and is meant as a public interface of the package, though not thoroughly documented. Moreover, not all of its symbols are exported at the root level; importing the sub-module in an application is necessary in some cases. In my case, I need getMainDefinition, which is shown in apollo client example code.
• Fix ApolloLink and Operation class inheritance, which were incorrectly extending a global class. This didn't create the correct class inheritance and caused wrong flow errors in correctly written application code.
• Move some hack global types back into their proper module, to match the typescript sources.

There is a limitation in flow libdefs, which makes it awkward to define a class hierarchy that spans a module boundary. The following is an error:

declare module "@apollo/client/link/core" {
  declare export class ApolloLink {};
}

declare module "@apollo/client" {
  import type { ApolloLink } from "@apollo/client/link/core";
  declare export class HttpLink extends ApolloLink {}; // value-as-type error

I tried combinations of import typeof and extends Class<Base>, but these don't seem to solve the problem.

In this PR I left the error suppression $FlowFixMe[value-as-type] in the libdef. This lets the libdef source express the class hierarchy and module membership correctly to a human reader, and there are no incorrect flow diagnostics in application code that uses these types.

[Brianzchen]

Shouldn't use Object as this resolves to any. Use { ... } or { [key: string]: any } instead

[joshuanapoli]

Fixed in 93a5212

In this case, I added a libdef for "graphql", because { ... } or { [key: string]: any } led to flow errors in correct application code around the GraphQL types.

[Brianzchen]

Should tidy this type up a bit. void | void and Object should be { ... } as mentioned above

[joshuanapoli]

Fixed in b3c6310

[Brianzchen]

Object

[joshuanapoli]

Fixed in a763180

[Brianzchen]

Re ApolloLink issue. Could you declare the class in the top level and then export/use in the two module definitions?

[joshuanapoli]

Re ApolloLink issue. Could you declare the class in the top level and then export/use in the two module definitions?

One problem with with this approach is that import type is an error at the top level of a library. I would like to use imported types (from "graphql" and "@apollo/client/...") in the ApolloLink definition.

[Brianzchen]

Re ApolloLink issue. Could you declare the class in the top level and then export/use in the two module definitions?

One problem with with this approach is that import type is an error at the top level of a library. I would like to use imported types (from "graphql" and "@apollo/client/...") in the ApolloLink definition.

Right I see