[Snyk] Upgrade @apollo/client from 3.11.8 to 3.12.10 #224
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Snyk has created this PR to upgrade @apollo/client from 3.11.8 to 3.12.10.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
The recommended version is 20 versions ahead of your current version.
The recommended version was released 22 days ago.
Issues fixed by the recommended upgrade:
SNYK-JS-MICROMATCH-6838728
SNYK-JS-AXIOS-6671926
Release notes
Package name: @apollo/client
Patch Changes
#12341
f2bb0b9
Thanks @ phryneas! -useReadQuery
/useQueryRefHandlers
: Fix a "hook order" warning that might be emitted in React 19 dev mode.#12342
219b26b
Thanks @ phryneas! - Addgraphql-ws
^6.0.3
as a validpeerDependency
Patch Changes
#12321
daa4f33
Thanks @ jerelmiller! - Fix type ofextensions
inprotocolErrors
forApolloError
and theonError
link. According to the multipart HTTP subscription protocol, fatal tranport errors follow the GraphQL error format which requireextensions
to be a map as its value instead of an array.#12318
b17968b
Thanks @ jerelmiller! - AllowRetryLink
to retry an operation when fatal transport-level errors are emitted from multipart subscriptions.attempts: (count, operation, error) => {
if (error instanceof ApolloError) {
// errors available on the
protocolErrors
field inApolloError
console.log(error.protocolErrors);
}
},
});
Patch Changes
#12292
3abd944
Thanks @ phryneas! - Remove unused dependencyresponse-iterator
#12287
bf313a3
Thanks @ phryneas! - Fixes an issue whereclient.watchFragment
/useFragment
with@ includes
crashes when a separate cache update writes to the conditionally included fields.Patch Changes
#12281
d638ec3
Thanks @ jerelmiller! - Make fatal tranport-level errors from multipart subscriptions available to the error link with theprotocolErrors
property.#12281
d638ec3
Thanks @ jerelmiller! - Fix the array type for theerrors
field on theApolloPayloadResult
type. This type was always in the shape of the GraphQL error format, per the multipart subscriptions protocol and never a plain string or a JavaScript error object.Patch Changes
#12267
d57429d
Thanks @ jerelmiller! - Maintain theTData
type when used withUnmasked
whenTData
is not a masked type generated from GraphQL Codegen.#12270
3601246
Thanks @ jerelmiller! - Fix handling of tagged/branded primitive types when used as scalar values withUnmasked
.Patch Changes
#12252
cb9cd4e
Thanks @ jerelmiller! - Changes the default behavior of theMaybeMasked
type to preserve types unless otherwise specified. This change makes it easier to upgrade from older versions of the client where types could have unexpectedly changed in the application due to the default of trying to unwrap types into unmasked types. This change also fixes the compilation performance regression experienced when simply upgrading the client since types are now preserved by default.A new
mode
option has now been introduced to allow for the old behavior. See the next section on migrating if you wish to maintain the old default behavior after upgrading to this version.Migrating from <= v3.12.4
If you've adopted data masking and have opted in to using masked types by setting the
enabled
property totrue
, you can remove this configuration entirely:If you prefer to specify the behavior explicitly, change the property from
enabled: true
, tomode: "preserveTypes"
:If you rely on the default behavior in 3.12.4 or below and would like to continue to use unmasked types by default, set the
mode
tounmask
:Patch Changes
4334d30
Thanks @ charpeni! - Fix an issue withrefetchQueries
where comparingDocumentNode
s internally by references could lead to an unknown query, even though theDocumentNode
was indeed an active query—with a different reference.Patch Changes
#12214
8bfee88
Thanks @ phryneas! - Data masking: prevent infinite recursion ofContainsFragmentsRefs
type#12204
851deb0
Thanks @ jerelmiller! - FixUnmasked
unwrapping tuple types into an array of their subtypes.#12204
851deb0
Thanks @ jerelmiller! - EnsureMaybeMasked
does not try and unwrap types that contain index signatures.#12204
851deb0
Thanks @ jerelmiller! - EnsureMaybeMasked
does not try to unwrap the type asUnmasked
if the type containsany
.Patch Changes
84af347
Thanks @ jerelmiller! - Update peer deps to allow for React 19 stable release.Patch Changes
e1efe74
Thanks @ phryneas! - Fix import extension in masking entry point.Important
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information: