Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better support for graphql-scalars #8413

Open
Tracked by #8296 ...
charlypoly opened this issue Sep 29, 2022 · 5 comments
Open
Tracked by #8296 ...

Better support for graphql-scalars #8413

charlypoly opened this issue Sep 29, 2022 · 5 comments
Assignees
Labels
core Related to codegen core/cli kind/docs Improvements or additions to documentation kind/enhancement New feature or request

Comments

@charlypoly
Copy link
Contributor

charlypoly commented Sep 29, 2022

DX proposal:

{
   // ...
   scalars: "graphql-scalars#clientTypes"
   // ...
}

Map to the primitive (serialized) value, always, and not use the GraphQLScalar or anything from graphql-scalars lib.


Related #8412, #8296 (comment)

@charlypoly charlypoly added this to the GraphQL Code Generator v3 milestone Sep 29, 2022
@charlypoly charlypoly self-assigned this Sep 29, 2022
@Urigo
Copy link
Collaborator

Urigo commented Sep 29, 2022

I would also suggest writing in more details, maybe a guide around the whole integration of these two tools as sometimes there is a lot of confusion around them and what's possible and what not

@charlypoly charlypoly added core Related to codegen core/cli kind/docs Improvements or additions to documentation kind/enhancement New feature or request labels Sep 29, 2022
@lensbart
Copy link

lensbart commented Oct 5, 2022

Fixing this would also obviate #7763

@sschneider-ihre-pvs
Copy link

sschneider-ihre-pvs commented Nov 24, 2022

this seems to break usage with noexports and using the generated files in tsconfig include. While it does insert the correct type tsc does not like imports in definition files

@nareshbhatia
Copy link

I know this is in the v5 roadmap, but is there a temporary workaround?

Currently my graphql schema has

scalar DateTime

This generarates

export type Scalars = {
  ID: { input: string; output: string; }
  String: { input: string; output: string; }
  Boolean: { input: boolean; output: boolean; }
  Int: { input: number; output: number; }
  Float: { input: number; output: number; }
  DateTime: { input: any; output: any; }
};

Is there any way to force DateTime to be type string instead of any?

I tried the suggestion here, but it looks like the client preset and the typescript plugin work independently and don't affect each other.

Here's my current codegen configuration:

import type { CodegenConfig } from '@graphql-codegen/cli';

const config: CodegenConfig = {
  schema: './src/gql/**.graphql',
  documents: ['src/**/*.{ts,tsx}'],
  generates: {
    './src/generated/gql/': {
      preset: 'client',
      presetConfig: {
        fragmentMasking: { unmaskFunctionName: 'getFragmentData' },
      },
    },
  },
  hooks: { afterAllFileWrite: ['prettier --write'] },
};

export default config;

@nareshbhatia
Copy link

Ok, figured it out. Had to add a config.scalars in the preset itself:

import type { CodegenConfig } from '@graphql-codegen/cli';

const config: CodegenConfig = {
  schema: './src/gql/**.graphql',
  documents: ['src/**/*.{ts,tsx}'],
  generates: {
    './src/generated/gql/': {
      preset: 'client',
      presetConfig: {
        // see https://the-guild.dev/graphql/codegen/plugins/presets/preset-client#the-usefragment-helper
        fragmentMasking: { unmaskFunctionName: 'getFragmentData' },
      },
      config: {
        scalars: {
          DateTime: 'string',
        },
      },
    },
  },
  hooks: { afterAllFileWrite: ['prettier --write'] },
};

export default config;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Related to codegen core/cli kind/docs Improvements or additions to documentation kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants