fix(deps): update dependency @apollo/client to v3.12.8 #1090
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.
This PR contains the following updates:
3.12.3
->3.12.8
Release Notes
apollographql/apollo-client (@apollo/client)
v3.12.8
Compare Source
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.v3.12.7
Compare Source
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.v3.12.6
Compare Source
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
.v3.12.5
Compare Source
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
:v3.12.4
Compare Source
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.Configuration
📅 Schedule: Branch creation - "every weekday after 2:00 am before 6:00 am,every weekend" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.