GithubHelp home page GithubHelp logo

Comments (21)

gusfune avatar gusfune commented on September 25, 2024 11

Can confirm same issue. Rolling back to 5.1.0 fixed temporarily.

from graphql-request.

jasonkuhrt avatar jasonkuhrt commented on September 25, 2024 7

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.

justb3a avatar justb3a commented on September 25, 2024 5

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.

kevindice avatar kevindice commented on September 25, 2024 4

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.

efstathiosntonas avatar efstathiosntonas commented on September 25, 2024 3

fixed on @graphql-codegen/[email protected]
https://github.com/dotansimha/graphql-code-generator-community/releases/tag/release-1684417928535

from graphql-request.

efstathiosntonas avatar efstathiosntonas commented on September 25, 2024 2

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.

jmoore240 avatar jmoore240 commented on September 25, 2024 2

Can also confirm this issue

from graphql-request.

efstathiosntonas avatar efstathiosntonas commented on September 25, 2024 2

@jasonkuhrt can you please pin this issue for visibility? Thanks

from graphql-request.

SimonSchneider avatar SimonSchneider commented on September 25, 2024 1

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.

Zerebokep avatar Zerebokep commented on September 25, 2024 1

@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.

madebyfabian avatar madebyfabian commented on September 25, 2024 1

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.

RobbyUitbeijerse avatar RobbyUitbeijerse commented on September 25, 2024 1

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.

madebyfabian avatar madebyfabian commented on September 25, 2024 1

@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.

batmanhit avatar batmanhit commented on September 25, 2024

This issue is happening as well.

from graphql-request.

Zerebokep avatar Zerebokep commented on September 25, 2024

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'.

Screenshot

from graphql-request.

efstathiosntonas avatar efstathiosntonas commented on September 25, 2024

@Zerebokep let me know if you wish to reopen this

from graphql-request.

Anthony-Jhoiro avatar Anthony-Jhoiro commented on September 25, 2024

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.

fungilation avatar fungilation commented on September 25, 2024

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.

madebyfabian avatar madebyfabian commented on September 25, 2024

@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.

RobSchilderr avatar RobSchilderr commented on September 25, 2024

@graphql-codegen/[email protected]

This also solved it for me!

from graphql-request.

Zerebokep avatar Zerebokep commented on September 25, 2024

@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

I realised this error was related to my custom fetcher, everything is fine now. Thank you again.

from graphql-request.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.