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

Issue: Explicit type annotation is needed when initialising graphQL tada #376

Closed
3 tasks done
JFSoler opened this issue Aug 22, 2024 · 3 comments · Fixed by #377
Closed
3 tasks done

Issue: Explicit type annotation is needed when initialising graphQL tada #376

JFSoler opened this issue Aug 22, 2024 · 3 comments · Fixed by #377
Labels
won't fix 🛑 This issue won't be fixed as part of the current roadmap

Comments

@JFSoler
Copy link

JFSoler commented Aug 22, 2024

Describe the bug

build fails with typescript v5.5 onwards while having the option "declaration" enabled in tsconfig.

// tsconfig.json

{
  "compilerOptions": {
    "declaration": true,
    ...
  }
}
// graphql.ts

import { initGraphQLTada } from 'gql.tada';
import type { introspection } from './generated/supergraph.d.ts';

export const graphql = initGraphQLTada<{
  disableMasking: true;
  introspection: introspection;
}>();

raised error:

error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

export const graphql = initGraphQLTada<{

Reproduction

No response

gql.tada version

gql.tada v1.8.6

Validations

  • I can confirm that this is a bug report, and not a feature request, RFC, question, or discussion, for which GitHub Discussions should be used
  • Read the docs.
  • Follow our Code of Conduct
@kitten kitten added the won't fix 🛑 This issue won't be fixed as part of the current roadmap label Aug 22, 2024
@kitten
Copy link
Member

kitten commented Aug 22, 2024

That's a new sanity check afaik, but nothing we can do about this afaik. The only way around this is to declare the graphql function's type manually in a declaration file. Otherwise, TypeScript will likely not recognise that it can reuse the existing declaration, since it's separate from the output.

FWIW, it's not a good idea to share the graphql function via declarations in this way. There might be ways around this, but in general, this isn't built to be shared but to be used in a "local" code base in your repository or monorepo

@JFSoler
Copy link
Author

JFSoler commented Aug 22, 2024

That's a new sanity check afaik, but nothing we can do about this afaik. The only way around this is to declare the graphql function's type manually in a declaration file. Otherwise, TypeScript will likely not recognise that it can reuse the existing declaration, since it's separate from the output.

At least I grabbed all the internal definitions from gql-tada.d.ts so that I could have schemaOfSetup and configOfSetup in the graphql.ts file and that fixed the build issue. Example:

// all the internal type definitions from gql-tada.d.ts file

interface Setup extends AbstractSetupSchema {
  disableMasking: true;
  introspection: introspection;
}

export const graphql: GraphQLTadaAPI<schemaOfSetup<Setup>, configOfSetup<Setup>> = initGraphQLTada<Setup>();

I know I'll never do this but I was testing whether that worked.

FWIW, it's not a good idea to share the graphql function via declarations in this way. There might be ways around this, but in general, this isn't built to be shared but to be used in a "local" code base in your repository or monorepo

what do you mean by "local" code base? I was following what's on https://gql-tada.0no.co/get-started/installation#initializing-gql-tada-manually to write GQL documents.

@kitten
Copy link
Member

kitten commented Aug 22, 2024

You were following it, but in a typical "app" build output, I wouldn't expect declarations to be generated, so I assume it's isolated in a package that isn't aliased in a monorepo, but instead shared declarations, or is a library that's being built.
But If you're just testing this all good.

I think we can make this more ergonomic though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
won't fix 🛑 This issue won't be fixed as part of the current roadmap
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants