Configuration

The Apollo CLI and VS Code extension can be configured with an Apollo config file. Apollo configuration is stored as a plain object in an apollo.config.js file which exports the configuration. For more information about configuring an Apollo project, see: https://www.apollographql.com/docs/devtools/apollo-config/.

Note: the use of the apollo key in the project's package.json file for configuration is deprecated, and will no longer be supported in Apollo v3

You'll need to set up your Apollo configuration for all the features of the Apollo CLI and VS Code extension to work correctly. For full details on how to do that, visit our docs. A basic configuration (apollo.config.js style) looks something like this:

module.exports = {
  client: {
    name: "My Client Project",
    service: "my-service-name"
  }
};

Code Generation

Accompanying Libraries

See Apollo iOS for details on the mapping from GraphQL results to Swift types, as well as runtime support for executing queries and mutations. For Scala, see React Apollo Scala.js for details on how to use generated Scala code in a Scala.js app with Apollo Client.

gql template support

If the source file for generation is a JavaScript or TypeScript file, the codegen will try to extrapolate the queries inside the gql tag templates.

The tag name is configurable using the CLI --tagName option.

Typescript and Flow

When using the codegen command with Typescript or Flow, make sure to add the __typename introspection field to every selection set within your graphql operations.

If you're using a client like apollo-client that does this automatically for your GraphQL operations, pass in the --addTypename option to apollo codegen:generate to make sure the generated Typescript and Flow types have the __typename field as well. This is required to ensure proper type generation support for GraphQLUnionType and GraphQLInterfaceType fields.

Why is the \\typename field required?

Using the type information from the GraphQL schema, we can infer the possible types for fields. However, in the case of a GraphQLUnionType or GraphQLInterfaceType, there are multiple types that are possible for that field. This is best modeled using a disjoint union with the __typename as the discriminant.

For example, given a schema:

...
interface Character {   name: String! }
type Human implements Character {   homePlanet: String }
type Droid implements Character {   primaryFunction: String }
...

Whenever a field of type Character is encountered, it could be either a Human or Droid. Human and Droid objects will have a different set of fields. Within your application code, when interacting with a Character you'll want to make sure to handle both of these cases.

Given this query:

query Characters {
  characters(episode: NEW_HOPE) {
    name
... on Human {       homePlanet     }
... on Droid {       primaryFunction     }   } }

Apollo Codegen will generate a union type for Character.

export type CharactersQuery = {
  characters: Array<
    | {
        __typename: "Human",
        name: string,
        homePlanet: ?string
      }
    | {
        __typename: "Droid",
        name: string,
        primaryFunction: ?string
      }
  >
};

This type can then be used as follows to ensure that all possible types are handled:

function CharacterFigures({ characters }: CharactersQuery) {
  return characters.map(character => {
    switch (character.__typename) {
      case "Human":
        return (
          <HumanFigure
            homePlanet={character.homePlanet}
            name={character.name}
          />
        );
      case "Droid":
        return (
          <DroidFigure
            primaryFunction={character.primaryFunction}
            name={character.name}
          />
        );
    }
  });
}

Contributing

This repo is composed of multiple packages. The apollo-cli contains the core CLI commands. The apollo-codegen-core package contains all the compiler APIs needed to implement code generation support for new languages. The other apollo-codegen-* packages implement code generation support for individual languages.

Running tests locally:

npm install
npm test

You can also run npm commands within package folders after you have bootstrapped the repository (part of npm install).

Note: if you have issues, try npm run clean && npm i to get a fresh install of the packages. Occasionally problems arise when removed dependencies stay around

Nock tests

To display the debugging messages for nock, run the following command:

DEBUG=nock.* npm test

It can also be helpful to print standard out during testing. To enable logging, add the following configuration to the stdout function call during test creation:

.stdout({ print: true })

Active Development / Debugging

To simplify the development process, you may want to step through and debug commands whose behavior you're modifying. To do this, run the executable with node in debug mode like so, where <command> is a valid CLI command like client:check or service:push:

node --inspect-brk=9002 packages/apollo/bin/run <command>

If you're using VS Code, you can run the included "Attach to CLI Debugger" launch task and debug right from VS Code! Otherwise, you may use the Chrome inspector or other Node debugger of your choice.

Regenerating Mocked Network Data

Some integration tests rely on mocked server data (service:check for example). Mock data is generated by making real network requests and recording those requests with nock's recording feature. Stop mocking network calls and add nock.recorder.rec() before network calls are made. For service:check, change apiKey to a real Apollo API key. Then run the tests and nock will output code to mock requests to the console. You can (and probably should) pare down the request to be less brittle (by only checking for an operation name, for example). See src/commands/service/tests/check.test.ts for an example of how a mocked network request will look.

Publishing

• Make sure the CHANGELOG.md is updated with all changes committed since the last release. Make sure the versions for each package to update are correct.
• Run npm run release:version-bump -- <bumpish>

• Run npm run release:start-ci-publish locally

• Circle will notify the appropriate Apollo team slack channel when ready to release

Maintainers

• @JakeDawkins (Apollo)