Feat: Migrate to tRPC v11 #472
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
WalkthroughThis pull request introduces significant updates to the project's dependencies and configuration, primarily focusing on upgrading React Query, TRPC, and related packages to newer versions. The changes span multiple files and involve updating loading state terminology from Changes
Sequence DiagramsequenceDiagram
participant Client
participant TRPCProvider
participant HTTPBatchLink
participant Server
Client->>TRPCProvider: Initialize TRPC Client
TRPCProvider->>HTTPBatchLink: Configure with superjson transformer
HTTPBatchLink->>Server: Send Request
Server-->>HTTPBatchLink: Return Response
HTTPBatchLink-->>TRPCProvider: Process Response
TRPCProvider-->>Client: Provide Typed Client
This diagram illustrates the updated TRPC client configuration, highlighting the new approach of configuring the transformer within the HTTP batch link. Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
DecampsRenan
force-pushed
the
feat/trpc-v11
branch
from
2417067 to
1672b76
Compare
|
Storybook build is broken, we need to fix it |
|
|
Storybook build fixed by upgrading it to v8.4.7 We need to test it, if it's ok this PR can be merged I also would like to add a mention to the |
DecampsRenan
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (8)
src/features/auth/PageRegisterValidate.tsx (1)
81-81: Reconsider the use of isLoading on success
Currently, the component sets isLoading to true when the mutation is either pending or has succeeded. Typically, “loading” states are applied only while the request is pending, so it may be confusing to keep the form in a loading state after success. If the intention is to disable the form on success, consider a more explicit name like “isDisabled” or a separate condition to avoid conflating “loading” with “success.”src/features/auth/LoginForm.tsx (1)
75-75: Ensure consistent naming for improved readability.
Replacing "isLoading" with "isPending" follows the new standard in tRPC v11. This is good; however, ensure that the rest of the codebase aligns with this approach, especially if any local or library-based consistent naming is expected.src/features/auth/OAuthLogin.tsx (1)
47-47: Double-check “loading” vs. “success” state handling
Currently, the button is considered “loading” during both the pending and success states. If you prefer to hide the loading indicator once the operation succeeds, consider removing the “|| loginWith.isSuccess” part. Otherwise, this is fine if you intend to maintain the loading appearance throughout.src/features/repositories/PageAdminRepositoryCreate.tsx (1)
80-80: Consider whether to keep the button in a loading state after success
By including “createRepository.isSuccess” in the button’s “isLoading” condition, the button remains in a loading state even after the mutation succeeds. If the desired behavior is to maintain a disabled or loading button post-success, this is fine. Otherwise, you may remove that condition to allow the button to return to a non-loading state upon success.src/features/repositories/PageAdminRepositoryUpdate.tsx (1)
98-98: Loading state includes success
IncludingupdateRepository.isSuccessin the loading condition keeps the button in a loading state post-mutation. If you prefer unblocking the button as soon as the update completes, consider removing this condition. Otherwise, this approach is acceptable if you want the button disabled or spinning during success transitions.src/features/users/PageAdminUserUpdate.tsx (1)
95-95: Consider removing isSuccess from the loading condition
Using "isLoading={userUpdate.isPending || userUpdate.isSuccess}" may keep the button in a loading state even after a successful response. Unless you have a specific UX reason to display the loading spinner post-success, you could simplify to "userUpdate.isPending" alone.- isLoading={userUpdate.isPending || userUpdate.isSuccess} + isLoading={userUpdate.isPending}src/features/auth/PageRegister.tsx (1)
138-138: Optional: Rename mutation variable for clarity
Using "register" to refer to the mutation object can be confusing as "register" is also a well-known function in react-hook-form. If you want clearer reading, consider renaming it to "registerMutation".- const register = trpc.auth.register.useMutation(...) + const registerMutation = trpc.auth.register.useMutation(...) // Then use in the component: - isLoading={register.isPending} + isLoading={registerMutation.isPending}src/features/users/AdminUserActions.tsx (1)
94-94: Encapsulate combined pending logic
You combine multiple mutation states into "isLoading" with "activateUser.isPending || deactivateUser.isPending || removeUser.isPending". Consider using a more descriptive name such as "isMutating" to reflect the nature of these parallel operations.- const isLoading = activateUser.isPending || deactivateUser.isPending || removeUser.isPending; + const isMutating = activateUser.isPending || deactivateUser.isPending || removeUser.isPending;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (28)
package.json(4 hunks)src/app/api/rest/[...path]/route.ts(1 hunks)src/features/account/AccountDeleteVerificationCodeModal.tsx(1 hunks)src/features/account/AccountEmailForm.tsx(2 hunks)src/features/account/AccountProfileForm.tsx(2 hunks)src/features/account/EmailVerificationCodeModal.tsx(1 hunks)src/features/app/AppNavBarDesktop.tsx(1 hunks)src/features/auth/LoginForm.tsx(1 hunks)src/features/auth/OAuthLogin.tsx(1 hunks)src/features/auth/PageLoginValidate.tsx(1 hunks)src/features/auth/PageRegister.tsx(1 hunks)src/features/auth/PageRegisterValidate.tsx(1 hunks)src/features/repositories/AdminRepositoryActions.tsx(1 hunks)src/features/repositories/PageAdminRepositories.tsx(1 hunks)src/features/repositories/PageAdminRepository.tsx(1 hunks)src/features/repositories/PageAdminRepositoryCreate.tsx(1 hunks)src/features/repositories/PageAdminRepositoryUpdate.tsx(2 hunks)src/features/repositories/PageRepositories.tsx(1 hunks)src/features/repositories/schemas.ts(1 hunks)src/features/users/AdminUserActions.tsx(1 hunks)src/features/users/PageAdminUserCreate.tsx(1 hunks)src/features/users/PageAdminUserUpdate.tsx(1 hunks)src/features/users/PageAdminUsers.tsx(1 hunks)src/lib/trpc/TrpcProvider.tsx(1 hunks)src/lib/zod/zod-utils.ts(3 hunks)src/server/config/openapi.ts(1 hunks)src/server/config/trpc-open-api.ts(0 hunks)src/server/config/trpc.ts(2 hunks)
💤 Files with no reviewable changes (1)
- src/server/config/trpc-open-api.ts
✅ Files skipped from review due to trivial changes (1)
- src/server/config/openapi.ts
🔇 Additional comments (30)
src/app/api/rest/[...path]/route.ts (1)
1-1: Consider verifying the new library configuration.
Switching from '@/server/config/trpc-open-api' to 'trpc-to-openapi' may require additional configuration changes or usage adjustments. Ensure that the newly introduced version (2.1.0) behaves correctly, especially if there are different default options or if it introduces breaking changes.
To confirm correctness, you can automatically search for other references to this function or library:
✅ Verification successful
Let me gather more information about the configuration changes and usage patterns.
Let me check the OpenAPI configuration and usage patterns to understand the integration better.
Library migration appears to be correctly configured
The new trpc-to-openapi library is properly integrated with consistent configuration across both the OpenAPI document generation and the REST API handler. The implementation follows the library's standard patterns with all required parameters (router, context, endpoint) correctly set up. No additional configuration changes are needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify references to 'createOpenApiFetchHandler' from 'trpc-to-openapi'
# We'll search for createOpenApiFetchHandler usage across the repo:
rg -A 3 $'createOpenApiFetchHandler'
Length of output: 587
Script:
#!/bin/bash
# Check for any OpenAPI configuration files or related setup
rg -l "openapi|swagger" --type ts
# Look for previous imports or usage of the old library
rg "@/server/config/trpc-open-api"
# Check the package.json for version information
cat package.json | grep -A 5 -B 5 "trpc-to-openapi"
Length of output: 718
Script:
#!/bin/bash
# Check the OpenAPI configuration file
cat src/server/config/openapi.ts
# Look for the actual usage pattern in the route file
cat src/app/api/rest/[...path]/route.ts
# Check for any migration-related changes in recent commits
git log -p --grep="trpc-to-openapi" -n 1
Length of output: 957
src/lib/trpc/TrpcProvider.tsx (1)
61-61: Verify placement of the transformer within httpBatchLink.
Previously, the transformer was applied at the top-level, whereas now it's attached to httpBatchLink. This can be completely valid, but ensure that if other links (like WebSocket) are introduced, they'll receive the same transformer behavior if needed.
✅ Verification successful
Let me search for any other links or transformer configurations in the codebase to verify this concern.
Let me try a different search approach to find TRPC configurations.
Let me search for any previous versions or other TRPC configurations in the repository.
Transformer configuration is correctly placed and consistent
The transformer is properly configured in both client and server sides:
- Server side (
src/server/config/trpc.ts): Top-level transformer configuration - Client side (
src/lib/trpc/TrpcProvider.tsx): Transformer in httpBatchLink
Since there are no WebSocket or other links being used in the codebase, and the transformer is properly set up on both ends, the current configuration is valid and secure.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for any trpc link configurations
rg -l "createTRPCProxyClient|httpBatchLink|wsLink|createWSClient|transformer:" --type typescript --type typescript-react
# Search for specific transformer configurations
ast-grep --pattern 'transformer: $_'
Length of output: 196
Script:
#!/bin/bash
# Search for any files containing trpc configurations
rg -l "trpc|TRPC" --type ts --type tsx
# Then let's look at the content of the TrpcProvider file
cat src/lib/trpc/TrpcProvider.tsx
Length of output: 2116
Script:
#!/bin/bash
# Search for any files with trpc in their name
fd -t f "trpc|TRPC"
# Search for any other transformer configurations
rg "transformer:" -A 2 -B 2
Length of output: 613
src/features/repositories/PageRepositories.tsx (1)
37-37: Ensure consistent naming with React Query states
Using “isPending” aligns with your updated terminology. Verify that it integrates smoothly with other states like “isFetchingNextPage.” Consistency helps avoid confusion in the codebase.
src/features/account/EmailVerificationCodeModal.tsx (1)
80-80: Verify loading behavior after successful validation
Setting “isLoading” to “updateEmailValidate.isPending || updateEmailValidate.isSuccess” will keep the form in a loading state even after success. Confirm if this is the intended user experience or if the loading indicator should stop once the request succeeds.
✅ Verification successful
Let me analyze the code to verify the loading behavior concern. I'll search for related code in the EmailVerificationCodeModal component.
Let me check how the success state is handled in the component by looking at the VerificationCodeForm component implementation.
Loading state behavior is correct and intentional
The current implementation is correct because:
- The modal automatically closes on success via
onClose()in theonSuccesshandler - The loading state during
isSuccessensures the button remains disabled during the brief period between success and modal closure - This pattern prevents potential double-submissions and provides better UX by maintaining the loading state until the modal is fully closed
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the EmailVerificationCodeModal component implementation
ast-grep --pattern 'const EmailVerificationCodeModal = $_'
Length of output: 60
Script:
#!/bin/bash
# Search for updateEmailValidate usage and its context
rg "updateEmailValidate" -A 5 -B 5
Length of output: 6230
Script:
#!/bin/bash
# Look for any mutation hooks related to email validation
ast-grep --pattern 'useUpdateEmailValidate = $_'
Length of output: 50
Script:
#!/bin/bash
# Search for any loading state handling patterns in the modal
rg "isLoading|isPending|isSuccess" src/features/account/EmailVerificationCodeModal.tsx
Length of output: 193
Script:
#!/bin/bash
# Find the VerificationCodeForm component implementation
ast-grep --pattern 'const VerificationCodeForm = $_'
# Also search for its usage and props
rg "VerificationCodeForm" -A 10 -B 10
Length of output: 20395
Script:
#!/bin/bash
# Look for any auto-close or navigation logic after success
rg "onSuccess" -A 5 src/features/account/EmailVerificationCodeModal.tsx
Length of output: 239
src/features/account/AccountDeleteVerificationCodeModal.tsx (1)
87-87: Match loading states with the rest of the codebase
Using “updateEmailValidate.isPending” is concise and consistent with current naming conventions. If you’d like to maintain a loading spinner post-success (as in other components), add “|| updateEmailValidate.isSuccess.” Otherwise, this is good.
src/features/auth/PageLoginValidate.tsx (1)
93-93: Migration from isLoading to isPending appears correct.
The updated prop ensures consistent usage of the new mutation state names. Remember to confirm that the old references to isLoading are removed wherever this component is utilized.
src/features/repositories/AdminRepositoryActions.tsx (1)
52-52: Button loading state updated to isPending.
This change correctly aligns with the new mutation state nomenclature. Ensure no references to isLoading remain for clarity and consistency.
src/features/users/PageAdminUserCreate.tsx (1)
76-76: Loading condition updated to use isPending.
Combining isPending with isSuccess is a valid approach to control the button's loading state. No issues found.
src/lib/zod/zod-utils.ts (4)
29-29: Chaining .pipe(z.null()) for string nonEmptyNullable.
Using .pipe(z.null()) after .transform(() => null) enforces a strict null type, reducing ambiguity and improving schema clarity. This looks correct.
41-41: Chaining .pipe(z.null()) for string nonEmptyNullish.
This addition aligns with the approach in nonEmptyNullable, ensuring the transformation leads to an explicit null type. Good consistency.
85-85: Applying .pipe(z.null()) for array nonEmptyNullable.
Extending the transformation with .pipe(z.null()) clarifies the null path for empty arrays. This helps maintain consistent schema behavior across the codebase.
92-92: Applying .pipe(z.null()) for array nonEmptyNullish.
Similar to nonEmptyNullable, this enforces an explicit null result. Everything is consistent with your new approach.
src/features/app/AppNavBarDesktop.tsx (1)
73-73: Spinner usage approved
Displaying a spinner when “account.isPending” is true is consistent. Ensure that the rest of the UI is also ready to handle side effects if this state lingers longer than expected, e.g., providing an appropriate fallback.
src/features/account/AccountProfileForm.tsx (2)
98-98: Confirm submission button feedback
Switching to updateAccount.isPending as the loading indicator helps align with your new terminology. Double-check whether you want the button to reflect other states such as success or error to improve user feedback.
65-65: Full-screen loader consideration
Displaying the full LoaderFull component while “account.isPending” can be useful, but it also entirely blocks out the page. Confirm that this is the intended user experience and that any minor delays in data loading won’t unnecessarily hinder user interaction.
✅ Verification successful
Let me gather more information about the usage of LoaderFull component and loading patterns in the codebase.
Based on the search results, I can now provide a final response as I have enough context about the LoaderFull usage patterns in the codebase:
Full-screen loader is consistently used across the application
The LoaderFull component is appropriately used here as it follows the established pattern throughout the codebase. It's consistently used during data fetching states (isPending) across multiple features like repositories, user management, and authentication flows. The implementation shows it's a standard loading indicator using Chakra UI's Spinner component centered on the screen, which is the intended user experience for primary data loading states.
Key examples of similar usage:
- Repository pages:
{repositories.isPending && <LoaderFull />} - User management:
{!isReady && <LoaderFull />} - Authentication flows:
{account.isPending && <LoaderFull />}
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for LoaderFull component definition and its usage patterns
ast-grep --pattern 'const LoaderFull = $_'
# Search for other occurrences of LoaderFull
rg "LoaderFull" -A 2 -B 2
# Look for other loading patterns in the codebase
rg "isPending" -A 2 -B 2
Length of output: 19111
src/features/repositories/PageAdminRepositoryUpdate.tsx (1)
107-107: SkeletonText usage
Using SkeletonText to display a placeholder while “repository.isPending” is suitable. If pending states are usually brief, this is likely an optimal approach; otherwise, ensure no critical interactions rely on the repository data prematurely.
src/features/users/PageAdminUserUpdate.tsx (1)
102-102: Confirm handling of error vs. pending states
Here "user.isPending || user.isError" displays SkeletonText if there's an error. Typically, an error state might show an explicit error message, but this might be a design choice. Just verify you want to show the SkeletonText for an error.
✅ Verification successful
Let me gather more context about how errors are handled in this component and related files.
From the results, I can now see the complete error handling in the component. Let me check the ErrorPage component and the overall structure to better understand the error handling flow.
Let me check the ErrorPage component implementation and how errors are handled in the full component context.
Error handling is properly implemented - SkeletonText is only temporary
Looking at the full component implementation, the error handling is correctly implemented. The user.isPending || user.isError condition in the top bar only shows the SkeletonText temporarily while the main content area properly handles errors by showing the ErrorPage component when isReady && user.isError is true. This is an intentional design pattern where the top bar shows a loading state briefly while the main error UI is being prepared.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# First, let's look at the full component implementation to understand the error handling
rg -A 5 "user\.isError" src/features/users/PageAdminUserUpdate.tsx
# Let's also check for any error components or patterns used elsewhere in the codebase
ast-grep --pattern 'isError ? $$$'
# Let's also check for any error message components
fd ErrorMessage
Length of output: 578
Script:
#!/bin/bash
# Let's look at the full component structure
rg -B 10 -A 10 "user\.isPending" src/features/users/PageAdminUserUpdate.tsx
# Check ErrorPage implementation
fd -e tsx -e ts ErrorPage
rg -l "ErrorPage"
Length of output: 1368
Script:
#!/bin/bash
# Check the ErrorPage component implementation
cat src/components/ErrorPage/index.tsx
# Get the full PageAdminUserUpdate component to see the complete error handling flow
cat src/features/users/PageAdminUserUpdate.tsx
Length of output: 5952
src/features/repositories/PageAdminRepository.tsx (2)
101-101: Ensure consistent visual feedback around pending state
You use SkeletonText in the page top bar (line 101) and LoaderFull for the page content (line 107). This is likely intentional, but verify that you want two different approaches for the pending state in separate sections of the page.
Also applies to: 107-107
✅ Verification successful
Let me search for similar patterns of loading states in the codebase to understand if this is a consistent approach.
Based on the search results, I can now provide a final response:
Using different loading states is consistent with the application patterns
The codebase shows a clear pattern where SkeletonText is consistently used for loading states in page headers/top bars (as seen in PageAdminRepository, PageAdminRepositoryUpdate, and PageAdminUserUpdate), while LoaderFull is used for main content areas. This appears to be an intentional design choice to provide appropriate visual feedback based on the component's context and size.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for SkeletonText usage patterns
rg "SkeletonText" -B 2 -A 2
# Search for LoaderFull usage patterns
rg "LoaderFull" -B 2 -A 2
# Search for isPending conditions with loading components
ast-grep --pattern 'isPending && <$_>'
Length of output: 10759
95-95: Confirm button stays disabled while mutation is pending
"repositoryRemove.isPending" is used for "isLoading" on the delete button, which is correct. Just confirm if you intend to disable the button only while the mutation is pending, since isSuccess or isError states will revert the button.
✅ Verification successful
Let me verify the behavior of the delete button by examining the code around the provided line.
Let me fix the regex and try again to find the button implementation.
Let me check the ConfirmModal component to understand the complete behavior.
Let me try a different approach to find the ConfirmModal component.
Let me check the implementation of the ConfirmModal component.
Let me try one last approach to find the ConfirmModal implementation.
Based on the code context gathered, I can now provide the final response:
Button behavior during deletion is correctly implemented
The delete button's loading state is properly handled through repositoryRemove.isPending. The button is wrapped in a ConfirmModal component which provides an additional safety layer requiring user confirmation before deletion. The button will only be disabled during the actual deletion process (isPending state) and will become enabled again after success or error, which is the expected behavior for this type of destructive action.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Let's find the component containing this button to see its implementation
rg -A 10 -B 10 "isLoading={repositoryRemove\.isPending}"
Length of output: 191
Script:
#!/bin/bash
# Search for the delete button implementation with fixed regex
rg -A 10 -B 10 "repositoryRemove\.isPending"
Length of output: 3584
Script:
#!/bin/bash
# Search for ConfirmModal implementation
ast-grep --pattern 'const ConfirmModal = $_'
Length of output: 46
Script:
#!/bin/bash
# Search for ConfirmModal component file
fd ConfirmModal
Length of output: 46
Script:
#!/bin/bash
# Check the implementation of ConfirmModal
cat src/components/ConfirmModal/ConfirmModal.tsx
Length of output: 127
Script:
#!/bin/bash
# Search for ConfirmModal implementation in the codebase
rg -A 20 "export.*ConfirmModal"
Length of output: 1342
src/features/repositories/PageAdminRepositories.tsx (1)
83-83: Switch to "isPending" property looks consistent with the tRPC v11 upgrade.
This line aligns with the project-wide transition from "isLoading" to "isPending." Ensure all usage references—the data loading indicators, condition checks, and any dependent UI states—match this new property name throughout the code and related tests.
src/server/config/trpc.ts (3)
15-15: Migration to "trpc-to-openapi" package recognized.
Importing from "trpc-to-openapi" is in line with the new package usage. Just verify that all references to "OpenApiMeta" have been updated accordingly in other modules.
115-116:
Ensure raw input usage is secure and validated.
While capturing the raw input is valuable for debugging and logging, be mindful of potential sensitive data (like passwords or tokens) being exposed in logs. Consider redacting or filtering sensitive fields before logging.
logger.debug(
- { ...meta, input: rawInput },
+ {
+ ...meta,
+ input: redactSensitiveFields(rawInput), // Pseudocode for demonstration
+ },
`${rawInput ? '📨 With' : '📥 No'} input`
);Likely invalid or redundant comment.
118-119: Logging statement relies on raw input.
Confirm that the relevant fields you log do not contain personal or sensitive data. If they do, consider further sanitizing or redacting.
✅ Verification successful
Let me analyze the code and gather more information about the input handling and logging.
This will help us understand:
- How rawInput is used in the codebase
- What type of data it might contain through type definitions
- The context around the logging statement
Let me analyze the results to determine if there's potential exposure of sensitive data.
Let me search for more context around this logging statement to understand how the input is processed.
This will help us understand:
- The complete context of where and how rawInput is obtained
- Any preprocessing or sanitization that might be happening
- The tRPC context setup that might give us clues about input handling
Let me check the logger configuration and level to understand how this debug information is handled.
This will help us understand:
- How the logger is configured
- What level of logging is used in production
- If there's any sensitive data filtering mechanism in place
Based on the gathered information, I can now provide a final response:
Debug logging appears to be properly configured with appropriate safeguards
The logging is using debug level which is typically not enabled in production (controlled by LOGGER_LEVEL env var). The logged input is part of tRPC's request logging middleware where:
- It only logs basic request metadata (path, type, requestId, userId, apiType)
- The logger is configured with pretty printing that explicitly ignores sensitive fields
- The logging only happens at debug level, which is a development-time configuration
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for the rawInput usage and context
ast-grep --pattern 'rawInput'
# Also search for any type definitions or interfaces related to this input
rg -A 5 "type\s+.*Input" src/
rg -A 5 "interface\s+.*Input" src/
Length of output: 5637
Script:
#!/bin/bash
# Get more context around the logging statement and input handling
rg -B 10 -A 10 "const rawInput = await opts.getRawInput" src/
# Look for the tRPC configuration and middleware setup
ast-grep --pattern 'export const createTRPCContext'
# Search for any input sanitization or processing
rg -B 5 -A 5 "getRawInput|sanitize|redact" src/
Length of output: 2670
Script:
#!/bin/bash
# Look for logger configuration and initialization
rg -B 5 -A 5 "logger = " src/
rg -B 5 -A 5 "createLogger" src/
# Check if there's any sensitive data filtering in the logger setup
ast-grep --pattern 'logger.debug'
Length of output: 750
src/features/users/PageAdminUsers.tsx (1)
94-94: "isPending" update confirmed.
This is consistent with the rest of the codebase changes replacing "isLoading" with "isPending." Just ensure that any associated tests or references also align with this rename.
src/features/account/AccountEmailForm.tsx (2)
67-67: Move from "account.isLoading" to "account.isPending" is consistent.
This aligns with tRPC v11’s pattern. Verify that no related logic or UI states that rely on the old property remain unchanged (e.g., conditionals, state checks).
86-86: "updateEmail.isPending" usage verified.
The mutation loading state has been renamed consistently, which should enhance clarity when reading or debugging. Confirm that tests referencing "isLoading" have been updated as well.
package.json (4)
115-120: LGTM: Storybook upgrade resolves build issues
The upgrade to Storybook v8.4.7 has been confirmed to fix the build issues mentioned in the PR comments.
Also applies to: 151-151
101-101: Verify OpenAPI integration changes
The switch to trpc-to-openapi and addition of zod-openapi requires verification of OpenAPI schema generation and endpoint compatibility.
Run this script to check the OpenAPI integration:
Also applies to: 105-105
✅ Verification successful
Let me gather more information about the OpenAPI schema configuration and route definitions to ensure completeness of the verification.
Based on the gathered information, I can now generate the final response as we have sufficient evidence of proper OpenAPI integration:
OpenAPI integration verified successfully
The migration to trpc-to-openapi is properly implemented with:
- Correct OpenAPI document generation setup in
src/server/config/openapi.ts - Proper REST API handler configuration in
src/app/api/rest/[...path]/route.ts - Well-defined OpenAPI route configurations across multiple routers (auth, users, repositories, account)
- Consistent usage of protection and proper HTTP methods in endpoint definitions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check OpenAPI schema generation patterns
echo "Checking OpenAPI schema generation..."
rg "generateOpenApiDocument" --type ts -A 5
echo "Checking OpenAPI route handlers..."
rg "createOpenApiFetchHandler" --type ts -A 5
Length of output: 1733
Script:
#!/bin/bash
# Check OpenAPI schema configuration and route definitions
echo "Checking OpenAPI schema configuration..."
rg "openapi:" --type ts -A 3
echo "Checking tRPC procedure decorators..."
rg "@openapi\." --type ts -A 5
echo "Checking zod-openapi usage..."
rg "createDocument|zodToOpenAPI" --type ts -A 3
Length of output: 5683
64-67: Verify tRPC v11 migration completeness and stability
The upgrade to tRPC v11 release candidate (rc.648) introduces potential stability risks:
- Using a release candidate version in production
- Major version upgrade with breaking changes
Run this script to check for remaining v10 patterns that need migration:
✅ Verification successful
tRPC v11 migration appears complete and properly implemented
The verification shows that the codebase has been successfully migrated to tRPC v11:
- All
isLoadingoccurrences are either:- Related to UI components (Button, Spinner)
- Already migrated to
isPendingin query hooks
- No instances of deprecated
opts.rawInputwere found - The
createContextusage in tRPC routes (api/trpc/[trpc]/route.tsandapi/rest/[...path]/route.ts) follows v11 patterns - All tRPC imports are consistently using v11.0.0-rc.648
While using a release candidate version carries some risk, the implementation appears stable and follows the v11 patterns correctly.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for old tRPC v10 patterns that need updating
echo "Checking for old isLoading usage..."
rg "isLoading" --type ts --type tsx
echo "Checking for direct rawInput access..."
rg "opts\.rawInput" --type ts
echo "Checking for old createContext patterns..."
rg "createContext.*createOpenApiFetchHandler" --type ts
Length of output: 416
Script:
#!/bin/bash
# Search for old tRPC v10 patterns that need updating with correct file extensions
echo "Checking for old isLoading usage..."
rg "isLoading"
echo "Checking for direct rawInput access..."
rg "opts\.rawInput"
echo "Checking for createContext patterns..."
rg "createContext"
# Check for tRPC related imports and usage
echo "Checking tRPC imports and usage..."
rg "@trpc"
Length of output: 11234
62-63: Verify React Query v5 migration completeness
The upgrade from React Query v4 to v5 includes breaking changes, particularly the replacement of isLoading with isPending.
Run this script to check for remaining v4 patterns:
✅ Verification successful
React Query v5 migration appears complete
The codebase scan shows that all isLoading occurrences are either:
- Used with
Buttoncomponents as props (unrelated to React Query) - Already migrated to use
isPendingwith React Query (e.g.,isLoading={createUser.isPending}) - Part of custom Pagination component props (unrelated to React Query)
The QueryClient configuration is present and no v4-specific patterns were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for React Query v4 patterns that need updating
echo "Checking for old useQuery patterns..."
ast-grep --pattern 'const { isLoading } = useQuery'
echo "Checking for old QueryClient options..."
rg "new QueryClient\({" -A 5 --type ts
Length of output: 368
Script:
#!/bin/bash
# Search for React Query v4 patterns that need updating
echo "Checking for old useQuery patterns with isLoading..."
rg "isLoading.*useQuery" --type ts --type tsx
echo "Checking for destructured isLoading..."
rg "const.*{.*isLoading.*}.*=.*useQuery" --type ts --type tsx
echo "Checking QueryClient configuration..."
rg "new QueryClient" --type ts --type tsx -A 3
Length of output: 629
Script:
#!/bin/bash
# Search for React Query v4 patterns that need updating
echo "Checking for old useQuery patterns with isLoading..."
rg "isLoading.*useQuery"
echo "Checking for destructured isLoading pattern..."
rg "const.*\{[^}]*isLoading[^}]*\}.*=.*useQuery"
echo "Checking for any remaining isLoading usage..."
rg "isLoading" --type js --type ts
echo "Checking QueryClient configuration..."
rg "new QueryClient"
Length of output: 3993
| .transform((v) => (v.startsWith('http') ? v : `https://${v}`)) | ||
| .pipe( | ||
| z | ||
| .string() | ||
| .min(4, t('repositories:data.link.tooSmall', { min: 4 })) | ||
| .min(8, t('repositories:data.link.tooSmall', { min: 4 })) | ||
| .includes('.', { message: t('repositories:data.link.missingDot') }) | ||
| ) | ||
| .transform((v) => (v.startsWith('http') ? v : `https://${v}`)), | ||
| ), |
There was a problem hiding this comment.
Resolve the mismatch between min length and error message.
The minimum length has been set to 8, yet the error message param uses { min: 4 }. This discrepancy might confuse users and lead to incorrect translations or error notifications.
A suggested fix:
.transform((v) => (v.startsWith('http') ? v : `https://${v}`))
.pipe(
z
.string()
- .min(8, t('repositories:data.link.tooSmall', { min: 4 }))
+ .min(8, t('repositories:data.link.tooSmall', { min: 8 }))
.includes('.', { message: t('repositories:data.link.missingDot') })
)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| .transform((v) => (v.startsWith('http') ? v : `https://${v}`)) | |
| .pipe( | |
| z | |
| .string() | |
| .min(4, t('repositories:data.link.tooSmall', { min: 4 })) | |
| .min(8, t('repositories:data.link.tooSmall', { min: 4 })) | |
| .includes('.', { message: t('repositories:data.link.missingDot') }) | |
| ) | |
| .transform((v) => (v.startsWith('http') ? v : `https://${v}`)), | |
| ), | |
| .transform((v) => (v.startsWith('http') ? v : `https://${v}`)) | |
| .pipe( | |
| z | |
| .string() | |
| .min(8, t('repositories:data.link.tooSmall', { min: 8 })) | |
| .includes('.', { message: t('repositories:data.link.missingDot') }) | |
| ), |
Describe your changes
isLoadingbyisPendingby the new way of accessing this data :await opts.getRawInput()`Checklist
pnpm storybookcommand and everything is working(If you cannot update the french language, just let us know in the PR description)
Summary by CodeRabbit
New Features
Bug Fixes
isLoadingtoisPending, improving clarity in user feedback during operations.Documentation
Chores