Comments (21)
Can confirm same issue. Rolling back to 5.1.0
fixed temporarily.
from graphql-request.
Wow had no idea internals were being depended upon like this. This is what exports map is for, explicit contracts around entry points that is actually maintainable by library authors.
The new exports also do not expose the types.dom
entry point so graphql-codegen
cannot be updated to work currently.
I'll need to understand what the use-case was and how to properly support it officially going forward. Any help in doing that (understanding) appreciated. I'll try to investigate later this month myself either way.
from graphql-request.
There is a workaround using hooks to fix the file after generation. Found the idea here: dotansimha/graphql-code-generator-community#501, see also Lifecycle Hooks.
For 5.2.0 it's fine to replace graphql-request/dist/types.dom
with graphql-request/src/types.dom
using:
hooks:
afterOneFileWrite:
- 'gsed -i -e"s|graphql-request/dist/types\.dom|graphql-request/src/types.dom|g"'
For 6.0.0
For me, my code generation uses only RequestInit
from the "Dom"
named import statement. RequestInit
is available by default in the typescript package. So I adapted the hook, removed the import statement and replaced all Dom.RequestInit
with RequestInit
. Does work for now.
hooks:
afterOneFileWrite:
- 'gsed -i -e"s|Dom\.RequestInit|RequestInit|g"'
- 'gsed -i -e"/graphql-request\/dist\/types\.dom/d"'
Edit: Update still not possible since at least for me since @graphql-codegen/typescript-graphql-request
requires ~5.1.0
as a peer dependency 😕
from graphql-request.
Wow had no idea internals were being depended upon like this. This is what exports map is for, explicit contracts around entry points that is actually maintainable by library authors.
Hyrum’s Law—“With a sufficient number of users, every observable behavior of your system will be depended upon by someone.”
:)
Appreciate your efforts on maintaining this.
from graphql-request.
fixed on @graphql-codegen/[email protected]
https://github.com/dotansimha/graphql-code-generator-community/releases/tag/release-1684417928535
from graphql-request.
Issue is located here: https://github.com/dotansimha/graphql-code-generator-community/blob/890aabe2c018a39e358dca5896b2b2fd9148fd4e/packages/plugins/typescript/graphql-request/src/visitor.ts#L51-L52
from graphql-request.
Can also confirm this issue
from graphql-request.
@jasonkuhrt can you please pin this issue for visibility? Thanks
from graphql-request.
I'll need to understand what the use-case was and how to properly support it officially going forward. Any help in doing that (understanding) appreciated
This might not be the only use-case, but what is being used by our generated code is the Dom.RequestInit["headers"]
as shown in the example below:
import { GraphQLClient } from 'graphql-request';
import * as Dom from 'graphql-request/dist/types.dom';
export function getSdk(client: GraphQLClient, withWrapper: SdkFunctionWrapper = defaultWrapper) {
return {
XYZ(variables: XYZMutationVariables, requestHeaders?: Dom.RequestInit["headers"]): Promise<XYZMutation> {
return withWrapper((wrappedRequestHeaders) => client.request<XYZMutation>(XYZDocument, variables, {...requestHeaders, ...wrappedRequestHeaders}), 'XYZ', 'mutation');
},
};
};
basically it generates named wrapper functions around client.request(document, vars, headers)
for each Query/Mutation. When doing this it needs access to the variables and headers types. And I'm guessing the headers types where easiest to get from the Dom
type.
Exporting the header type from this library and changing the codegen library here seems like it should be enough:
link
this._additionalImports.push(`${typeImport} { GraphQLClient } from 'graphql-request';`);
this._additionalImports.push(
`${typeImport} * as Dom from 'graphql-request/dist/types.dom${fileExtension}';`,
);
I'm guessing if the headers are exported next to the grapqlClient the import could be merged with the line above.
And the references to the headers (Dom.RequestInit["headers"]
) could be updated in the lines below:
link
}, requestHeaders?: Dom.RequestInit["headers"]): Promise<{ data: ${
o.operationResultType
}; extensions?: ${this.config.extensionsType}; headers: Dom.Headers; status: number; }> {
return withWrapper((wrappedRequestHeaders) => client.rawRequest<${
o.operationResultType
}>(${docArg}, variables, {...requestHeaders, ...wrappedRequestHeaders}), '${operationName}', '${operationType}');
}`;
}
return `${operationName}(variables${optionalVariables ? '?' : ''}: ${
o.operationVariablesTypes
}, requestHeaders?: Dom.RequestInit["headers"]): Promise<${o.operationResultType}> {
return withWrapper((wrappedRequestHeaders) => client.request<${
o.operationResultType
}>(${docVarName}, variables, {...requestHeaders, ...wrappedRequestHeaders}), '${operationName}', '${operationType}');
}`;
from graphql-request.
@efstathiosntonas Yes, please. I think RequestInit
must be replaced with HeadersInit
. I haven't checked it yet, but it probably got renamed in graphql-request 6.1
from graphql-request.
What's the current state of this? I am on 5.0.0 and the generated code does not include any import for the Dom
interface. Therefore, I get:
⚠ Error(TS2503) |
Cannot find namespace 'Dom'.
My config:
import type { CodegenConfig } from '@graphql-codegen/cli'
import { loadEnv } from 'vite'
const { CAISY_PROJECT_ID, CAISY_API_KEY } = loadEnv(process.env.NODE_ENV as string, process.cwd(), '')
const config: CodegenConfig = {
overwrite: true,
schema: {
[`https://cloud.caisy.io/api/v3/e/${CAISY_PROJECT_ID}/graphql`]: {
headers: {
'x-caisy-apikey': CAISY_API_KEY || '',
},
},
},
generates: {
'gen/caisy.gen.ts': {
documents: 'src/gql/**/*.gql',
plugins: ['typescript', 'typescript-operations', 'typescript-graphql-request'],
config: {
rawRequest: true,
useTypeImports: true,
},
},
},
}
export default config
from graphql-request.
hey @madebyfabian , I was in the same situation and it indeed is resolved in @graphql-codegen/typescript-graphql-request
- but it's not included in a stable release yet - 5.0.0 indeed still contains the Dom.Headers
type usage.
You can find that Dom.Headers
was changed to just Headers
by looking in the plug-in source here:
https://github.com/dotansimha/graphql-code-generator-community/blob/main/packages/plugins/typescript/graphql-request/src/visitor.ts#L132C55-L132C56
But you need to install the v6 alpha to actually get it, if you install @graphql-codegen/[email protected]
and you should be good to go. The alpha seems stable enough (at least for me).
Alternatively you could do something similar to #467 (comment) , and simply replace Dom.Headers
for Headers
after generating the client.
Hope that helps.
from graphql-request.
@RobbyUitbeijerse Thank you very much for the detailed update! I upgraded the package to the v6 alpha and don't have any type errors anymore.
from graphql-request.
This issue is happening as well.
from graphql-request.
Thank you so much @@michaelgmcd, you rock. Most problems are gone now, however, I still have this one:
Argument of type 'HeadersInit | undefined' is not assignable to parameter of type 'RequestInit | undefined'.
from graphql-request.
@Zerebokep let me know if you wish to reopen this
from graphql-request.
Hello @efstathiosntonas, I noticed an issue in this release (I can create a new issue if needed but it is related to this one)
The change int he import for "'graphql-request/build/cjs/types';" was not applied everywhere, and the Dom.Headers
occurrence create typing errors. A simple way to see the errors is just by using this configuration with at least one query
const config: CodegenConfig = {
schema: `${graphqlServer}/graphql`,
documents: ['src/**/*.gql'],
generates: {
'./src/server/generated/requests.ts': {
plugins: ['typescript', 'typescript-operations', 'typescript-graphql-request'],
config: {
rawRequest: true
},
}
}
}
export default config
from graphql-request.
before you ask a question like this, try the latest version first.
I'm on 6.1.0 and graphql-codegen runs fine with it
from graphql-request.
@fungilation I of course mean the package version of @graphql-codegen/typescript-graphql-request
. Which is actually the most recent at 5.0.0. I am also on the most recent version of graphql-request
(6.1.0).
from graphql-request.
@graphql-codegen/[email protected]
This also solved it for me!
from graphql-request.
@efstathiosntonas Yes, please. I think
RequestInit
must be replaced withHeadersInit
. I haven't checked it yet, but it probably got renamed in graphql-request 6.1
I realised this error was related to my custom fetcher, everything is fine now. Thank you again.
from graphql-request.
Related Issues (20)
- Finish Graffle documentation
- Polish Roundup
- Make orThrow methods come from an extension
- responseMiddleware isn't a middleware HOT 2
- Socket hang up error with Node 20 on second request
- All examples produce a 404 not found error HOT 1
- envelope response optional if errors in envelope
- Randomly generate names
- with method as extension HOT 1
- support for subscription type
- Error "Cannot find module '../_.js'" when trying to compile the generated client HOT 2
- Results are not typed HOT 2
- Unable to add an entry in request header through middleware HOT 1
- Stop using Atlas schema for testing
- Make generated interface an extension
- Add support for oneOf
- Make output a hook
- Effect extension
- Add logger extension
- Extract extensions to own packages
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graphql-request.