chore: Bump versions for Next.js, React, and related dependencies#140
Merged
chore: Bump versions for Next.js, React, and related dependencies#140
Conversation
📝 WalkthroughWalkthroughUpdated package versions and TypeScript typings; adjusted React Query cache keys to include the translation function Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
package.json (1)
73-74: Consider consolidating duplicate@types/react*version declarations.These type packages are declared identically in both
devDependenciesandoverrides(currently synchronized). However, maintaining two edit points creates drift risk during future version bumps. Consider using a DRY approach, such as a shared variable or workspace-level override policy, to reduce maintenance burden.Applies to: lines 73-74 and 83-85.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` around lines 73 - 74, Consolidate duplicate version declarations for `@types/react` and `@types/react-dom` by removing one of the edit points and centralizing the version source; e.g., keep the versions only in devDependencies and remove them from overrides (or vice versa), or implement a single workspace-level override/variable that both devDependencies and overrides reference; update package.json entries for "@types/react" and "@types/react-dom" so only one authoritative declaration remains and ensure any lockfiles or workspace settings are updated to reflect that single source.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@package.json`:
- Around line 73-74: Consolidate duplicate version declarations for `@types/react`
and `@types/react-dom` by removing one of the edit points and centralizing the
version source; e.g., keep the versions only in devDependencies and remove them
from overrides (or vice versa), or implement a single workspace-level
override/variable that both devDependencies and overrides reference; update
package.json entries for "@types/react" and "@types/react-dom" so only one
authoritative declaration remains and ensure any lockfiles or workspace settings
are updated to reflect that single source.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 40640add-29ee-4ccd-9670-89bb2f8b6336
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (1)
package.json
…oving comparison logic
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
hooks/useAdminAuditLogs.ts (1)
193-228:⚠️ Potential issue | 🔴 CriticalQuery key mismatch breaks optimistic updates.
The query at line 193 uses
queryKeys.admin.auditLogs({ filters, sort, pagination, t }), but the optimistic update operations (lines 204, 207, 212, 227) usequeryKeys.admin.auditLogs({ filters, sort, pagination })— withoutt.Since
getQueryDataandsetQueryDatarequire exact key matches:
getQueryDatareturnsundefined(cache miss)setQueryDatacreates a separate cache entry instead of updating the active query- Users won't see optimistic UI feedback; rollback on error also fails
Recommended fix: Remove `t` from the query key
} = useQuery({ - queryKey: queryKeys.admin.auditLogs({ filters, sort, pagination, t }), + queryKey: queryKeys.admin.auditLogs({ filters, sort, pagination }), queryFn: () => fetchAuditLogsApi(filters, sort, pagination, t),Alternatively, add
tto all optimistic update operations (less preferred sincetserializes toundefinedanyway).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hooks/useAdminAuditLogs.ts` around lines 193 - 228, The optimistic update is using a different cache key than the active query because useQuery's queryKey includes t while the mutation's getQueryData/setQueryData calls do not; update hooks/useAdminAuditLogs.ts so the keys match by removing t from the queryKey passed to useQuery (the call that currently uses queryKeys.admin.auditLogs({ filters, sort, pagination, t })), ensuring all uses of queryKeys.admin.auditLogs (including in deleteByIdsMutation's mutationFn/onMutate/onError rollback which call getQueryData and setQueryData) use the identical object shape { filters, sort, pagination } so optimistic updates and rollbacks target the same cache entry.hooks/useAdminUsers.ts (1)
355-388:⚠️ Potential issue | 🔴 CriticalQuery key mismatch breaks optimistic updates (same pattern as other admin hooks).
The query uses
queryKeys.admin.users({ filters, sort, pagination, t })(line 355), but all optimistic update operations usequeryKeys.admin.users({ filters, sort, pagination })withoutt.This affects all user mutations: update, ban, unban, and delete — none will have working optimistic updates.
Recommended fix
} = useQuery({ - queryKey: queryKeys.admin.users({ filters, sort, pagination, t }), + queryKey: queryKeys.admin.users({ filters, sort, pagination }), queryFn: () => fetchUsersApi(filters, sort, pagination, t),🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hooks/useAdminUsers.ts` around lines 355 - 388, The optimistic-update queryKey calls in the admin users mutations are missing the translation param t: ensure every use of queryKeys.admin.users inside updateMutation (onMutate), and the equivalent ban, unban and delete mutation handlers (including calls to queryClient.cancelQueries, queryClient.getQueryData, queryClient.setQueryData, and any invalidateQueries) includes the same { filters, sort, pagination, t } shape used by the queryFn/queryKey (and by fetchUsersApi/updateUserApi). Update those queryKey calls so they exactly match the original queryKey signature with t so optimistic updates target the correct cache entry.hooks/useAdminCalendars.ts (1)
291-324:⚠️ Potential issue | 🔴 CriticalQuery key mismatch breaks optimistic updates (same issue as
useAdminAuditLogs).The query uses
queryKeys.admin.calendars({ filters, sort, t })(line 291), but all optimistic update operations usequeryKeys.admin.calendars({ filters, sort })withoutt(lines 307, 310, 315, 331, 352, 355, 360, 375, 421, 424, 429, 446).This causes the same cache mismatch issue where optimistic updates silently fail.
Recommended fix
} = useQuery({ - queryKey: queryKeys.admin.calendars({ filters, sort, t }), + queryKey: queryKeys.admin.calendars({ filters, sort }), queryFn: () => fetchCalendarsApi(filters, sort, t),🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hooks/useAdminCalendars.ts` around lines 291 - 324, The optimistic updates are using a different query key than the initial useQuery: useQuery uses queryKeys.admin.calendars({ filters, sort, t }) but the mutation handlers (e.g., updateMutation's onMutate and other queryClient calls like cancelQueries, getQueryData, setQueryData, invalidateQueries inside the useMutation blocks) use queryKeys.admin.calendars({ filters, sort }) without t, causing cache mismatches; fix by updating every queryClient.* call in the mutation handlers (onMutate, onError, onSettled, invalidate calls) to use the exact same key used by the query (queryKeys.admin.calendars({ filters, sort, t })) so optimistic updates read/write the same cache entry.
🧹 Nitpick comments (1)
hooks/useActivityLogs.ts (1)
135-135: Includingtin query key is unnecessary.Similar to other hooks,
t(a function) serializes toundefinedin the query key. While this doesn't break functionality here (no optimistic updates, and invalidation uses prefix matching with["activity-logs"]), it adds no value and reduces clarity.Suggested simplification
- queryKey: queryKeys.activityLogs({ filters, pagination, t }), + queryKey: queryKeys.activityLogs({ filters, pagination }),🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hooks/useActivityLogs.ts` at line 135, The query key for useActivityLogs includes the translation function t unnecessarily; remove t from the query key construction so queryKeys.activityLogs is called with only serializable params (filters, pagination) — update the call site where queryKey: queryKeys.activityLogs({ filters, pagination, t }) to omit t and ensure any other places using queryKeys.activityLogs or invalidation logic still match the simplified key.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@hooks/useAdminStats.ts`:
- Line 118: The query key currently includes the translation function `t`
(queryKeys.admin.stats({ t })), which serializes to undefined and causes
inconsistent cache keys; change the key to omit `t` (pass undefined or an empty
object) or, if you need locale-based separation, replace `t` with the actual
locale string (e.g., obtain locale via useLocale and call
queryKeys.admin.stats({ locale })) so the key matches invalidations and properly
isolates caches; update the call sites using queryKeys.admin.stats accordingly.
In `@scripts/i18n-checks.ts`:
- Around line 296-299: The script assumes German translations exist but will
throw a generic file-read error if messages/de.json is missing; add an explicit
guard after calling getAvailableLocales() and getTranslationKeys("de") to check
that "de" is present (e.g., locales.includes("de")) and that deKeys is
defined/non-empty, and if not throw a clear, actionable Error stating that
messages/de.json is missing and instructing to add all new translation keys to
messages/de.json; reference the symbols getAvailableLocales,
getTranslationKeys("de"), deKeys and otherLocales to locate where to insert the
guard so CI fails fast with a readable message.
- Around line 544-553: The loop uses otherLocales built from
getAvailableLocales() while comparisonResults comes from
compareTranslationFiles(), which can lead to missing keys if files change;
update logic in main() to derive otherLocales from
Object.keys(comparisonResults) (filtering out "de") instead of re-calling
getAvailableLocales(), so you always iterate only over locales present in
comparisonResults and avoid undefined lookup of comparisonResults[locale].
---
Outside diff comments:
In `@hooks/useAdminAuditLogs.ts`:
- Around line 193-228: The optimistic update is using a different cache key than
the active query because useQuery's queryKey includes t while the mutation's
getQueryData/setQueryData calls do not; update hooks/useAdminAuditLogs.ts so the
keys match by removing t from the queryKey passed to useQuery (the call that
currently uses queryKeys.admin.auditLogs({ filters, sort, pagination, t })),
ensuring all uses of queryKeys.admin.auditLogs (including in
deleteByIdsMutation's mutationFn/onMutate/onError rollback which call
getQueryData and setQueryData) use the identical object shape { filters, sort,
pagination } so optimistic updates and rollbacks target the same cache entry.
In `@hooks/useAdminCalendars.ts`:
- Around line 291-324: The optimistic updates are using a different query key
than the initial useQuery: useQuery uses queryKeys.admin.calendars({ filters,
sort, t }) but the mutation handlers (e.g., updateMutation's onMutate and other
queryClient calls like cancelQueries, getQueryData, setQueryData,
invalidateQueries inside the useMutation blocks) use queryKeys.admin.calendars({
filters, sort }) without t, causing cache mismatches; fix by updating every
queryClient.* call in the mutation handlers (onMutate, onError, onSettled,
invalidate calls) to use the exact same key used by the query
(queryKeys.admin.calendars({ filters, sort, t })) so optimistic updates
read/write the same cache entry.
In `@hooks/useAdminUsers.ts`:
- Around line 355-388: The optimistic-update queryKey calls in the admin users
mutations are missing the translation param t: ensure every use of
queryKeys.admin.users inside updateMutation (onMutate), and the equivalent ban,
unban and delete mutation handlers (including calls to
queryClient.cancelQueries, queryClient.getQueryData, queryClient.setQueryData,
and any invalidateQueries) includes the same { filters, sort, pagination, t }
shape used by the queryFn/queryKey (and by fetchUsersApi/updateUserApi). Update
those queryKey calls so they exactly match the original queryKey signature with
t so optimistic updates target the correct cache entry.
---
Nitpick comments:
In `@hooks/useActivityLogs.ts`:
- Line 135: The query key for useActivityLogs includes the translation function
t unnecessarily; remove t from the query key construction so
queryKeys.activityLogs is called with only serializable params (filters,
pagination) — update the call site where queryKey: queryKeys.activityLogs({
filters, pagination, t }) to omit t and ensure any other places using
queryKeys.activityLogs or invalidation logic still match the simplified key.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2ef7e63f-efc3-4bdf-8020-c163635b49b8
📒 Files selected for processing (8)
hooks/useActivityLogs.tshooks/useAdminAuditLogs.tshooks/useAdminCalendars.tshooks/useAdminStats.tshooks/useAdminUsers.tslib/auth/audit-plugin.tslib/query-keys.tsscripts/i18n-checks.ts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary by CodeRabbit
Chores
Bug Fixes / Improvements