fix(deps): update dependency @apollo/client to v4

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@apollo/client (source)	^3.11.8 -> ^4.0.0

---

Release Notes

apollographql/apollo-client (@​apollo/client)

v4.0.7

Compare Source

Patch Changes

• #​12950 5b4f36a Thanks @​jerelmiller! - Don't send operationType in the payload sent by GraphQLWsLink.

v4.0.6

Compare Source

Patch Changes

• #​12937 3b0d89b Thanks @​phryneas! - Fix a problem with fetchMore where the loading state wouldn't reset if the result wouldn't result in a data update.

v4.0.5

Compare Source

Patch Changes

• #​12920 e2fc385 Thanks @​phryneas! - Fix an invariance type error in the MockedResponse type.

v4.0.4

Compare Source

Patch Changes

• #​12892 db8a04b Thanks @​jerelmiller! - Prevent unhandled rejections from the promise returned by calling the mutate function from the useMutation hook.

• #​12899 5352c12 Thanks @​phryneas! - Fix an issue when invariant is called by external libraries when no dev error message handler is loaded.

• #​12895 71f2517 Thanks @​jerelmiller! - Support skipToken with useQuery to provide a more type-safe way to skip query execution.

  import { skipToken, useQuery } from "@​apollo/client/react";
  
  // Use `skipToken` in place of `skip: true` for better type safety
  // for required variables
  const { data } = useQuery(QUERY, id ? { variables: { id } } : skipToken);

  Note: this change is provided as a patch within the 4.0 minor version because the changes to TypeScript validation with required variables in version 4.0 made using the skip option more difficult.

• #​12900 c0d5be7 Thanks @​phryneas! - Use named export equal instead of default from "@​wry/equality"

v4.0.3

Compare Source

Patch Changes

• #​12887 6f6ca47 Thanks @​phryneas! - Fix accidental deep re-export from /react out of /react/internals

• #​12890 019b422 Thanks @​jerelmiller! - Ensure the variables option for useMutation provides proper IntelliSense suggestions.

v4.0.2

Compare Source

Patch Changes

• #​12880 56fac52 Thanks @​phryneas! - restore getMemoryInternals access in dev builds

v4.0.1

Compare Source

Patch Changes

• #​12876 b00f231 Thanks @​phryneas! - Fix CJS build output for invariantErrorCodes

• #​12866 0d1614a Thanks @​jerelmiller! - Export isNetworkStatusInFlight from @apollo/client/utilities. Add isNetworkStatusSettled to @apollo/client/utilities and re-export it from @apollo/client with a deprecation.

v4.0.0

Compare Source

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[yolanfery]

This PR is blocked.

