Skip to content

fix(deps): update dependency @reduxjs/toolkit to v2.8.2 j:kit-282 #5094

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(deps): update dependency @reduxjs/toolkit to v2.8.2 j:kit-282 #5094

wants to merge 1 commit into from
+19 −5

Conversation

renovate-coveo[bot]
Copy link
Contributor

@renovate-coveo renovate-coveo bot commented Mar 25, 2025 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@reduxjs/toolkit (source) 2.6.0 -> 2.8.2 age adoption passing confidence

Release Notes

reduxjs/redux-toolkit (@​reduxjs/toolkit)

v2.8.2

Compare Source

This bugfix release fixes a bundle size regression in RTK Query from the build and packaging changes in v2.8.0.

If you're using v2.8.0 or v2.8.1, please upgrade to v2.8.2 right away to resolve that bundle size issue!

Changelog

RTK Query Bundle Size

In v2.8.0, we reworked our packaging setup to better support React Native. While there weren't many meaningful code changes, we did alter our bundling build config file. In the process, we lost the config options to externalize the @reduxjs/toolkit core when building the RTK Query nested entry points. This resulted in a regression where the RTK core code also got bundled directly into the RTK Query artifacts, resulting in a significant size increase.

This release fixes the build config and restores the previous RTKQ build artifact sizes.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.8.1...v2.8.2

v2.8.1

Compare Source

This bugfix release makes an additional update to the package config to fix a regression that happened with Jest and jest-environment-jsdom.

[!CAUTION]
This release had a bundle size regression. Please update to v2.8.2 to resolve that issue.

Changes

More Package Updates

After releasing v2.8.0, we got reports that Jest tests were breaking. After investigation we concluded that jest-environment-jsdom was looking at the new browser package exports condition we'd added to better support JSPM, finding an ESM file containing the export keyword, and erroring because it doesn't support ES modules correctly.

https://github.com/reduxjs/redux-toolkit/issues/4971#issuecomment-2859506562 listed several viable workarounds, but this is enough of an issue we wanted to fix it directly. We've tweaked the package exports setup again, and it appears to resolve the issue with Jest.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.8.0...v2.8.1

v2.8.0

Compare Source

This feature release improves React Native compatibility by updating our package exports definitions, and adds queryArg as an additional parameter to infinite query page param functions.

[!CAUTION]
This release had a bundle size regression, as well as a breakage with jest-environment-jsdom. Please update to v2.8.2 to resolve those issues.

Changelog

Package Exports and React Native Compatibility

Expo and the Metro bundler have been adding improved support for the exports field in package.json files, but those changes started printing warnings due to how some of our package definitions were configured.

We've reworked the package definitions (again!), and this should be resolved now.

Infinite Query Page Params

The signature for the getNext/PreviousPageParam functions has been:

(
    lastPage: DataType,
    allPages: Array<DataType>,
    lastPageParam: PageParam,
    allPageParams: Array<PageParam>,
  ) => PageParam | undefined | null

This came directly from React Query's API and implementation.

We've had some requests to make the endpoint's queryArg available in page param functions. For React Query, that isn't necessary because the callbacks are defined inline when you call the useInfiniteQuery hook, so you've already got the query arg available in scope and can use it. Since RTK Query defines these callbacks as part of the endpoint definition, the query arg isn't in scope.

We've added queryArg as an additional 5th parameter to these functions in case it's needed.

Other Changes

We've made a few assorted docs updates, including replacing the search implementation to now use a local index generated on build (which should be more reliable and also has a nicer results list uI), and fixing some long-standing minor docs issues.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.7.0...v2.8.0

v2.7.0

Compare Source

RTK has hit Stage 2.7! 🤣 This feature release adds support for Standard Schema validation in RTK Query endpoints, fixes several issues with infinite queries, improves perf when infinite queries provide tags, adds a dev-mode check for duplicate middleware, and improves reference stability in slice selectors and infinite query hooks.

Changelog

Standard Schema Validation for RTK Query

Apps often need to validate responses from the server, both to ensure the data is correct, and to help enforce that the data matches the expected TS types. This is typically done with schema libraries such as Zod, Valibot, and Arktype. Because of the similarities in usage APIs, those libraries and others now support a common API definition called Standard Schema, allowing you to plug your chosen validation library in anywhere Standard Schema is supported.

RTK Query now supports using Standard Schema to validate query args, responses, and errors. If schemas are provided, the validations will be run and errors thrown if the data is invalid. Additionally, providing a schema allows TS inference for that type as well, allowing you to omit generic types from the endpoint.

Schema usage is per-endpoint, and can look like this:

import { createApi, fetchBaseQuery } from '@&#8203;reduxjs/toolkit/query/react'
import * as v from 'valibot'

const postSchema = v.object({
  id: v.number(),
  name: v.string(),
})
type Post = v.InferOutput<typeof postSchema>

const api = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: '/' }),
  endpoints: (build) => ({
    getPost: build.query({
      // infer arg from here
      query: ({ id }: { id: number }) => `/post/${id}`,
      // infer result from here
      responseSchema: postSchema,
    }),
    getTransformedPost: build.query({
      // infer arg from here
      query: ({ id }: { id: number }) => `/post/${id}`,
      // infer untransformed result from here
      rawResponseSchema: postSchema,
      // infer transformed result from here
      transformResponse: (response) => ({
        ...response,
        published_at: new Date(response.published_at),
      }),
    }),
  }),
})

If desired, you can also configure schema error handling with the catchSchemaFailure option. You can also disable actual runtime validation with skipSchemaValidation (primarily useful for cases when payloads may be large and expensive to validate, but you still want to benefit from the TS type inference).

See the "Schema Validation" docs section in the createApi reference and the usage guide sections on queries, infinite queries, and mutations, for more details.

Infinite Query Fixes

This release fixes several reported issue with infinite queries:

  • The lifecycleApi.updateCachedData method is now correctly available
  • The skip option now correctly works for infinite query hooks
  • Infinite query fulfilled actions now include the meta field from the base query (such as {request, response}). For cases where multiple pages are being refetched, this will be the meta from the last page fetched.
  • useInfiniteQuerySubscription now returns stable references for refetch and the fetchNext/PreviousPage methods
upsertQueryEntries, Tags Performance and API State Structure

We recently published a fix to actually process per-endpoint providedTags when using upsertQueryEntries. However, this exposed a performance issue - the internal tag handling logic was doing repeated O(n) iterations over all endpoint+tag entries in order to clear out existing references to that cache key. In cases where hundreds or thousands of cache entries were being inserted, this became extremely expensive.

We've restructured the state.api.provided data structure to handle reverse-mapping between tags and cache keys, which drastically improves performance in this case. However, it's worth noting that this is a change to that state structure. This shouldn't affect apps, because the RTKQ state is intended to be treated as a black box and not generally directly accessed by user app code. However, it's possible someone may have depended on that specific state structure when writing a custom selector, in which case this would break. An actual example of this is the Redux DevTools RTKQ panel, which iterates the tags data while displaying cache entries. That did break with this change. Prior to releasing RTK 2.7,we released Redux DevTools 3.2.10, which includes support for both the old and new state.api.provided definitions.

TS Support Matrix Updates

Following with the DefinitelyTyped support matrix, we've officially dropped support for TS 5.0, and currently support TS 5.1 - 5.8. (RTK likely still works with 5.0, but we no longer test against that in CI.)

Duplicate Middleware Dev Checks

configureStore now checks the final middleware array for duplicate middleware references. This will catch cases such as accidentally adding the same RTKQ API middleware twice (such as adding baseApi.middleware and injectedApi.middlweware - these are actually the same object and same middleware).

Unlike the other dev-mode checks, this is part of configureStore itself, not getDefaultMiddleware().

This can be configured via the new duplicateMiddlewareCheck option.

Other Changes

createEntityAdapter now correctly handles adding an item and then applying multiple updates to it.

The generated combineSlices selectors will now return the same placeholder initial state reference for a given slice, rather than returning a new initial state reference every time.

useQuery hooks should now correctly refetch after dispatching resetApiState.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.6.1...v2.7.0

v2.6.1

Compare Source

This bugfix release fixes several assorted types issues with the initial infinite query feature release, and adds support for an optional signal argument to createAsyncThunk.

Changelog

Infinite Query Fixes

We've fixed several types issues that were reported with infinite queries after the 2.6.0 release:

  • matchFulfilled and providesTags now get the correct response types
  • We've added pre-typed Type* types to represent infinite queries, similar to the existing pre-defined types for queries and mutations
  • selectCachedArgsForQuery now supports fetching args for infinite query endpoints
  • We fixed some TS type portability issues with infinite queries that caused errors when generating TS declarations
  • useInfiniteQueryState/Subscription now correctly expect just the query arg, not the combined {queryArg, pageParam} object
Other Improvements

createAsyncThunk now accepts an optional {signal} argument. If provided, the internal AbortSignal handling will tie into that signal.

upsertQueryEntries now correctly generates provided tags for upserted cache entries.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.6.0...v2.6.1

Configuration

📅 Schedule: Branch creation - "before 4:00am on Tuesday" in timezone America/Toronto, Automerge - "after 9:00am and before 12:00pm on tuesday, wednesday, thursday" in timezone America/Toronto.

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

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

This PR has been generated by Renovate Bot.

@renovate-coveo renovate-coveo bot requested a review from a team as a code owner March 25, 2025 04:05
@renovate-coveo renovate-coveo bot added the dependencies Pull requests that update a dependency file label Mar 25, 2025
@renovate-coveo renovate-coveo bot changed the title fix(deps): update dependency @reduxjs/toolkit to v2.6.1 j:kit-282 fix(deps): update dependency @reduxjs/toolkit to v2.7.0 j:kit-282 Apr 23, 2025
alexprudhomme
alexprudhomme reviewed May 2, 2025
View reviewed changes
Copy link
Contributor

@alexprudhomme alexprudhomme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@renovate-coveo renovate-coveo bot changed the title fix(deps): update dependency @reduxjs/toolkit to v2.7.0 j:kit-282 fix(deps): update dependency @reduxjs/toolkit to v2.8.0 j:kit-282 May 13, 2025
@renovate-coveo renovate-coveo bot changed the title fix(deps): update dependency @reduxjs/toolkit to v2.8.0 j:kit-282 fix(deps): update dependency @reduxjs/toolkit to v2.8.1 j:kit-282 May 15, 2025
@renovate-coveo renovate-coveo bot changed the title fix(deps): update dependency @reduxjs/toolkit to v2.8.1 j:kit-282 fix(deps): update dependency @reduxjs/toolkit to v2.8.2 j:kit-282 May 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@alexprudhomme alexprudhomme alexprudhomme left review comments

@olamothe olamothe Awaiting requested review from olamothe olamothe is a code owner automatically assigned from coveo/search

@fpbrault fpbrault Awaiting requested review from fpbrault fpbrault is a code owner automatically assigned from coveo/search

@y-lakhdar y-lakhdar Awaiting requested review from y-lakhdar y-lakhdar is a code owner automatically assigned from coveo/search

@louis-bompart louis-bompart Awaiting requested review from louis-bompart louis-bompart is a code owner automatically assigned from coveo/search

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@alexprudhomme