fix(deps): update dependency @apollo/client to v4.2.0 by svc-secops · Pull Request #380 · apollographql/react-apollo-error-template

svc-secops · 2025-09-05T12:14:37Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@apollo/client (source)	`4.0.3` → `4.2.0`

Release Notes

apollographql/apollo-client (@apollo/client)

`v4.2.0`

Compare Source

Minor Changes

#13132 f3ce805 Thanks @phryneas! - Introduce "classic" and "modern" method and hook signatures.

Apollo Client 4.2 introduces two signature styles for methods and hooks. All signatures previously present are now "classic" signatures, and a new set of "modern" signatures are added alongside them.

Classic signatures are the default and are identical to the signatures before Apollo Client 4.2, preserving backward compatibility. Classic signatures still work with manually specified TypeScript generics (e.g., useSuspenseQuery<MyData>(...)). However, manually specifying generics has been discouraged for a long time—instead, we recommend using TypedDocumentNode to automatically infer types, which provides more accurate results without any manual annotations.

Modern signatures automatically incorporate your declared defaultOptions into return types, providing more accurate types. Modern signatures infer types from the document node and do not support manually passing generic type arguments; TypeScript will produce a type error if you attempt to do so.

Methods and hooks automatically switch to modern signatures the moment any non-optional property is declared in DeclareDefaultOptions. The switch happens across all methods and hooks globally:
```
// apollo.d.ts
import "@&#8203;apollo/client";
declare module "@&#8203;apollo/client" {
  namespace ApolloClient {
    namespace DeclareDefaultOptions {
      interface WatchQuery {
        errorPolicy: "all"; // non-optional → modern signatures activated automatically
      }
    }
  }
}
```
Users can also manually switch to modern signatures without declaring any defaultOptions, for example when wanting accurate type inference without relying on global defaultOptions:
```
// apollo.d.ts
import "@&#8203;apollo/client";
declare module "@&#8203;apollo/client" {
  export interface TypeOverrides {
    signatureStyle: "modern";
  }
}
```
Users can do a global DeclareDefaultOptions type augmentation and then manually switch back to "classic" for migration purposes:
```
// apollo.d.ts
import "@&#8203;apollo/client";
declare module "@&#8203;apollo/client" {
  export interface TypeOverrides {
    signatureStyle: "classic";
  }
}
```
Note that this is not recommended for long-term use. When combined with DeclareDefaultOptions, switching back to classic results in the same incorrect types as before Apollo Client 4.2—methods and hooks will not reflect the defaultOptions you've declared.
#13130 dd12231 Thanks @jerelmiller! - Improve the accuracy of client.query return type to better detect the current errorPolicy. The data property is no longer nullable when the errorPolicy is none. This makes it possible to remove the undefined checks or optional chaining in most cases.

#13210 1f9a428 Thanks @jerelmiller! - Add support for automatic event-based refetching, such as window focus.

The RefetchEventManager class handles automatic refetches in response to events. Apollo Client provides built-in sources for window focus and network reconnect as windowFocusSource and onlineSource.

Event refetching is fully opt-in. Create and pass a RefetchEventManager instance to the ApolloClient constructor to activate the event listeners.

import {
  ApolloClient,
  InMemoryCache,
  RefetchEventManager,
  windowFocusSource,
  onlineSource,
} from "@&#8203;apollo/client";

const client = new ApolloClient({
  link,
  cache: new InMemoryCache(),
  refetchEventManager: new RefetchEventManager({
    sources: {
      // Refetch when window is focused
      windowFocus: windowFocusSource,

      // Refetch when the user comes back online
      online: onlineSource,
    },
  }),
});

By default, all active queries refetch when the events fire. Queries can opt out per-event or disable all event refetches:

// Skip refetch on window focus for this query, but keep `online`
useQuery(QUERY, {
  refetchOn: { windowFocus: false },
});

// Disable all event-driven refetches for this query
useQuery(OTHER_QUERY, {
  refetchOn: false,
});

// Enable every event for this query, regardless of defaultOptions
useQuery(LIVE_DASHBOARD, {
  refetchOn: true,
});

// Dynamically enable or disable a refetch when the event fires
useQuery(LIVE_DASHBOARD, {
  refetchOn: ({ source, payload }) => {
    if (source === "windowFocus") {
      // payload is the data associated with the event
      return someCondition(payload);
    }

    return true;
  },
});

// Dynamically enable or disable a refetch for a specific event
useQuery(LIVE_DASHBOARD, {
  refetchOn: {
    windowFocus: ({ payload }) => {
      // payload is the data associated with the event
      return someCondition(payload);
    },
  },
});

To enable per-query opt-in rather than opt-out, set defaultOptions.watchQuery.refetchOn to false and enable it per-query instead.

const client = new ApolloClient({
  link,
  cache,
  refetchEventManager: new RefetchEventManager({
    sources: { windowFocus: windowFocusSource },
  }),
  defaultOptions: {
    watchQuery: { refetchOn: false },
  },
});

// Only this query refetches on window focus
useQuery(DASHBOARD_QUERY, { refetchOn: { windowFocus: true } });

When defaultOptions.watchQuery.refetchOn and per-query refetchOn options are provided, the objects are merged together.

Custom events

You can also add your own custom events that trigger refetches. Register your event name and payload type using TypeScript module augmentation, then provide a source function that returns an Observable. The source's emitted value becomes the event's payload.

import { Observable } from "@&#8203;apollo/client";
import { filter } from "rxjs";
import { AppState, AppStateStatus, Platform } from "react-native";

declare module "@&#8203;apollo/client" {
  interface RefetchEvents {
    reactNativeAppStatus: AppStateStatus;
  }
}

const refetchEventManager = new RefetchEventManager({
  sources: {
    reactNativeAppStatus: () => {
      return new Observable((observer) => {
        const subscription = AppState.addEventListener("change", (status) => {
          observer.next(status);
        });
        return () => subscription.remove();
      }).pipe(
        filter((status) => Platform.OS !== "web" && status === "active")
      );
    },
  },
});

// Disable per-query by setting the event to false
useQuery(QUERY, { refetchOn: { reactNativeAppStatus: false } });

Manually trigger an event refetch

Refetches can be triggered imperatively by calling emit with the event name and its payload (if any).

refetchEventManager.emit("reactNativeAppStatus", "active");

Sourceless events

A source that has no automatic detection logic but still wants imperative emit support can be declared as true. Type the event as void to omit the payload argument.

declare module "@&#8203;apollo/client" {
  interface RefetchEvents {
    userTriggered: void;
  }
}

const refetchEventManager = new RefetchEventManager({
  sources: { userTriggered: true },
});

refetchEventManager.emit("userTriggered");

Note: Calling emit on an event without a registered source will log a warning and result in a no-op.

Custom handlers

When an event fires, the default handler calls client.refetchQueries({ include: "active" }) filtered by each query's refetchOn setting. You can override the handler for an event to add your own custom filtering. For example, to refetch all queries, including standby queries, define a handler for the event:

const refetchEventManager = new RefetchEventManager({
  // ...
  handlers: {
    userTriggered: ({ client, source, payload, matchesRefetchOn }) => {
      return client.refetchQueries({
        include: "all",
        onQueryUpdated: (observableQuery) => {
          return matchesRefetchOn(observableQuery);
        },
      });
    },
  },
});

Handlers must return either a RefetchQueriesResult or void. Returning void skips refetching for the event.

#13232 f1b541f Thanks @jerelmiller! - Version bump to rc.
#13206 08fccab Thanks @jerelmiller! - Extend the defaultOptions type-safety work to client.mutate and useMutation.

The errorPolicy option now flows through to the result types for mutations in the same way it already does for queries:
- ApolloClient.MutateResult<TData, TErrorPolicy> maps errorPolicy to the concrete shape of data and error:
  - "none" → { data: TData; error?: never }
  - "all" → { data: TData | undefined; error?: ErrorLike }
  - "ignore" → { data: TData | undefined; error?: never }
- client.mutate and useMutation pick up the declared defaultOptions.mutate.errorPolicy and the explicit errorPolicy on each call to narrow return types accordingly.
- useMutation.Result.error is narrowed to undefined when errorPolicy is "ignore", since client.mutate never resolves with an error in that case.
DeclareDefaultOptions.Mutate already accepted errorPolicy; the new behavior is that once you declare it, hook and method return types reflect it:
```
// apollo.d.ts
import "@&#8203;apollo/client";

declare module "@&#8203;apollo/client" {
  namespace ApolloClient {
    namespace DeclareDefaultOptions {
      interface Mutate {
        errorPolicy: "all";
      }
    }
  }
}
```
```
const result = await client.mutate({ mutation: MUTATION });
result.data;
//     ^? TData | undefined
result.error;
//     ^? ErrorLike | undefined
```
Setting errorPolicy on an individual call overrides the default for that call's return type.

#13222 b93c172 Thanks @jerelmiller! - Extend the defaultOptions type-safety work to preloadQuery (returned from createQueryPreloader). Defaults declared in DeclareDefaultOptions.WatchQuery now work with preloadQuery to ensure the PreloadedQueryRef's data states are correctly set.

// apollo.d.ts
import "@&#8203;apollo/client";

declare module "@&#8203;apollo/client" {
  namespace ApolloClient {
    namespace DeclareDefaultOptions {
      interface WatchQuery {
        errorPolicy: "all";
      }
    }
  }
}

const preloadQuery = createQueryPreloader(client);
const queryRef = preloadQuery(QUERY);
//    ^? PreloadedQueryRef<TData, TVariables, "complete" | "streaming" | "empty">

#13132 f3ce805 Thanks @phryneas! - Synchronize method and hook return types with defaultOptions.

Prior to this change, the following code snippet would always apply:
```
declare const MY_QUERY: TypedDocumentNode<TData, TVariables>;
const result1 = useSuspenseQuery(MY_QUERY);
result1.data;
//      ^? TData
const result2 = useSuspenseQuery(MY_QUERY, { errorPolicy: "all" });
result2.data;
//      ^? TData | undefined
```
While these types are generally correct, if you were to set errorPolicy: 'all' as a default option, the type of result.data for the first query would remain TData instead of changing to TData | undefined to match the runtime behavior.

We are now enforcing that certain defaultOptions types need to be registered globally. This means that if you want to use errorPolicy: 'all' as a default option for a query, you will need to register its type like this:
```
// apollo.d.ts
import "@&#8203;apollo/client";

declare module "@&#8203;apollo/client" {
  namespace ApolloClient {
    namespace DeclareDefaultOptions {
      interface WatchQuery {
        // possible global-registered values:
        // * `errorPolicy`
        // * `returnPartialData`
        errorPolicy: "all";
      }
      interface Query {
        // possible global-registered values:
        // * `errorPolicy`
      }
      interface Mutate {
        // possible global-registered values:
        // * `errorPolicy`
      }
    }
  }
}
```
Once this type declaration is in place, the type of result.data in the above example will correctly be changed to TData | undefined, reflecting the possibility that if an error occurs, data might be undefined. Manually specifying useSuspenseQuery(MY_QUERY, { errorPolicy: "none" }); changes result.data to TData to reflect the local override.

This change means that you will need to declare your default options types in order to use defaultOptions with ApolloClient, otherwise you will see a TypeScript error.

Without the type declaration, the following (previously valid) code will now error:
```
new ApolloClient({
  link: ApolloLink.empty(),
  cache: new InMemoryCache(),
  defaultOptions: {
    watchQuery: {
      // results in a type error:
      // Type '"all"' is not assignable to type '"A default option for watchQuery.errorPolicy must be declared in ApolloClient.DeclareDefaultOptions before usage. See https://www.apollographql.com/docs/react/data/typescript#declaring-default-options-for-type-safety."'.
      errorPolicy: "all",
    },
  },
});
```
If you are creating multiple instances of Apollo Client with conflicting default options and you cannot register a single defaultOptions value as a result, you can relax the constraints by declaring those options as union types covering all values used by all clients. The properties can be required (to enforce them in defaultOptions) or optional (if some constructor calls won't pass a value):
```
// apollo.d.ts
import "@&#8203;apollo/client";

declare module "@&#8203;apollo/client" {
  export namespace ApolloClient {
    export namespace DeclareDefaultOptions {
      interface WatchQuery {
        errorPolicy?: "none" | "all" | "ignore";
        returnPartialData?: boolean;
      }
      interface Query {
        errorPolicy?: "none" | "all" | "ignore";
      }
      interface Mutate {
        errorPolicy?: "none" | "all" | "ignore";
      }
    }
  }
}
```
With this declaration, the ApolloClient constructor accepts any of those values in defaultOptions. The tradeoff is that hook and method return types become more generic. For example, calling useSuspenseQuery without an explicit errorPolicy will return a result typed as if all error policies are possible, since TypeScript can't know which specific value your instance uses at runtime.

Note that making a property optional (errorPolicy?:) is equivalent to adding the TypeScript default value ("none") to the union. So errorPolicy?: "all" | "ignore" has the same effect on return types as errorPolicy: "none" | "all" | "ignore", because TypeScript assumes the option could also be absent (i.e., "none").

You can also use a partial union that only lists the values you actually use. For example, if you only ever use "all" or "ignore", declare errorPolicy: "all" | "ignore" (required) to keep the union narrow and avoid unused values broadening your signatures unnecessarily.

Patch Changes

#13217 790f987 Thanks @jerelmiller! - Fix the deprecation for the classic signatures for function overloads that rely on type inference from a TypedDocumentNode. The deprecation now only applies to classic signatures that provide explicit type arguments to encourage the use of TypedDocumentNode.
#13166 0537d97 Thanks @jerelmiller! - Release changes in 4.1.5 and 4.1.6.
#13215 54c9eb7 Thanks @jerelmiller! - Ensure the options object for the useQuery, useSuspenseQuery, and useBackgroundQuery hooks provide proper IntelliSense suggestions.
#13229 9a7f65a Thanks @jerelmiller! - Fix refetchOn merging when defaultOptions.watchQuery.refetchOn is set to a non-object value (false, true, or a function) and the per-query refetchOn is an object. Previously the per-query object completely replaced the default so unspecified events fell back to "enabled" regardless of the default.

The defaultOptions value now applies to any event the per-query object does not explicitly configure:
- false - unspecified events stay disabled
- true - unspecified events refetch
- Callback function - the function is called for unspecified events to determine whether to refetch
```
const client = new ApolloClient({
  // ...
  defaultOptions: {
    watchQuery: {
      refetchOn: false,
    },
  },
});

// Only `windowFocus` refetches. Other events stay disabled per the default.
useQuery(QUERY, { refetchOn: { windowFocus: true } });
```
#13230 b25b659 Thanks @jerelmiller! - Add the ability to override the default event handler on RefetchEventManager. The default handler runs when no per-source handler is configured for an event. Provide a custom handler via the defaultHandler constructor option or the setDefaultEventHandler instance method.
```
new RefetchEventManager({
  defaultHandler: ({ client, matchesRefetchOn }) => {
    return client.refetchQueries({
      include: "all",
      onQueryUpdated: matchesRefetchOn,
    });
  },
});
```

`v4.1.9`

Compare Source

Patch Changes

#13203 099954b Thanks @copilot-swe-agent! - Remove the workspaces field from the published package.json in dist to avoid Yarn v1 warnings about workspaces requiring private packages.

`v4.1.8`

Compare Source

Patch Changes

#13202 8a51ea6 Thanks @phryneas! - Ship agent skill for usage with @tanstack/intent — the skill is now bundled in the npm package under skills/apollo-client/ and discoverable by intent list.
For more context, see the TanStack Intent QuickStart.

`v4.1.7`

Compare Source

Patch Changes

#13187 bb3fd9b Thanks @jerelmiller! - Fix RxJS interop issue with the observable returned by WebSocketLink.

`v4.1.6`

Compare Source

Patch Changes

#13128 6c0b8e4 Thanks @pavelivanov! - Fix useQuery hydration mismatch when ssr: false and skip: true are used together

When both options were combined, the server would return loading: false (because useSSRQuery checks skip first), but the client's getServerSnapshot was returning ssrDisabledResult with loading: true, causing a hydration mismatch.

`v4.1.5`

Compare Source

Patch Changes

#13155 3ba1583 Thanks @jerelmiller! - Fix an issue where useQuery would poll with pollInterval when skip was initialized to true.
#13135 fd42142 Thanks @jerelmiller! - Fix issue where client.query would apply options from defaultOptions.watchQuery.

`v4.1.4`

Compare Source

Patch Changes

#13124 578081f Thanks @Re-cool! - Ensure PersistedQueryLink merges http and fetchOptions context values instead of overwriting them.

`v4.1.3`

Compare Source

Patch Changes

#13111 bf46fe0 Thanks @RogerHYang! - Fix createFetchMultipartSubscription to support cancellation via AbortController

Previously, calling dispose() or unsubscribe() on a subscription created by createFetchMultipartSubscription had no effect - the underlying fetch request would continue running until completion. This was because no AbortController was created or passed to fetch(), and no cleanup function was returned from the Observable.

`v4.1.2`

Compare Source

Patch Changes

#13105 8b62263 Thanks @phryneas! - ssrMode, ssrForceFetchDelay or prioritizeCacheValues should not override fetchPolicy: 'cache-only', fetchPolicy: 'no-cache', fetchPolicy: 'standby', skip: true, or skipToken when reading the initial value of an ObservableQuery.
#13105 8b62263 Thanks @phryneas! - Fix skipToken in useQuery with prerenderStatic and related SSR functions.
#13105 8b62263 Thanks @phryneas! - Avoid fetches with fetchPolicy: no-cache in useQuery with prerenderStatic and related SSR functions.

`v4.1.1`

Compare Source

Patch Changes

#13103 dee7dcf Thanks @jerelmiller! - Ensure @client fields that are children of aliased server fields are resolved correctly.

`v4.1.0`

Compare Source

Minor Changes

#13043 65e66ca Thanks @jerelmiller! - Support headers transport for enhanced client awareness.
#12927 785e223 Thanks @jerelmiller! - You can now provide a callback function as the context option on the mutate function returned by useMutation. The callback function is called with the value of the context option provided to the useMutation hook. This is useful if you'd like to merge the context object provided to the useMutation hook with a value provided to the mutate function.
```
function MyComponent() {
  const [mutate, result] = useMutation(MUTATION, {
    context: { foo: true },
  });

  async function runMutation() {
    await mutate({
      // sends context as { foo: true, bar: true }
      context: (hookContext) => ({ ...hookContext, bar: true }),
    });
  }

  // ...
}
```
#12923 94ea3e3 Thanks @jerelmiller! - Fix an issue where deferred payloads that returned arrays with fewer items than the original cached array would retain items from the cached array. This change includes @stream arrays where stream arrays replace the cached arrays.
#12927 96b531f Thanks @jerelmiller! - Don't set the fallback value of a @client field to null when a read function is defined. Instead the read function will be called with an existing value of undefined to allow default arguments to be used to set the returned value.

When a read function is not defined nor is there a defined resolver for the field, warn and set the value to null only in that instance.
#12927 45ebb52 Thanks @jerelmiller! - Add support for from: null in client.watchFragment and cache.watchFragment. When from is null, the emitted result is:
```
{
  data: null,
  dataState: "complete",
  complete: true,
}
```
#12926 2b7f2c1 Thanks @jerelmiller! - Support the newer incremental delivery format for the @defer directive implemented in graphql@17.0.0-alpha.9. Import the GraphQL17Alpha9Handler to use the newer incremental delivery format with @defer.
```
import { GraphQL17Alpha9Handler } from "@&#8203;apollo/client/incremental";

const client = new ApolloClient({
  // ...
  incrementalHandler: new GraphQL17Alpha9Handler(),
});
```
[!NOTE]
In order to use the GraphQL17Alpha9Handler, the GraphQL server MUST implement the newer incremental delivery format. You may see errors or unusual behavior if you use the wrong handler. If you are using Apollo Router, continue to use the Defer20220824Handler because Apollo Router does not yet support the newer incremental delivery format.
#12927 45ebb52 Thanks @jerelmiller! - Add support for arrays with useFragment, useSuspenseFragment, and client.watchFragment. This allows the ability to use a fragment to watch multiple entities in the cache. Passing an array to from will return data as an array where each array index corresponds to the index in the from array.
```
function MyComponent() {
  const result = useFragment({
    fragment,
    from: [item1, item2, item3],
  });

  // `data` is an array with 3 items
  console.log(result); // { data: [{...}, {...}, {...}], dataState: "complete", complete: true }
}
```

#12927 45ebb52 Thanks @jerelmiller! - Add a getCurrentResult function to the observable returned by client.watchFragment and cache.watchFragment that returns the current value for the watched fragment.

const observable = client.watchFragment({
  fragment,
  from: { __typename: "Item", id: 1 },
});

console.log(observable.getCurrentResult());
// {
//   data: {...},
//   dataState: "complete",
//   complete: true,
// }

#13038 109efe7 Thanks @jerelmiller! - Add the from option to readFragment, watchFragment, and updateFragment.
#12918 2e224b9 Thanks @jerelmiller! - Add support for the @stream directive on both the Defer20220824Handler and the GraphQL17Alpha2Handler.

[!NOTE]
The implementations of @stream differ in the delivery of incremental results between the different GraphQL spec versions. If you upgrading from the older format to the newer format, expect the timing of some incremental results to change.
#13056 b224efc Thanks @jerelmiller! - InMemoryCache no longer filters out explicitly returned undefined items from read functions for array fields. This now makes it possible to create read functions on array fields that return partial data and trigger a fetch for the full list.
#13058 121a2cb Thanks @jerelmiller! - Add an extensions option to cache.write, cache.writeQuery, and client.writeQuery. This makes extensions available in cache merge functions which can be accessed with the other merge function options.

As a result of this change, any extensions returned in GraphQL operations are now available in merge in the cache writes for these operations.
#12927 96b531f Thanks @jerelmiller! - Add an abstract resolvesClientField function to ApolloCache that can be used by caches to tell LocalState if it can resolve a @client field when a local resolver is not defined.

LocalState will emit a warning and set a fallback value of null when no local resolver is defined and resolvesClientField returns false, or isn't defined. Returning true from resolvesClientField signals that a mechanism in the cache will set the field value. In this case, LocalState won't set the field value.
#13078 bf1e0dc Thanks @phryneas! - Use the default stream merge function for @stream fields only if stream info is present. This change means that using the older Defer20220824Handler will not use the default stream merge function and will instead truncate the streamed array on the first chunk.

Patch Changes

#12884 d329790 Thanks @phryneas! - Ensure that PreloadedQueryRef instances are unsubscribed when garbage collected
#13086 1a1d408 Thanks @phryneas! - Change the returned value from null to {} when all fields in a query were skipped.

This also fixes a bug where useSuspenseQuery would suspend indefinitely when all fields were skipped.
#13010 7627000 Thanks @jerelmiller! - Fix an issue where errors parsed from incremental chunks in ErrorLink might throw when using the GraphQL17Alpha9Handler.
#12927 45ebb52 Thanks @jerelmiller! - Deduplicate watches created by useFragment, client.watchFragment, and cache.watchFragment that contain the same fragment, variables, and identifier. This should improve performance in situations where a useFragment or a client.watchFragment is used to watch the same object in multiple places of an application.
#12927 259ae9b Thanks @jerelmiller! - Allow FragmentType not only to be called as FragmentType<TData>, but also as FragmentType<TypedDocumentNode>.
#12925 5851800 Thanks @jerelmiller! - Fix an issue where calling fetchMore with @defer or @stream would not rerender incremental results as they were streamed.
#12927 9e55188 Thanks @jerelmiller! - Truncate @stream arrays only on last chunk by default.
#13083 f3c2be1 Thanks @phryneas! - Expose the ExtensionsWithStreamInfo type for extensions in Cache.writeQuery, Cache.write and Cache.update so other cache implementations also can correctly access them.
#12923 94ea3e3 Thanks @jerelmiller! - Improve the cache data loss warning message when existing or incoming is an array.
#12927 4631175 Thanks @jerelmiller! - Ignore top-level data values on subsequent chunks in incremental responses.
#12927 2be8de2 Thanks @jerelmiller! - Create mechanism to add experimental features to Apollo Client
#12927 96b531f Thanks @jerelmiller! - Ensure LocalState doesn't try to read from the cache when using a no-cache fetch policy.
#12927 bb8ed7b Thanks @jerelmiller! - Ensure an error is thrown when @stream is detected and an incrementalDelivery handler is not configured.
#13053 23ca0ba Thanks @phryneas! - Use memoized observable mapping when using watchFragment, useFragment or useSuspenseFragment.
#12927 44706a2 Thanks @jerelmiller! - Add helper type QueryRef.ForQuery<TypedDocumentNode>
#13082 c257418 Thanks @phryneas! - Pass streamInfo through result extensions as a WeakRef.
#12927 4631175 Thanks @jerelmiller! - Fix the Defer20220824Handler.SubsequentResult type to match the FormattedSubsequentIncrementalExecutionResult type in graphql@17.0.0-alpha.2.
#12927 96b531f Thanks @jerelmiller! - Warn when using a no-cache fetch policy without a local resolver defined. no-cache queries do not read or write to the cache which meant no-cache queries are silently incomplete when the @client field value was handled by a cache read function.
#12927 5776ea0 Thanks @jerelmiller! - Update the accept header used with the GraphQL17Alpha9Handler to multipart/mixed;incrementalSpec=v0.2 to ensure the newest incremental delivery format is requested.
#12927 45ebb52 Thanks @jerelmiller! - DeepPartial<Array<TData>> now returns Array<DeepPartial<TData>> instead of Array<DeepPartial<TData | undefined>>.
#13071 99ffe9a Thanks @phryneas! - prerenderStatic: Expose return value of renderFunction to userland, fix aborted property.

This enables usage of resumeAndPrerender with React 19.2.
#13026 05eee67 Thanks @jerelmiller! - Reduce the number of observables created by watchFragment by reusing existing observables as much as possible. This should improve performance when watching the same item in the cache multiple times after a cache update occurs.
#13010 7627000 Thanks @jerelmiller! - Handle @stream payloads that send multiple items in the same chunk when using the Defer20220824Handler.
#13010 7627000 Thanks @jerelmiller! - Handle an edge case with the Defer20220824Handler where an error for a @stream item that bubbles to the @stream boundary (such as an item returning null for a non-null array item) would write items from future chunks to the wrong array index. In these cases, the @stream field is no longer processed and future updates to the field are ignored. This prevents runtime errors that TypeScript would otherwise not be able to catch.
#13081 1e06ad7 Thanks @jerelmiller! - Avoid calling merge functions more than once for the same incremental chunk.

`v4.0.13`

Compare Source

Patch Changes

#13094 9cbe2c2 Thanks @phryneas! - Ensure that compact and mergeOptions preserve symbol keys.

This fixes an issue where the change introduced in 4.0.11 via #13049 would not
be applied if defaultOptions for watchQuery were declared.

Please note that compact and mergeOptions are considered internal utilities
and they might have similar behavior changes in future releases.
Do not use them in your application code - a change like this is not considered
breaking and will not be announced as such.

`v4.0.12`

Compare Source

Patch Changes

#12884 d329790 Thanks @phryneas! - Ensure that PreloadedQueryRef instances are unsubscribed when garbage collected
#13069 9cad04a Thanks @jerelmiller! - Truncate @stream arrays only on last chunk by default

`v4.0.11`

Compare Source

Patch Changes

#13050 8020829 Thanks @phryneas! - Replace usage of findLast with more backwards-compatible methods.
#13049 05638de Thanks @phryneas! - Fixes an issue where queries starting with skipToken or lazy queries from useLazyQuery were included in client.refetchQueries() before they had been executed for the first time. While generally queries with a standby fetchPolicy should be included in refetch, these queries never had variables passed in, so they should be excluded until they have run once and received their actual variables.

These queries are now properly excluded from refetch operations until after their initial execution.

This change adds a new hidden option to client.watchQuery, [variablesUnknownSymbol], which may be set true for queries starting with a fetchPolicy of standby. It will only be applied when creating the ObservableQuery instance and cannot be changed later. This flag indicates that the query's variables are not yet known, and thus it should be excluded from refetch operations until they are.
This option is not meant for everyday use and is intended for framework integrations only.

Patch Changes

#12993 8f3bc9b Thanks @jerelmiller! - Fix an issue where switching from options with variables to skipToken with useSuspenseQuery and useBackgroundQuery would create a new ObservableQuery. This could cause unintended refetches where variables were absent in the request when the query was referenced with refetchQueries.

`v4.0.8`

Compare Source

Patch Changes

#12983 f6d0efa Thanks @CarsonF! - Fix cache.modify() mapping readonly arrays to singular reference

`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! -

Configuration

📅 Schedule: (in timezone Etc/UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- "after 8am and before 4pm on tuesday"

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

This PR has been generated by Renovate Bot.

svc-secops requested a review from a team as a code owner September 5, 2025 12:14

svc-secops added the dependencies Pull requests that update a dependency file label Sep 5, 2025

svc-secops force-pushed the renovate/apollo-graphql-packages branch from 3ce9842 to 38e817a Compare September 16, 2025 11:02

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.4~~ fix(deps): update dependency @apollo/client to v4.0.5 Sep 16, 2025

svc-secops force-pushed the renovate/apollo-graphql-packages branch from 38e817a to fc18f53 Compare September 30, 2025 11:37

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.5~~ fix(deps): update dependency @apollo/client to v4.0.6 Sep 30, 2025

svc-secops force-pushed the renovate/apollo-graphql-packages branch from fc18f53 to 8e42377 Compare October 4, 2025 11:12

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.6~~ fix(deps): update dependency @apollo/client to v4.0.7 Oct 4, 2025

svc-secops force-pushed the renovate/apollo-graphql-packages branch from 8e42377 to d3ba312 Compare October 31, 2025 13:05

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.7~~ fix(deps): update dependency @apollo/client to v4.0.8 Oct 31, 2025

svc-secops force-pushed the renovate/apollo-graphql-packages branch from d3ba312 to 41ccf50 Compare November 4, 2025 12:47

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.8~~ fix(deps): update dependency @apollo/client to v4.0.9 Nov 4, 2025

svc-secops force-pushed the renovate/apollo-graphql-packages branch from 41ccf50 to e40606c Compare December 18, 2025 13:28

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.9~~ fix(deps): update dependency @apollo/client to v4.0.10 Dec 18, 2025

svc-secops force-pushed the renovate/apollo-graphql-packages branch from e40606c to 604d91d Compare December 25, 2025 12:29

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.10~~ fix(deps): update dependency @apollo/client to v4.0.11 Dec 25, 2025

svc-secops force-pushed the renovate/apollo-graphql-packages branch from 604d91d to 9180954 Compare January 15, 2026 14:15

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.11~~ fix(deps): update dependency @apollo/client to v4.0.12 Jan 15, 2026

svc-secops force-pushed the renovate/apollo-graphql-packages branch from 9180954 to bbe7100 Compare January 26, 2026 18:14

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.0.12~~ fix(deps): update dependency @apollo/client to v4.1.2 Jan 26, 2026

svc-secops force-pushed the renovate/apollo-graphql-packages branch from bbe7100 to ae8b8df Compare February 4, 2026 12:16

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.1.2~~ fix(deps): update dependency @apollo/client to v4.1.3 Feb 4, 2026

svc-secops force-pushed the renovate/apollo-graphql-packages branch from ae8b8df to 64b2bd7 Compare February 9, 2026 14:25

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.1.3~~ fix(deps): update dependency @apollo/client to v4.1.4 Feb 9, 2026

svc-secops force-pushed the renovate/apollo-graphql-packages branch from 64b2bd7 to a7b7bed Compare February 25, 2026 15:13

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.1.4~~ fix(deps): update dependency @apollo/client to v4.1.5 Feb 25, 2026

svc-secops force-pushed the renovate/apollo-graphql-packages branch from a7b7bed to dbc2024 Compare March 1, 2026 17:24

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.1.5~~ fix(deps): update dependency @apollo/client to v4.1.6 Mar 1, 2026

svc-secops force-pushed the renovate/apollo-graphql-packages branch from dbc2024 to c0da95a Compare April 12, 2026 12:11

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.1.6~~ fix(deps): update dependency @apollo/client to v4.1.7 Apr 12, 2026

svc-secops force-pushed the renovate/apollo-graphql-packages branch from c0da95a to c26a432 Compare April 26, 2026 11:14

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.1.7~~ fix(deps): update dependency @apollo/client to v4.1.8 Apr 26, 2026

svc-secops force-pushed the renovate/apollo-graphql-packages branch from c26a432 to 3e47e1a Compare April 27, 2026 15:25

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.1.8~~ fix(deps): update dependency @apollo/client to v4.1.9 Apr 27, 2026

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

9c50e96

svc-secops force-pushed the renovate/apollo-graphql-packages branch from 3e47e1a to 9c50e96 Compare May 24, 2026 15:01

svc-secops changed the title ~~fix(deps): update dependency @apollo/client to v4.1.9~~ fix(deps): update dependency @apollo/client to v4.2.0 May 24, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(deps): update dependency @apollo/client to v4.2.0#380

fix(deps): update dependency @apollo/client to v4.2.0#380
svc-secops wants to merge 1 commit into
mainfrom
renovate/apollo-graphql-packages

svc-secops commented Sep 5, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

svc-secops commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Release Notes

Minor Changes

Custom events

Manually trigger an event refetch

Sourceless events

Custom handlers

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Minor Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Configuration

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

svc-secops commented Sep 5, 2025 •

edited

Loading