Roadmap for next major version of GraphQL Code Generator

[dotansimha]

Let's try to track and suggest ideas for Codegen v2 here.

Focus on internal API and plugins, but feel free to discuss plugin-specific as well.

Internal API:

• Add a way to easily interact between plugins that affect the same output file - add a shared object across plugins that affect the same output file (to share things like namingConvention and common config, and to allow easy hooks across plugins). For example: plugin typescript can add to the shared object a method called ignoreType(), and allow other plugins to specifically ignore specific things.
• Separate config phase and allow plugins to build that shared object and parse configurations that are specific to it.
• Allow simpler interface for plugins to do more than just control output (using shared object or hooks)
• Change signature of plugin (and correct schema and schemaAst fields)
• ... your ideas here ...

typescript

• Consider to change the default value of namingConvention.enumsValues to be keep, or at least something else that reduces issues with it.

typescript-operations

• Break the dependency between typescript and typescript-operations - allowing those to run independently.
  Similar to operationTypesOnly: true, preResolveTypes: true.

typescript-react-apollo

• Change withHooks to be true by default.

typescript-resolvers

• Remove IResolvers (already deprecated)
• useSchemaStitching: false by default
• Notify typescript plugin to hide types that has mappers, if it's not in use by others.

Also, in terms of configuration, we'll aim to change the existing structure and avoid object keys, and prefer array of objects instead.

This is an example of how it will look like:

schema:
  - http://server/graphql
  - url: http://server/graphql
    headers:
      Test: 1
generates:
  - output: my-file.ts
    plugins:
      - one
      - package: add
        config:
          content: "hi"
      - package: two
        config:
          key: val

This structure is more clear and easier to use with YAML. Also, plugins configuration will be enforced to be object (unlike today, where add plugin accepts a string)