Issue workflow progress
Progress of the issue based on the
Contributor Workflow
Describe the bug
If you import something from @graphql-tools/utils in your TypeScript project, and you are using a fixed `lib' in your tsconfig.json (e.g. es2024), you get the following type errors when you run typescript:
node_modules/@graphql-tools/utils/typings/executor.d.ts:8:159 - error TS2304: Cannot find name 'Disposable'.
8 export type DisposableSyncExecutor<TBaseContext = Record<string, any>, TBaseExtensions = Record<string, any>> = SyncExecutor<TBaseContext, TBaseExtensions> & Disposable;
~~~~~~~~~~
node_modules/@graphql-tools/utils/typings/executor.d.ts:9:161 - error TS2304: Cannot find name 'AsyncDisposable'.
9 export type DisposableAsyncExecutor<TBaseContext = Record<string, any>, TBaseExtensions = Record<string, any>> = AsyncExecutor<TBaseContext, TBaseExtensions> & AsyncDisposable;
~~~~~~~~~~~~~~~
Found 2 errors in the same file, starting at: node_modules/@graphql-tools/utils/typings/executor.d.ts:8
The issue can be worked around in two ways
- use
"lib": "esnext" (or add esnext.disposable) in your tsconfig.json
- set
skipLibCheck to false in your tsconfig.json
To Reproduce Steps to reproduce the behavior:
https://stackblitz.com/edit/graphql-tools-ts-lib-issue
Open a terminal and type "npm run build" (the default dev script does not run typescript)
Expected behavior
The package can be used in an app without skipLibCheck: true and with a regular lib version (like es2023 or es2024).
Environment:
- OS:
@graphql-tools/...: 10.8.0 or higher
- NodeJS:
Additional context
The issue has been introduced in this PR: #6921
The Explicit resource management, where the Disposable and AsyncDisposable types come from, is currently in phase 3 and has not been released in a ecmascript version. Therefore, it's still only part of "esnext" in typescript. I think a lib should not force an app to enable experimental typescript features, so I would expect the lib to work with one of the released versions. Also, the breaking change has been introduced in a minor version - requiring new typescript lib features should be considered a breaking change and only done in major versions.
To prevent issues like this, it might be beneficial to set an explicit lib' version in the tsconfig.json` of this repo and communicate that as required for dependents.
While skipLibCheck: true removes the error, this is not a good solution because it ignores all type problems in all libraries used by an app, and replaces problematic silently with any.
Issue workflow progress
Progress of the issue based on the
Contributor Workflow
Describe the bug
If you import something from
@graphql-tools/utilsin your TypeScript project, and you are using a fixed `lib' in your tsconfig.json (e.g. es2024), you get the following type errors when you run typescript:The issue can be worked around in two ways
"lib": "esnext"(or addesnext.disposable) in yourtsconfig.jsonskipLibChecktofalsein yourtsconfig.jsonTo Reproduce Steps to reproduce the behavior:
https://stackblitz.com/edit/graphql-tools-ts-lib-issue
Open a terminal and type "npm run build" (the default dev script does not run typescript)
Expected behavior
The package can be used in an app without
skipLibCheck: trueand with a regular lib version (like es2023 or es2024).Environment:
@graphql-tools/...: 10.8.0 or higherAdditional context
The issue has been introduced in this PR: #6921
The Explicit resource management, where the
DisposableandAsyncDisposabletypes come from, is currently in phase 3 and has not been released in a ecmascript version. Therefore, it's still only part of "esnext" in typescript. I think a lib should not force an app to enable experimental typescript features, so I would expect the lib to work with one of the released versions. Also, the breaking change has been introduced in a minor version - requiring new typescript lib features should be considered a breaking change and only done in major versions.To prevent issues like this, it might be beneficial to set an explicit
lib' version in thetsconfig.json` of this repo and communicate that as required for dependents.While
skipLibCheck: trueremoves the error, this is not a good solution because it ignores all type problems in all libraries used by an app, and replaces problematic silently withany.