To upgrade to Apollo Client v4 we need to move away from generated hooks to client preset (see dotansimha/graphql-code-generator-community#1216 (comment))

I tried, but I can not manage to make the type inference to work (with useQuery/useMutation) yet in Apollo v4.
Once we achieve to make this type inference to work (without explicit typing like useMutation<DocType, InputsType>), we need to resolve the remaining tsc errors (duplicate generated types, imports,...)

[bramj]

😱

[eddeee888]

Hello 👋

I'm Eddy from the GraphQL Codegen team.

I notice the migration codemod may not have run correctly in this repo. For example, CountryPicker.tsx.ts shouldn't have been generated.

Could you please help me understand where your GraphQL operation files are? Were they in .graphql or .ts files?

[yolanfery]

Hello 👋

I'm Eddy from the GraphQL Codegen team.

Hi @eddeee888 ,

Thanks for having a look at our codebase migration, we really appreciate it 😊

I notice the migration codemod may not have run correctly in this repo. For example, CountryPicker.tsx.ts shouldn't have been generated.

Yes, we are having trouble migrating.

Could you please help me understand where your GraphQL operation files are? Were they in .graphql or .ts files?

GraphQL operations are in .graphql files

openhexa-app/frontend/src/pipelines/graphql/mutations.graphql

Line 1 in e780f95

mutation UpdatePipeline($input: UpdatePipelineInput!) {

As const in .tsx files

openhexa-app/frontend/src/datasets/features/DatasetVersionFileSample/DatasetVersionFileSample.tsx

Lines 91 to 103 in fbae842

	const GET_DATASET_VERSION_FILE_SAMPLE = gql`
	query GetDatasetVersionFileSample($id: ID!) {
	datasetVersionFile(id: $id) {
	id
	properties
	fileSample {
	sample
	status
	statusReason
	}
	}
	}
	`;

And also in fragments of those .tsx files

openhexa-app/frontend/src/core/features/SpotlightSearch/SpotlightSearch.tsx

Lines 487 to 555 in 9f339c1

	SpotlightSearch.fragments = {
	datasets: gql`
	query SearchDatasets($query: String!, $workspaceSlugs: [String]!, $page: Int, $perPage: Int) {
	datasets: searchDatasets(query: $query, workspaceSlugs: $workspaceSlugs, page: $page, perPage: $perPage) {
	__typename
	...DatasetsPage
	}
	${DatasetResultTable.fragments.datasetsPage}
	}
	`,
	pipelines: gql`
	query SearchPipelines($query: String!, $workspaceSlugs: [String]!, $page: Int, $perPage: Int, $functionalType: PipelineFunctionalType) {
	pipelines: searchPipelines(query: $query, workspaceSlugs: $workspaceSlugs, page: $page, perPage: $perPage, functionalType: $functionalType) {
	__typename
	...PipelinesPage
	}
	${PipelineResultTable.fragments.pipelinesPage}
	}
	`,
	pipelineTemplates: gql`
	query SearchPipelineTemplates($query: String!, $workspaceSlugs: [String]!, $page: Int, $perPage: Int) {
	pipelineTemplates: searchPipelineTemplates(
	query: $query
	workspaceSlugs: $workspaceSlugs
	page: $page
	perPage: $perPage
	) {
	__typename
	...PipelineTemplatesPage
	}
	${PipelineTemplateResultTable.fragments.pipelineTemplatesPage}
	}
	`,
	databaseTables: gql`
	query SearchDatabaseTables($query: String!, $workspaceSlugs: [String]!, $page: Int, $perPage: Int) {
	databaseTables: searchDatabaseTables(
	query: $query
	workspaceSlugs: $workspaceSlugs
	page: $page
	perPage: $perPage
	) {
	__typename
	...DatabaseTablesPage
	}
	${DatabaseTableResultTable.fragments.databaseTablesPage}
	}
	`,
	files: gql`
	query SearchFiles($query: String!, $workspaceSlugs: [String]!, $page: Int, $perPage: Int) {
	files: searchFiles(query: $query, workspaceSlugs: $workspaceSlugs, page: $page, perPage: $perPage) {
	__typename
	...FilesPage
	}
	${FileResultTable.fragments.filesPage}
	}
	`,
	workspaces: gql`
	query GetWorkspaces($organizationId: UUID, $page: Int, $perPage: Int) {
	workspaces(organizationId: $organizationId, page: $page, perPage: $perPage) {
	totalItems
	items {
	slug
	...WorkspaceDisplayFragment
	}
	}
	${WorkspaceDisplay.fragments.workspace}
	}
	`,
	};

Hope you can provide us guidance for moving forward !

[eddeee888]

Apologies @yolanfery , I didn't see this earlier!

I can see there are a mix of usages between .graphql and .ts files.
So I'll give suggestions for each pattern:

1. The codemod is best when used on .graphql file, so you can update your codegen config to just target these files when running codemod. For example:

// openhexa-app/frontend/codegen.yml

overwrite: true
schema: "../backend/**/schema.graphql" 
# documents: "src/**/!(*.generated).{ts,tsx,graphql}" temporarily disable this
generates:
  # ...
  # disable all other config above
  src/:
    documents: "src/**/*.graphql" # only targets `.graphql` files during codemod
    preset: '@eddeee888/gcg-operation-location-migration'
    presetConfig:
      tsConfigFilePath: 'path-to-your/tsconfig.json'
      targetStyle: 'near-operation-file'
      gqlTag: {
        name: 'gql'
        importFrom: '@apollo/client'
        importType: 'absolute'
      },
      hooksImportFrom: '@apollo/client/react', // Use @apollo/client for v3

I'd recommend using documents to target just a small subset of .graphql files to start with, to see if it's working as intended.

2. For .tsx files like DatasetVersionFileSample.tsx, there's no need to run codemod.

However, I have a question: does this have type-safety? It looks like it's just using the gql from Apollo Client directly which most of the tim is untyped

3. For fragments, no need to run migration. Unless I misunderstood how these work, if something's not working, please let me know!

[yolanfery]

Apologies @yolanfery , I didn't see this earlier!

I can see there are a mix of usages between .graphql and .ts files. So I'll give suggestions for each pattern:

1. The codemod is best when used on .graphql file, so you can update your codegen config to just target these files when running codemod. For example:

// openhexa-app/frontend/codegen.yml

overwrite: true
schema: "../backend/**/schema.graphql" 
# documents: "src/**/!(*.generated).{ts,tsx,graphql}" temporarily disable this
generates:
  # ...
  # disable all other config above
  src/:
    documents: "src/**/*.graphql" # only targets `.graphql` files during codemod
    preset: '@eddeee888/gcg-operation-location-migration'
    presetConfig:
      tsConfigFilePath: 'path-to-your/tsconfig.json'
      targetStyle: 'near-operation-file'
      gqlTag: {
        name: 'gql'
        importFrom: '@apollo/client'
        importType: 'absolute'
      },
      hooksImportFrom: '@apollo/client/react', // Use @apollo/client for v3

I'd recommend using documents to target just a small subset of .graphql files to start with, to see if it's working as intended.

Thanks for the help, we will try this way !

2. For .tsx files like DatasetVersionFileSample.tsx, there's no need to run codemod.

However, I have a question: does this have type-safety? It looks like it's just using the gql from Apollo Client directly which most of the tim is untyped

The result is untyped indeed, we will try and move away from this pattern

3. For fragments, no need to run migration. Unless I misunderstood how these work, if something's not working, please let me know!