You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While generating TypeScript types with ts-gql, we've encountered an issue where several types are defined but not used within the codebase. These unused types are being flagged by ESLint as 'defined but never used'. For reference and replication purposes, I have created a sample Turbo Repo Next.js app with GraphQL, which can be found here: https://github.com/udhaya21/Next-GQL-APP
The following are examples of the generated types that are not utilized:
TSGQLMaybeArray in schema.d.ts
providedFragments in schema.d.ts
HelloQueryVariables in Hello.ts
TSGQLDocuments in Hello.ts
Due to our stringent CI/CD pipeline rules, which include a zero tolerance for unused variables, these warnings from ESLint cause the pipeline to fail.
Workaround
As a temporary measure, @lukebennett88 adjusted ESLint to ignore the generated folder to prevent these warnings from causing build failures. However, this workaround is not ideal as it may overlook other important warnings.
Expected Behavior
Ideally, ts-gql should generate only the types that are used in the codebase, or at least provide an option to exclude certain types from being generated to prevent linting issues.
Additional Context
Below is a screenshot of the terminal output that displays the warnings in question.
I would appreciate your guidance on this matter. Is there a configuration option within ts-gql to circumvent the generation of these unused types, or is there a recommended method to better handle this situation?
The text was updated successfully, but these errors were encountered:
I want to clarify that the issue was not with ESLint, but TypeScript when using the noUnusedLocals flag.
With ESLint, we can add ignorePatterns: ["__generated__/**/*"], and it won't try to lint those files.
Putting __generated__ in the exclude array of the tsconfig doesn't work if you're referencing those files anywhere.
I can think of a few possible solutions:
Do nothing. Leave it up to consumers to turn off noUnusedLocals in the app and use ESLint to check for unused variables instead.
Have ts-gql export the unused type so there is no warning.
Update ts-gql to not generate the query variable's type if the query doesn't accept any variables.
Have ts-gql generate a .d.ts instead of a .ts file so it doesn't get type checked at all if skipLibCheck is turned on.
Description
While generating TypeScript types with ts-gql, we've encountered an issue where several types are defined but not used within the codebase. These unused types are being flagged by ESLint as 'defined but never used'. For reference and replication purposes, I have created a sample Turbo Repo Next.js app with GraphQL, which can be found here: https://github.com/udhaya21/Next-GQL-APP
The following are examples of the generated types that are not utilized:
TSGQLMaybeArray
inschema.d.ts
providedFragments
inschema.d.ts
HelloQueryVariables
inHello.ts
TSGQLDocuments
inHello.ts
Due to our stringent CI/CD pipeline rules, which include a zero tolerance for unused variables, these warnings from ESLint cause the pipeline to fail.
Workaround
As a temporary measure, @lukebennett88 adjusted ESLint to ignore the generated folder to prevent these warnings from causing build failures. However, this workaround is not ideal as it may overlook other important warnings.
Expected Behavior
Ideally,
ts-gql
should generate only the types that are used in the codebase, or at least provide an option to exclude certain types from being generated to prevent linting issues.Additional Context
Below is a screenshot of the terminal output that displays the warnings in question.
I would appreciate your guidance on this matter. Is there a configuration option within ts-gql to circumvent the generation of these unused types, or is there a recommended method to better handle this situation?
The text was updated successfully, but these errors were encountered: