feat: Upgrade to Apollo Client v4 #717
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 70423c6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 18 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📝 WalkthroughWalkthroughUpgrades Apollo Client to v4 (imports, types, ErrorLink, new error types), adds first-class Vitest support and generators across projects, removes vitest global .env setup in favor of loadEnv, updates generated imports to Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant App as Client (React app)
participant Apollo as ApolloClient
participant ErrorLink as ErrorLink
participant Logger as logError/logger
participant Sentry as Sentry
participant Session as userSessionClient
App->>Apollo: execute operation (query / mutation)
Apollo->>ErrorLink: propagate error (CombinedGraphQLErrors / ServerError)
ErrorLink->>Logger: log GraphQL errors (iterate error.errors) and include operation context
ErrorLink->>Sentry: report first GraphQLError (annotate scope)
alt ServerError with status 401 and body.code == "invalid-session"
ErrorLink->>Session: userSessionClient.signOut()
end
Note over ErrorLink,Logger: For ServerError set context.networkErrorResponse = error.bodyText
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Disabled knowledge base sources:
⛔ Files ignored due to path filters (7)
📒 Files selected for processing (7)
🚧 Files skipped from review as they are similar to previous changes (1)
🧰 Additional context used📓 Path-based instructions (6)**/*.{ts,tsx}📄 CodeRabbit inference engine (.cursor/rules/code-style.mdc)
Files:
**/*.{ts,tsx,js}📄 CodeRabbit inference engine (.cursor/rules/code-style.mdc)
Files:
examples/todo-with-auth0/**/*.{ts,tsx,js,jsx}📄 CodeRabbit inference engine (examples/todo-with-auth0/CLAUDE.md)
Files:
examples/todo-with-auth0/**/*.{ts,tsx}📄 CodeRabbit inference engine (examples/todo-with-auth0/CLAUDE.md)
Files:
examples/blog-with-auth/**/*.{ts,tsx,js,jsx}📄 CodeRabbit inference engine (examples/blog-with-auth/CLAUDE.md)
Files:
examples/blog-with-auth/**/*.{ts,tsx}📄 CodeRabbit inference engine (examples/blog-with-auth/CLAUDE.md)
Files:
🧠 Learnings (22)📓 Common learnings📚 Learning: 2025-11-25T22:46:20.505ZApplied to files:
📚 Learning: 2025-11-24T19:44:46.506ZApplied to files:
📚 Learning: 2025-11-24T19:44:33.994ZApplied to files:
📚 Learning: 2025-11-24T19:45:01.582ZApplied to files:
📚 Learning: 2025-04-23T06:44:30.952ZApplied to files:
📚 Learning: 2025-11-24T19:44:46.506ZApplied to files:
📚 Learning: 2025-11-24T19:44:46.506ZApplied to files:
📚 Learning: 2025-11-24T19:44:46.506ZApplied to files:
📚 Learning: 2025-11-24T19:45:19.136ZApplied to files:
📚 Learning: 2025-11-24T19:45:19.136ZApplied to files:
📚 Learning: 2025-04-23T06:44:30.952ZApplied to files:
📚 Learning: 2025-04-23T06:44:30.952ZApplied to files:
📚 Learning: 2025-11-24T19:45:19.136ZApplied to files:
📚 Learning: 2025-11-24T19:45:19.136ZApplied to files:
📚 Learning: 2025-11-24T19:45:19.136ZApplied to files:
📚 Learning: 2025-11-24T19:45:19.136ZApplied to files:
📚 Learning: 2025-06-30T11:52:28.745ZApplied to files:
📚 Learning: 2025-11-24T19:44:33.994ZApplied to files:
📚 Learning: 2025-11-24T19:44:33.994ZApplied to files:
📚 Learning: 2025-11-24T19:44:33.994ZApplied to files:
📚 Learning: 2025-11-24T19:44:33.994ZApplied to files:
🧬 Code graph analysis (4)plugins/plugin-auth/src/auth0/generators/react/auth0-apollo/auth0-apollo.generator.ts (1)
examples/todo-with-auth0/apps/web/src/services/apollo/index.ts (1)
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.ts (3)
packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.ts (2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
🔇 Additional comments (6)
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 |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (20)
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.ts (1)
5-23: Add JSDocs to the exported function.Per the coding guidelines for
examples/todo-with-auth0/**/*.{ts,tsx}, all exported functions should have JSDocs documenting the function, its parameters, return value, and all fields.As per coding guidelines, examples/todo-with-auth0 files require JSDocs on all exported functions.
🔎 Add JSDocs
+/** + * Global setup for Prisma database during test runs. + * Creates a separate test database and runs migrations. + * + * @param project - The Vitest test project configuration + * @returns A promise that resolves when setup is complete + */ export default async function setup(project: TestProject): Promise<void> {plugins/plugin-auth/src/local-auth/core/generators/auth-hooks/templates/src/hooks/use-log-out.ts (1)
1-1: Remove or justify the@ts-nocheckdirective.The coding guidelines require strict TypeScript checking, but this file disables all type checking with
@ts-nocheck. If this directive is necessary due to the template placeholders (e.g.,%generatedGraphqlImports), consider using more targeted@ts-expect-errorcomments or structuring the template to allow type checking.plugins/plugin-auth/src/local-auth/core/generators/auth-routes/templates/routes/auth_/register.tsx (1)
1-1: Remove@ts-nocheckand fix underlying type errors.Disabling TypeScript checking for the entire file violates the coding guideline "Use TypeScript with strict type checking enabled" and hides potential type safety issues that could be introduced by the Apollo Client v4 upgrade.
As per coding guidelines, strict type checking should be enabled. If there are specific type errors, they should be resolved properly rather than suppressed.
plugins/plugin-auth/src/local-auth/core/generators/auth-routes/templates/routes/auth_/login.tsx (1)
1-1: Remove@ts-nocheckdirective from generated template.The
@ts-nocheckdirective disables all TypeScript checking for this file, which directly contradicts the coding guideline: "Use TypeScript with strict type checking enabled." Generated code should be type-safe and not require disabling type checking.If specific type errors exist, they should be resolved individually rather than suppressing all checking. This ensures generated projects maintain type safety.
As per coding guidelines, TypeScript strict type checking must be enabled for all TypeScript files.
examples/todo-with-auth0/apps/admin/src/routes/admin/accounts/users/user/$id.tsx (1)
42-89: Add JSDoc documentation to exported function.The exported function
UserEditPageis missing JSDoc documentation. Per coding guidelines forexamples/todo-with-auth0/**/*.{ts,tsx}, all exported functions should have JSDocs with documentation of the function, its parameters, return value, and all fields.As per coding guidelines, examples/todo-with-auth0/**/*.{ts,tsx} requires JSDocs for all exported functions.
🔎 Proposed JSDoc addition
+/** + * User edit page component that allows editing a user by ID. + * Loads user data, displays an edit form, and handles form submission. + * + * @returns React element containing the user edit interface + */ function UserEditPage(): ReactElement {examples/blog-with-auth/apps/admin/src/hooks/use-log-out.ts (2)
5-8: Add.jsextensions to local imports.According to the coding guidelines for this project, all import statements should include
.jsextensions, even for TypeScript files. This is required for ESM module resolution with TypeScript'sNodeNextsetting.🔎 Proposed fix
-import { LogOutDocument } from '../generated/graphql'; -import { logAndFormatError } from '../services/error-formatter'; -import { logError } from '../services/error-logger'; -import { userSessionClient } from '../services/user-session-client'; +import { LogOutDocument } from '../generated/graphql.js'; +import { logAndFormatError } from '../services/error-formatter.js'; +import { logError } from '../services/error-logger.js'; +import { userSessionClient } from '../services/user-session-client.js';As per coding guidelines.
10-10: Add JSDoc to exported function.The exported
useLogOutfunction is missing JSDoc documentation. According to the coding guidelines, all exported functions should have documentation describing the function, its parameters, return value, and all fields.🔎 Proposed fix
+/** + * Hook that provides a log out callback function. + * Logs the user out via GraphQL mutation, clears the user session, displays a success toast, + * and navigates to the home page. + * @returns A callback function that triggers the log out flow. + */ export function useLogOut(): () => void {As per coding guidelines.
examples/todo-with-auth0/apps/admin/src/hooks/use-current-user.ts (1)
14-28: Add JSDoc documentation for exported function.Per coding guidelines, all exported functions require JSDoc comments documenting the function, parameters, and return value.
🔎 Suggested JSDoc addition
+/** + * Hook to fetch the current authenticated user's data. + * + * @returns An object containing the current user data, loading state, and any errors. + * - `user`: The current user fragment, or undefined if not loaded/authenticated + * - `loading`: Boolean indicating if the query is in progress + * - `error`: Error object if the query failed or if no user is logged in + */ export function useCurrentUser(): UseCurrentUserResult { const { userId } = useSession(); const { data, loading, error } = useQuery(GetUserByIdDocument, { variables: { id: userId ?? '' }, skip: !userId, }); const noUserError = !userId ? new Error('No user logged in') : null; return { user: data?./* TPL_USER:START */ user /* TPL_USER:END */, loading, error: error ?? noUserError, }; }As per coding guidelines, JSDoc comments are required for all exported functions in
examples/todo-with-auth0/**/*.{ts,tsx}files.examples/blog-with-auth/apps/admin/src/routes/admin/accounts/users/-components/user-table.tsx (1)
1-200: Fix Prettier formatting issues.The pipeline indicates Prettier check failed for this file. Run
pnpm run prettier --write .to fix the formatting issues.examples/blog-with-auth/apps/admin/src/routes/admin/accounts/users/-components/password-reset-dialog.tsx (1)
1-155: Fix Prettier formatting issues.The pipeline indicates Prettier check failed. Run
pnpm run prettier --write .to fix the formatting issues.examples/blog-with-auth/apps/admin/src/routes/admin/accounts/users/$id.tsx (1)
1-89: Fix Prettier formatting issues.The pipeline indicates Prettier check failed. Run
pnpm run prettier --write .to fix the formatting issues.examples/todo-with-auth0/apps/admin/src/app/router.tsx (1)
1-120: Fix Prettier formatting issues.The pipeline indicates Prettier check failed. Run
pnpm run prettier --write .to fix the formatting issues.examples/todo-with-auth0/apps/web/src/utils/apollo-error.ts (1)
3-17: Add JSDoc documentation to the exported function.The
getApolloErrorCodefunction is exported but lacks JSDoc documentation describing its purpose, parameters, and return value.🔎 Proposed documentation
+/** + * Extract error code from Apollo GraphQL errors. + * @param error The error object to extract code from. + * @param allowedCodes List of allowed error codes to filter for. + * @returns The first matching error code, or null if no match found. + */ export function getApolloErrorCode<T extends readonly string[]>( error: unknown, allowedCodes: T, ): T[number] | null {Based on coding guidelines.
examples/todo-with-auth0/apps/admin/src/services/apollo/index.ts (1)
29-33: Add JSDoc documentation to the exported function.The
createApolloClientfunction is exported but lacks JSDoc documentation.🔎 Proposed documentation
+/** + * Create and configure an Apollo Client instance. + * @param options Configuration options including access token provider. + * @returns Configured Apollo Client instance. + */ export function createApolloClient( /* TPL_CREATE_ARGS:START */ { getAccessToken, }: CreateApolloClientOptions /* TPL_CREATE_ARGS:END */, ): ApolloClient {Based on coding guidelines.
examples/blog-with-auth/apps/admin/src/utils/apollo-error.ts (1)
1-16: Add JSDoc and create dedicated unit tests forgetApolloErrorCode.The migration from
ApolloErrortoCombinedGraphQLErrorsand the property change fromgraphQLErrorstoerrorscorrectly aligns with Apollo Client v4. However, the exported function lacks JSDoc documentation (required by coding guidelines for all exported functions, including parameter, return value documentation). Additionally, whileapollo.unit.test.tstests broader error handling, it does not include dedicated tests forgetApolloErrorCodeitself—only indirect usage through error scenarios. Add JSDoc and create explicit tests covering the function with various allowed codes and error scenarios.examples/blog-with-auth/apps/admin/src/services/sentry.ts (1)
1-84: Run Prettier to fix formatting.The pipeline indicates a Prettier check failure. Please run the following command to fix formatting issues:
pnpm run prettier --write .examples/blog-with-auth/apps/admin/baseplate/file-id-map.json (1)
1-130: Run Prettier to fix formatting.The pipeline indicates a Prettier check failure. Please run:
pnpm run prettier --write .examples/blog-with-auth/apps/admin/package.json (1)
1-103: Run Prettier to fix formatting.The pipeline indicates a Prettier check failure. Please run:
pnpm run prettier --write .examples/blog-with-auth/apps/admin/src/routes/__root.tsx (1)
1-17: Run Prettier to fix formatting.The pipeline indicates a Prettier check failure. Please run:
pnpm run prettier --write .examples/blog-with-auth/apps/admin/eslint.config.js (1)
1-329: Run Prettier to fix formatting.The pipeline indicates a Prettier check failure. Please run:
pnpm run prettier --write .
🧹 Nitpick comments (15)
.changeset/spicy-hornets-fry.md (1)
1-8: Consider a more comprehensive description to reflect all major changes.The changeset currently documents only vitest support, but the PR summary indicates this release includes a significant Apollo Client v4 upgrade with breaking changes, error handling restructuring, and expanded test coverage. Given that all four packages are being bumped, the description should reflect the broader scope of changes.
Consider updating the description to something like:
Add support for generating vitest on web apps, upgrade to Apollo Client v4 with new error handling patterns, and expand test coverage across generators.This ensures consumers of these packages understand the scope of changes, especially the breaking Apollo Client v4 migration.
packages/core-generators/src/generators/node/vitest/vitest.generator.ts (1)
15-25: Import statements should precede all declarations.The
descriptorSchemaconst declaration on line 15 splits the import block. As per coding guidelines, imports should be sorted by group (external libs first, then local imports) and placed together at the top of the file.🔎 Proposed fix to reorder imports
import { createConfigProviderTask, createGenerator, createGeneratorTask, } from '@baseplate-dev/sync'; +import { quot } from '@baseplate-dev/utils'; import { z } from 'zod'; import { CORE_PACKAGES } from '#src/constants/index.js'; import { packageScope } from '#src/providers/scopes.js'; +import { + tsCodeFragment, + TsCodeUtils, + tsImportBuilder, +} from '#src/renderers/index.js'; import { extractPackageVersions } from '#src/utils/extract-packages.js'; import { eslintConfigProvider } from '../eslint/index.js'; import { createNodePackagesTask, createNodeTask } from '../node/index.js'; +import { NODE_VITEST_GENERATED } from './generated/index.js'; const descriptorSchema = z.object({}); - -import { quot } from '@baseplate-dev/utils'; - -import { - tsCodeFragment, - TsCodeUtils, - tsImportBuilder, -} from '#src/renderers/index.js'; - -import { NODE_VITEST_GENERATED } from './generated/index.js';examples/todo-with-auth0/apps/web/eslint.config.js (1)
309-323: Consider including benchmark files in Vitest configuration.The Vitest configuration is well-structured with recommended rules and proper settings. However, benchmark files (
**/*.bench.{js,ts,jsx,tsx}) are listed inFILES_WITH_DEV_DEPENDENCIES(line 19) but aren't included in the Vitest ESLint rules. Since benchmark files typically use Vitest's bench API, they should follow the same linting rules as test files.🔎 Suggested enhancement
// Vitest Configs { - files: ['**/*.test.{ts,js,tsx,jsx}', 'tests/**'], + files: ['**/*.{test,bench}.{ts,js,tsx,jsx}', 'tests/**'], plugins: { vitest }, rules: { ...vitest.configs.recommended.rules, // Helpful in dev but should flag as errors when linting 'vitest/no-focused-tests': 'error', }, settings: { vitest: { typecheck: true, }, }, },packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.ts (1)
1-1: Evaluate if@ts-nocheckis still necessary.With proper type annotations now in place (
TestProjectparameter andPromise<void>return type), consider removing the@ts-nocheckdirective. Disabling TypeScript checking can hide legitimate type errors and reduces type safety.If it's still needed for template generation flexibility, please add a comment explaining why.
🔎 Proposed fix
-// @ts-nocheck - import type { TestProject } from 'vitest/node';examples/todo-with-auth0/apps/admin/src/routes/admin/todos/todo-list/$id.tsx (1)
28-34: Consider checking for GraphQL errors in the loader.The data guard is good for type safety, but the loader could benefit from also checking for GraphQL errors. Currently, only
datais destructured from the query result.🔎 Optional enhancement to handle GraphQL errors
loader: async ({ context: { apolloClient }, params }) => { const { id } = params; - const { data } = await apolloClient.query({ + const { data, error } = await apolloClient.query({ query: TodoListEditByIdDocument, variables: { id }, }); - if (!data) throw new Error('No data received from query'); + if (!data || error) { + throw error || new Error('Failed to load todo list'); + } return { crumb: data.todoList.name ? data.todoList.name : 'Unnamed Todo List', }; },packages/react-generators/src/generators/admin/admin-crud-edit/templates/edit.tsx (1)
18-18: Good defensive guard, consider more specific error message.The data validation guard is good defensive programming that fails fast in the loader. However, the error message could be more descriptive to aid debugging in generated code.
💡 Optional: More descriptive error message
- if (!data) throw new Error('No data received from query'); + if (!data) throw new Error(`No data received from query: ${TPL_USER_QUERY.loc?.source.body ?? 'unknown query'}`);Alternatively, if the template system supports it, use a template placeholder for the query name to make the error message more specific in generated code.
plugins/plugin-auth/src/local-auth/core/generators/auth-routes/templates/routes/auth_/login.tsx (1)
52-52: Consider usingReact.ReactElementfor consistency with guidelines.The function uses
React.JSX.Elementas the return type, which is valid and modern. However, the coding guidelines specify usingReact.ReactElementfor React component return types. Consider aligning with the guideline for consistency across the codebase.🔎 Proposed change
-function LoginPage(): React.JSX.Element { +function LoginPage(): React.ReactElement {As per coding guidelines: "Always include return types on top-level functions including React components (
React.ReactElement)"examples/todo-with-auth0/apps/admin/src/routes/admin/accounts/users/user/$id.tsx (1)
33-33: Enhance error message with contextual information.The runtime guard is a good defensive practice. Consider making the error message more descriptive by including the query name and ID parameter for easier debugging.
🔎 Proposed enhancement
- if (!data) throw new Error('No data received from query'); + if (!data) throw new Error(`No data received from UserEditByIdDocument query for user ID: ${id}`);examples/blog-with-auth/apps/admin/src/routes/admin/accounts/users/$id.tsx (1)
33-33: Consider a more specific error message.The runtime guard is good defensive programming, but the error message could be more specific to aid debugging.
🔎 Suggested improvement
- if (!data) throw new Error('No data received from query'); + if (!data) throw new Error('No data received from UserEditByIdDocument query');examples/blog-with-auth/apps/admin/src/routes/admin/accounts/users/new.tsx (1)
10-10: Useimport typefor type-only imports.Per coding guidelines for this project, type-only imports should use the
import typesyntax.🔎 Proposed fix
-import type { ReactElement } from 'react'; - -import { useMutation } from '@apollo/client/react'; -import { createFileRoute, useNavigate } from '@tanstack/react-router'; -import { toast } from 'sonner'; - -import { CreateUserDocument, GetUsersDocument } from '@src/generated/graphql'; -import { logError } from '@src/services/error-logger'; - -import type { UserFormData } from './-schemas/user-schema'; +import type { ReactElement } from 'react'; + +import { useMutation } from '@apollo/client/react'; +import { createFileRoute, useNavigate } from '@tanstack/react-router'; +import { toast } from 'sonner'; + +import { CreateUserDocument, GetUsersDocument } from '@src/generated/graphql'; +import { logError } from '@src/services/error-logger'; + +import type { UserFormData } from './-schemas/user-schema';Based on learnings, this applies to examples/blog-with-auth/**/*.{ts,tsx}.
examples/todo-with-auth0/apps/web/src/app/app-apollo-provider.tsx (1)
9-11: Add JSDocs and consider exporting the Props interface.Per coding guidelines for this project, exported functions should have JSDocs documentation. Additionally, the Props interface could be exported for better reusability.
🔎 Proposed additions
-interface Props { +/** + * Props for the AppApolloProvider component. + */ +export interface AppApolloProviderProps { children: React.ReactNode; } -export function AppApolloProvider({ children }: Props): ReactElement { +/** + * Provides Apollo Client context to the application. + * Creates an Apollo Client instance with Auth0 authentication. + * + * @param props - Component props + * @returns The provider component wrapping children with Apollo context + */ +export function AppApolloProvider({ children }: AppApolloProviderProps): ReactElement {Based on learnings, this applies to examples/todo-with-auth0/**/*.{ts,tsx}.
examples/blog-with-auth/apps/admin/src/tests/helpers/logger.test-helper.ts (1)
1-105: Consider extracting shared test helper to a common package.The identical
logger.test-helper.tsimplementation appears in three locations:
examples/todo-with-auth0/apps/admin/src/tests/helpers/logger.test-helper.tsexamples/todo-with-auth0/apps/web/src/tests/helpers/logger.test-helper.tsexamples/blog-with-auth/apps/admin/src/tests/helpers/logger.test-helper.tsIf these example apps share test infrastructure, consider extracting this helper to a shared testing utilities package to reduce duplication and ensure consistency.
examples/blog-with-auth/apps/admin/src/routes/__root.tsx (1)
7-13: Consider adding JSDocs to exported interface.Per coding guidelines for
examples/blog-with-auth/**/*.{ts,tsx}, exported interfaces should have JSDocs documenting all fields.🔎 Suggested documentation
+/** + * Context provided to all routes in the application. + */ export interface RootRouteContext { /* TPL_ROOT_ROUTE_CONTEXT:START */ + /** Apollo Client instance for GraphQL operations */ apolloClient: ApolloClient; + /** Current session data */ session: SessionData; + /** Current user ID if authenticated */ userId?: string | undefined; /* TPL_ROOT_ROUTE_CONTEXT:END */ }examples/todo-with-auth0/apps/admin/src/routes/__root.tsx (1)
8-15: Consider adding JSDocs to exported interface.Per coding guidelines for
examples/todo-with-auth0/**/*.{ts,tsx}, all exported interfaces should have JSDocs documenting the interface, its purpose, and all fields.🔎 Suggested documentation
+/** + * Context provided to all routes in the application. + */ export interface RootRouteContext { /* TPL_ROOT_ROUTE_CONTEXT:START */ + /** Apollo Client instance for GraphQL operations */ apolloClient: ApolloClient; + /** Auth0 authentication context */ auth0: Auth0ContextInterface; + /** Current session data */ session: SessionData; + /** Current user ID if authenticated */ userId?: string | undefined; /* TPL_ROOT_ROUTE_CONTEXT:END */ }examples/blog-with-auth/apps/admin/src/services/apollo/index.ts (1)
60-73: Session error handling implementation is correct.The
sessionErrorLinkproperly handles session invalidation by:
- Checking for 401 status code
- Parsing JSON body to verify the
invalid-sessioncode- Gracefully handling non-JSON response bodies
Minor nit: The explicit
return;on line 72 is unnecessary sinceErrorLinkcallbacks don't require a return value.🔎 Optional cleanup
} catch { // Body is not JSON, ignore } } - return; });
| --- | ||
| '@baseplate-dev/react-generators': patch | ||
| '@baseplate-dev/plugin-auth': patch | ||
| '@baseplate-dev/plugin-storage': patch | ||
| --- | ||
|
|
||
| Upgrade Apollo Client to v4 | ||
|
|
||
| - @apollo/client: 3.13.8 → 4.0.11 | ||
| - Add rxjs 7.8.2 as peer dependency (required by Apollo Client v4) | ||
|
|
||
| Breaking changes in generated code: | ||
|
|
||
| - React hooks (useQuery, useMutation, useApolloClient, etc.) now import from `@apollo/client/react` instead of `@apollo/client` | ||
| - ApolloProvider now imports from `@apollo/client/react` | ||
| - Error handling uses new `CombinedGraphQLErrors` and `ServerError` classes from `@apollo/client/errors` | ||
| - `ErrorLink` class replaces deprecated `onError` function | ||
| - `ApolloClient` is no longer generic (use `ApolloClient` instead of `ApolloClient<NormalizedCacheObject>`) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find and check rxjs in peerDependencies of affected packages
# First, find the packages directory and list its structure
find . -type d -name "packages" | head -1
# Check if the affected package directories exist
for pkg in react-generators plugin-auth plugin-storage; do
if [ -f "packages/$pkg/package.json" ]; then
echo "=== packages/$pkg/package.json ==="
jq '{name: .name, peerDependencies: .peerDependencies, dependencies: .dependencies}' "packages/$pkg/package.json" 2>/dev/null || echo "Failed to parse"
fi
done
# Alternative: use fd to find package.json files
echo "=== Searching for packages with fd ==="
fd package.json --type f | grep -E 'packages/(react-generators|plugin-auth|plugin-storage)' | head -5Repository: halfdomelabs/baseplate
Length of output: 562
🏁 Script executed:
#!/bin/bash
# Check all three affected packages for rxjs peer dependency
for pkg in react-generators plugin-auth plugin-storage; do
pkgfile="packages/$pkg/package.json"
if [ -f "$pkgfile" ]; then
echo "=== $pkgfile ==="
cat "$pkgfile" | jq '{"name": .name, "peerDependencies": .peerDependencies, "rxjs_in_deps": .dependencies.rxjs, "rxjs_in_peer": .peerDependencies.rxjs}'
else
echo "=== $pkgfile === NOT FOUND"
fi
doneRepository: halfdomelabs/baseplate
Length of output: 343
🏁 Script executed:
#!/bin/bash
# Search for the missing packages
echo "=== Searching for plugin-auth ==="
find . -name "plugin-auth" -type d 2>/dev/null
echo "=== Searching for plugin-storage ==="
find . -name "plugin-storage" -type d 2>/dev/null
echo "=== List all packages in packages/ directory ==="
ls -la packages/ 2>/dev/null | head -20
echo "=== Find all package.json files in packages/ ==="
find packages -name "package.json" -type f 2>/dev/null | sortRepository: halfdomelabs/baseplate
Length of output: 1929
🏁 Script executed:
#!/bin/bash
# Check all three affected packages for rxjs peer dependency
for pkg in "plugins/plugin-auth" "plugins/plugin-storage" "packages/react-generators"; do
pkgfile="$pkg/package.json"
if [ -f "$pkgfile" ]; then
echo "=== $pkgfile ==="
jq '{"name": .name, "peerDependencies": .peerDependencies, "rxjs_in_peer": (.peerDependencies.rxjs // "NOT FOUND")}' "$pkgfile"
else
echo "=== $pkgfile === NOT FOUND"
fi
doneRepository: halfdomelabs/baseplate
Length of output: 709
The changeset claims rxjs peer dependency was added, but it is not present in any of the affected packages.
The changeset documents adding rxjs 7.8.2 as a peer dependency to @baseplate-dev/react-generators, @baseplate-dev/plugin-auth, and @baseplate-dev/plugin-storage. However, verification shows:
@baseplate-dev/react-generatorshas no peerDependencies defined at all@baseplate-dev/plugin-authhas peerDependencies but rxjs is not listed@baseplate-dev/plugin-storagehas peerDependencies but rxjs is not listed
Add rxjs 7.8.2 to the peerDependencies of all three packages, or remove this line from the changeset if it is not required.
🤖 Prompt for AI Agents
.changeset/upgrade-apollo-client-v4.md lines 1-18: the changeset claims adding
rxjs 7.8.2 as a peer dependency to @baseplate-dev/react-generators,
@baseplate-dev/plugin-auth, and @baseplate-dev/plugin-storage but those packages
do not actually list rxjs; either add "rxjs": "7.8.2" to the peerDependencies of
each of the three package.json files (react-generators, plugin-auth,
plugin-storage) and update their package.json for package publishing, or remove
the rxjs entry from this changeset if the peer dependency is not required — make
the changeset and package.json peerDependencies consistent and commit the
updated files.
| import { logError } from '../error-logger'; | ||
| import { logger } from '../logger'; | ||
| import { userSessionClient } from '../user-session-client'; | ||
| import { createApolloClient } from './index'; |
There was a problem hiding this comment.
Missing .js extensions in import statements.
Per coding guidelines, imports should include file extensions. As per coding guidelines for examples/blog-with-auth/**/*.{ts,tsx,js,jsx}: "Always use .js extensions in import statements, even for TypeScript files."
🔎 Proposed fix
-import { logError } from '../error-logger';
-import { logger } from '../logger';
-import { userSessionClient } from '../user-session-client';
-import { createApolloClient } from './index';
+import { logError } from '../error-logger.js';
+import { logger } from '../logger.js';
+import { userSessionClient } from '../user-session-client.js';
+import { createApolloClient } from './index.js';📝 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.
| import { logError } from '../error-logger'; | |
| import { logger } from '../logger'; | |
| import { userSessionClient } from '../user-session-client'; | |
| import { createApolloClient } from './index'; | |
| import { logError } from '../error-logger.js'; | |
| import { logger } from '../logger.js'; | |
| import { userSessionClient } from '../user-session-client.js'; | |
| import { createApolloClient } from './index.js'; |
🤖 Prompt for AI Agents
In examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
around lines 15 to 18, the import statements omit the required .js file
extensions; update each import to include the .js extension (e.g.,
'../error-logger.js', '../logger.js', '../user-session-client.js', './index.js')
so that all module specifiers follow the repo guideline to always use .js
extensions even in TypeScript files.
| import { ApolloClient, ApolloLink, HttpLink } from '@apollo/client'; | ||
| import { CombinedGraphQLErrors, ServerError } from '@apollo/client/errors'; | ||
| import { ErrorLink } from '@apollo/client/link/error'; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n examples/blog-with-auth/apps/admin/src/services/apollo/index.ts | head -30Repository: halfdomelabs/baseplate
Length of output: 1541
🌐 Web query:
Apollo Client v4 import paths CombinedGraphQLErrors ServerError ErrorLink
💡 Result:
Use the errors API and the link error module from @apollo/client. Example imports for Apollo Client v4:
-
CombinedGraphQLErrors, ServerError (and other error classes):
import { CombinedGraphQLErrors, ServerError } from "@apollo/client/errors"; [1] -
ErrorLink / onError:
import { ErrorLink } from "@apollo/client/link/error";
// or the onError helper:
import { onError } from "@apollo/client/link/error"; [2]
(Docs showing these imports and usage: CombinedGraphQLErrors [1], ErrorLink/onError [2], ServerError [3].)
Sources:
[1] Apollo Client — CombinedGraphQLErrors docs.
[2] Apollo Client — ErrorLink / link error docs.
[3] Apollo Client — ServerError docs.
🌐 Web query:
Apollo Client v4 ApolloClient return type generic parameter NormalizedCacheObject
💡 Result:
Short answer: In Apollo Client v4 you no longer need — and typically won't use — ApolloClient. The client types were reorganized: most generics were removed or renamed (cache APIs still use NormalizedCacheObject for extract/restore, but ApolloClient's public API now uses non‑generic/namespace types). Use the plain ApolloClient (or the new namespaced types) and the InMemoryCache / ApolloCache types where needed.
References:
- ApolloClient API (v4 docs) — shows Options.cache is ApolloCache (no T generic). [1]
- Migration notes describing TypeScript renames/removed generics (including cache/context changes). [2]
- Explanation that NormalizedCacheObject describes the cache extraction shape (used by cache.extract/restore). [3]
Sources:
[1] ApolloClient API (Apollo docs).
[2] Migrating to Apollo Client 4.0 (Apollo docs).
[3] Apollo docs / TypeScript discussions (NormalizedCacheObject meaning).
Add .js extensions to all local import statements.
Lines 7-12 use relative imports without .js extensions, violating the coding guideline that requires .js extensions in all import statements for this file path. Update:
'../config'→'../config.js''../error-logger'→'../error-logger.js''../logger'→'../logger.js''../user-session-client'→'../user-session-client.js''./apollo-sentry-link'→'./apollo-sentry-link.js''./cache'→'./cache.js'
The Apollo Client v4 imports (lines 1-3) are correct and properly reflect the v4 API; the return type ApolloClient on line 23 is also correct for v4.
🧰 Tools
🪛 GitHub Actions: Lint Examples
[error] 1-1: Prettier check failed for blog-with-auth-admin. Command failed with exit code 1. Run 'pnpm run prettier:check' to reproduce or 'pnpm run prettier --write .' to fix formatting issues.
🤖 Prompt for AI Agents
In examples/blog-with-auth/apps/admin/src/services/apollo/index.ts around lines
1 to 3, several relative imports later in the file (lines ~7-12) are missing
required .js extensions; update each local import to include the .js extension
(e.g., '../config' → '../config.js', '../error-logger' → '../error-logger.js',
'../logger' → '../logger.js', '../user-session-client' →
'../user-session-client.js', './apollo-sentry-link' → './apollo-sentry-link.js',
'./cache' → './cache.js') so they comply with the project file-extension import
guideline while leaving the external Apollo Client v4 imports unchanged.
| @@ -0,0 +1,105 @@ | |||
| import type { MockedFunction } from 'vitest'; | |||
There was a problem hiding this comment.
Fix prettier formatting to resolve pipeline failure.
The pipeline indicates a prettier check failure for blog-with-auth-admin. Run the formatter to fix:
pnpm run prettier --write examples/blog-with-auth/apps/admin/src/tests/helpers/logger.test-helper.ts🧰 Tools
🪛 GitHub Actions: Lint Examples
[error] 1-1: Prettier check failed for blog-with-auth-admin. Command failed with exit code 1. Run 'pnpm run prettier:check' to reproduce or 'pnpm run prettier --write .' to fix formatting issues.
🤖 Prompt for AI Agents
In examples/blog-with-auth/apps/admin/src/tests/helpers/logger.test-helper.ts
around line 1, the file fails the project's Prettier formatting check; run the
formatter to fix the styling by executing the project's prettier script (pnpm
run prettier --write
examples/blog-with-auth/apps/admin/src/tests/helpers/logger.test-helper.ts),
review the formatted changes, then stage and commit the updated file so the
pipeline passes.
| './tests/scripts/global-setup-prisma.ts', | ||
| ], | ||
| env: loadEnv('development', process.cwd(), ''), | ||
| globalSetup: ['./tests/scripts/global-setup-prisma.ts'], |
There was a problem hiding this comment.
Critical: Incorrect globalSetup path.
The path './tests/scripts/global-setup-prisma.ts' is missing the src/ prefix. The globalSetup option resolves paths relative to the config file location, not the test.root directory. This will cause the setup script to fail to load.
🔎 Fix the globalSetup path
- globalSetup: ['./tests/scripts/global-setup-prisma.ts'],
+ globalSetup: ['./src/tests/scripts/global-setup-prisma.ts'],📝 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.
| globalSetup: ['./tests/scripts/global-setup-prisma.ts'], | |
| globalSetup: ['./src/tests/scripts/global-setup-prisma.ts'], |
🤖 Prompt for AI Agents
In examples/blog-with-auth/apps/backend/vitest.config.ts around line 11, the
globalSetup path is incorrect because it lacks the src/ prefix; update the path
to point to the actual file location (add src/ so the path resolves relative to
this config file), i.e., replace './tests/scripts/global-setup-prisma.ts' with
the correct './src/tests/scripts/global-setup-prisma.ts' so the setup script can
be loaded.
| import type { GraphQLFormattedError } from 'graphql'; | ||
|
|
||
| import { ApolloError } from '@apollo/client'; | ||
| import { CombinedGraphQLErrors, ServerError } from '@apollo/client/errors'; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Apollo Client v4 CombinedGraphQLErrors ServerError @apollo/client/errors exports
💡 Result:
Yes — in Apollo Client v4 the error classes are exported from "@apollo/client/errors". Key exports you’ll use include CombinedGraphQLErrors and ServerError (along with CombinedProtocolErrors, ServerParseError, LocalStateError, UnconventionalError, etc.). Use their static .is(...) checks to detect types. Note: ServerError is a proper error class and exposes bodyText (not result) for non-2xx responses. [1][2][3]
Sources:
- CombinedGraphQLErrors docs. [1]
- ServerError docs. [2]
- Apollo Client v4 error-handling / migration docs (lists exported error classes and ServerError change). [3]
🏁 Script executed:
# Check the package.json to see Apollo Client version
cd examples/todo-with-auth0/apps/admin
cat package.json | grep -A 5 '"apollo"'Repository: halfdomelabs/baseplate
Length of output: 48
🏁 Script executed:
# Check the actual error-logger.ts file to see the full context
cat -n examples/todo-with-auth0/apps/admin/src/services/error-logger.ts | head -100Repository: halfdomelabs/baseplate
Length of output: 3222
Apollo Client v4 imports are correct, but fix local import extensions.
The imports of CombinedGraphQLErrors and ServerError from @apollo/client/errors are correctly exported in Apollo v4 and properly used with type guards (.is()) and bodyText access.
However, lines 6-7 violate the coding guideline requiring .js extensions for local imports in the examples/todo-with-auth0 directory:
import { logger } from './logger.js';import { logErrorToSentry } from './sentry.js';
🤖 Prompt for AI Agents
In examples/todo-with-auth0/apps/admin/src/services/error-logger.ts around lines
3 to 7, the Apollo imports are fine but the local imports must use .js
extensions; update the local import statements to import { logger } from
'./logger.js' and import { logErrorToSentry } from './sentry.js' so the example
complies with the repo guideline requiring .js extensions for local modules.
| if (CombinedGraphQLErrors.is(error)) { | ||
| for (const graphQLError of error.errors) { | ||
| const { message, path } = graphQLError; | ||
| logger.error( | ||
| \`[GraphQL Error] Message: \${message}, Path: \${ | ||
| path?.join(',') ?? '' | ||
| }, Operation: \${operation.operationName ? operation.operationName : 'Anonymous'}\`, | ||
| ); | ||
| } | ||
| // we just record the first error (usually only one) in order to avoid over-reporting | ||
| // e.g. if a sub-resolver fails for each item in a large array | ||
| const graphQLError = graphQLErrors[0]; | ||
| const graphQLError = error.errors[0]; | ||
| logError(new GraphQLError(graphQLError.message, graphQLError)); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find where CombinedGraphQLErrors is defined or imported
fd -e ts -e tsx | xargs grep -l "CombinedGraphQLErrors" | head -20Repository: halfdomelabs/baseplate
Length of output: 188
🏁 Script executed:
# Check the specific file for imports and usage
cat -n packages/react-generators/src/generators/apollo/apollo-error-link/apollo-error-link.generator.ts | head -80Repository: halfdomelabs/baseplate
Length of output: 3695
🌐 Web query:
Apollo Client v4 CombinedGraphQLErrors error.errors array structure documentation
💡 Result:
CombinedGraphQLErrors.errors is a ReadonlyArray — i.e. each element is a GraphQL-formatted error object (TypeScript type GraphQLFormattedError) with the standard fields: message (string), optional locations (array of {line, column}), optional path (array), and optional extensions (object). See Apollo Client v4 docs and the GraphQL/GraphQL‑JS error format. [1][2]
Sources:
- Apollo Client v4 — CombinedGraphQLErrors (errors: ReadonlyArray). [1]
- GraphQL / graphql-js — GraphQLFormattedError / response error fields (message, locations, path, extensions). [2]
🏁 Script executed:
# Search for CombinedGraphQLErrors import source in the codebase
rg "CombinedGraphQLErrors" --type ts -B 3 -A 3 | head -50Repository: halfdomelabs/baseplate
Length of output: 5996
🌐 Web query:
Apollo Client CombinedGraphQLErrors class definition source errors array constraints
💡 Result:
Short answer: CombinedGraphQLErrors is an Apollo Client error class that wraps the GraphQL "errors" array from a server response. Its important details:
- Defined in the Apollo Client errors API (exported from @apollo/client/errors). [1]
- Instance properties include: data, extensions, result and errors. The errors property is typed as ReadonlyArray (i.e., an array of the GraphQL-formatted error objects returned by the server). [1]
- The class exposes static helpers: is(error) to type‑narrow and formatMessage(errors, options) to customize the error.message string (formatMessage is called by the constructor). [1]
- Semantics: it represents the errors returned in the GraphQL response "errors" field — it therefore contains the server-provided GraphQLFormattedError objects (as-is). The docs treat it as the wrapper for whatever the server put into the response.errors array. [1][2]
If you want the actual implementation/source, see the Apollo Client repository on GitHub (errors are implemented in the errors module of the repo). [2]
Sources:
- Apollo Client API reference — CombinedGraphQLErrors. [1]
- Apollo Client GitHub repository (source distribution). [2]
🌐 Web query:
GraphQL specification errors field requirements non-empty array
💡 Result:
Short answer: The GraphQL spec requires that the top-level "errors" entry, when present, be a non-empty list. If "data" is absent the "errors" list must contain at least one error; if "data" is present it may include any execution/field errors. See the spec. [1][2]
Sources:
- GraphQL Specification — Errors (statement that "errors" is a non‑empty list and rules about when it must be present). [1]
- GraphQL Learn: Response and Errors (practical summary of errors, partial responses, and presence of data/errors). [2]
References:
[1] spec.graphql.org — Errors / Result format (see "The errors entry in the response is a non‑empty list of errors"...).
[2] graphql.org — Response / Errors.
Add length check for consistency with similar error handlers.
The code accesses error.errors[0] without checking array length. While the GraphQL specification guarantees a non-empty errors array when present, similar error handlers in the codebase (apollo-sentry.generator.ts and react-apollo.generator.ts) include explicit length checks before accessing array elements. For consistency and defensive safety, add a check:
- if (CombinedGraphQLErrors.is(error)) {
+ if (CombinedGraphQLErrors.is(error) && error.errors.length > 0) {
for (const graphQLError of error.errors) {🤖 Prompt for AI Agents
In
packages/react-generators/src/generators/apollo/apollo-error-link/apollo-error-link.generator.ts
around lines 55 to 68, the code accesses error.errors[0] without verifying the
array has elements; add a defensive length check (e.g., if (!error.errors ||
error.errors.length === 0) return or skip) before reading error.errors[0] so we
only construct and log a GraphQLError when an element exists, matching the
pattern used in apollo-sentry.generator.ts and react-apollo.generator.ts.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts (1)
15-18: Missing.jsextensions in import statements.The local imports are missing the required
.jsextensions per coding guidelines for this project.
🧹 Nitpick comments (1)
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts (1)
159-181: Consider adding more specific assertion for network error.The test verifies
logErrorwas called but doesn't assert the error details. Consider adding a more specific assertion to verify the reported error contains expected information (e.g., status code, error type).🔎 Example of more specific assertion
// Verify logError was called to report the server error - expect(vi.mocked(logError)).toHaveBeenCalled(); + expect(vi.mocked(logError)).toHaveBeenCalledWith( + expect.objectContaining({ + statusCode: 500, + }), + );
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (31)
examples/todo-with-auth0/apps/admin/baseplate/generated/eslint.config.jsis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/admin/baseplate/generated/tsconfig.node.jsonis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/admin/baseplate/generated/vitest.config.tsis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/backend/baseplate/generated/vitest.config.tsis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/web/baseplate/generated/eslint.config.jsis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/web/baseplate/generated/tsconfig.node.jsonis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/web/baseplate/generated/vitest.config.tsis excluded by!**/generated/**,!**/generated/**tests/simple/apps/backend/baseplate/file-id-map.jsonis excluded by!tests/**tests/simple/apps/backend/baseplate/generated/eslint.config.jsis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/backend/baseplate/generated/package.jsonis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/backend/baseplate/generated/src/tests/scripts/global-setup-env.tsis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/backend/baseplate/generated/src/tests/scripts/global-setup-prisma.tsis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/backend/baseplate/generated/vitest.config.tsis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/backend/eslint.config.jsis excluded by!tests/**tests/simple/apps/backend/package.jsonis excluded by!tests/**tests/simple/apps/backend/src/tests/scripts/global-setup-env.tsis excluded by!tests/**tests/simple/apps/backend/src/tests/scripts/global-setup-prisma.tsis excluded by!tests/**tests/simple/apps/backend/vitest.config.tsis excluded by!tests/**tests/simple/apps/web/baseplate/file-id-map.jsonis excluded by!tests/**tests/simple/apps/web/baseplate/generated/eslint.config.jsis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/web/baseplate/generated/package.jsonis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/web/baseplate/generated/src/tests/helpers/logger.test-helper.tsis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/web/baseplate/generated/tsconfig.node.jsonis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/web/baseplate/generated/vitest.config.tsis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/web/eslint.config.jsis excluded by!tests/**tests/simple/apps/web/package.jsonis excluded by!tests/**tests/simple/apps/web/src/routes/index.tsxis excluded by!tests/**tests/simple/apps/web/src/tests/helpers/logger.test-helper.tsis excluded by!tests/**tests/simple/apps/web/tsconfig.node.jsonis excluded by!tests/**tests/simple/apps/web/vitest.config.tsis excluded by!tests/**tests/simple/pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!tests/**
📒 Files selected for processing (8)
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.tsexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/backend/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.jsexamples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/web/vitest.config.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- examples/todo-with-auth0/apps/backend/vitest.config.ts
- examples/todo-with-auth0/apps/web/vitest.config.ts
🧰 Additional context used
📓 Path-based instructions (11)
examples/todo-with-auth0/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (examples/todo-with-auth0/CLAUDE.md)
Always use .js extensions in import statements, even for TypeScript files. Example:
import { getSystemInfo } from '@src/system-info.js';
Files:
examples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.js
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/code-style.mdc)
**/*.{ts,tsx,js}: Node 16 module resolution - include file extensions in imports (.js)
Sort imports by group: external libs first, then local imports
Use camelCase for variables/functions, PascalCase for types/classes
Order functions such that functions are placed below the variables/functions they use
Prefer using nullish coalescing operator (??) instead of logical or (||), enforced via ESLint rule
Prefer barrel exports e.g.export * from './foo.js'instead of individual named exports
Use console.info/warn/error instead of console.log
Files:
examples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.jsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
examples/todo-with-auth0/**/*.{ts,tsx}
📄 CodeRabbit inference engine (examples/todo-with-auth0/CLAUDE.md)
examples/todo-with-auth0/**/*.{ts,tsx}: Useimport typefor type-only imports
Always specify explicit return types for functions
Add JSDocs to all exported functions, interfaces, and classes with documentation of the function, its parameters, return value, and all fields
Files:
examples/todo-with-auth0/apps/admin/vitest.config.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/code-style.mdc)
**/*.{ts,tsx}: Use TypeScript with strict type checking enabled
Always include return types on top-level functions including React components (React.ReactElement)
Include absolute paths in import statements via tsconfig paths (@src/is the alias forsrc/)
If a particular interface or type is not exported, change the file so it is exported
If caught on a typing loop where forcing theanytype is necessary, do not iterate too much - leave the typing as broken and let the user fix itIf target code is not easily testable, refactor it to be more testable (e.g., export types or functions)
**/*.{ts,tsx}: Import components from '@baseplate-dev/ui-components' package for UI development (e.g., Button, Input, Card, Dialog, etc.)
Use form components with React Hook Form controller variants (InputField, TextareaField, SelectField, CheckboxField, SwitchField, ComboboxField, MultiComboboxField, ColorPickerField, DatePickerField, DateTimePickerField)
Use SidebarLayout, Card, Breadcrumb, NavigationMenu, and NavigationTabs components for consistent layout structure from @baseplate-dev/ui-components
Use Dialog, ConfirmDialog, and useConfirmDialog from @baseplate-dev/ui-components for modal dialogs and confirmation interactions
Always usecompareStringsfrom@baseplate-dev/utilsinstead ofString.prototype.localeCompare()for code generation, file sorting, and internal data structures
If a particular interface or type is not exported, modify the file to export it
Use TsCodeFragment for composable code pieces and TsCodeUtils for manipulating fragments when generating TypeScript code
Create generators usingcreateGeneratorwith configuration via descriptor schema (Zod), organizing into one or more tasks created withcreateGeneratorTask
Tasks should haverun(initialization) andbuild(code generation) phases, export and consume providers, and may be organized into phases for ordered execution
Use provider scopes to control visibility and prevent collisions be...
Files:
examples/todo-with-auth0/apps/admin/vitest.config.tsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
examples/blog-with-auth/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (examples/blog-with-auth/CLAUDE.md)
examples/blog-with-auth/**/*.{ts,tsx,js,jsx}: Always use .js extensions in import statements, even for TypeScript files (e.g.,import { getSystemInfo } from '@src/system-info.js';)
Follow ESM module resolution with TypeScript'sNodeNextsetting
Add JSDocs to all exported functions, interfaces, and classes with documentation of the function, its parameters, return value, and all fields
Files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
examples/blog-with-auth/**/*.{ts,tsx}
📄 CodeRabbit inference engine (examples/blog-with-auth/CLAUDE.md)
examples/blog-with-auth/**/*.{ts,tsx}: Useimport typefor type-only imports in TypeScript
Always specify explicit return types for functions in TypeScript
Files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
examples/blog-with-auth/**/*.{unit,int}.test.ts
📄 CodeRabbit inference engine (examples/blog-with-auth/CLAUDE.md)
Use
.unit.test.tsor.int.test.tssuffixes for test files and collocate tests with source files
Files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
examples/blog-with-auth/**/*.test.ts
📄 CodeRabbit inference engine (examples/blog-with-auth/CLAUDE.md)
Import test functions explicitly from 'vitest' instead of relying on globals (e.g.,
import { describe, expect, it } from 'vitest';)
Files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
**/*.{unit.test.ts,int.test.ts}
📄 CodeRabbit inference engine (.cursor/rules/code-style.mdc)
**/*.{unit.test.ts,int.test.ts}: Unit tests must use.unit.test.tssuffix, integration tests must use.int.test.tssuffix
Always import vitest globals explicitly (describe, it, expect)
Files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
**/*.{unit,int}.test.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/testing.mdc)
**/*.{unit,int}.test.{ts,tsx}: Use descriptive test names that explain what is being tested
Structure tests with Arrange-Act-Assert: clear setup, execution, and verification phases
Always mock external API calls and file system operations
Each test should be independent and not rely on other tests
Leverage TypeScript for type-safe mocking in tests
Focus on testing public methods and behaviors, not implementation details
Each test should verify one specific behavior
Extract repeated logic into helper functions to reduce duplication
Test broad behavior and common edge cases intelligently to avoid slowing down CI with excessive tests
For file system operations in tests, use memfs and mocknode:fsandnode:fs/promises
When using globby with mocked fs, pass the mocked fs adapter to the globby call
Files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
**/*.unit.test.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/testing.mdc)
Unit tests are colocated with source files using
.unit.test.tssuffix
Files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
🧠 Learnings (33)
📓 Common learnings
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{unit,int}.test.ts : Import test functions explicitly from 'vitest' instead of using globals. Example: `import { describe, expect, it } from 'vitest';`
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.test.ts : Import test functions explicitly from 'vitest' instead of relying on globals (e.g., `import { describe, expect, it } from 'vitest';`)
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-11-24T19:45:01.582Z
Learning: Applies to **/*.{unit.test.ts,int.test.ts} : Always import vitest globals explicitly (describe, it, expect)
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{unit,int}.test.ts : Import test functions explicitly from 'vitest' instead of using globals. Example: `import { describe, expect, it } from 'vitest';`
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.jsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/tsconfig.json : Use `NodeNext` module resolution in TypeScript configuration
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/vitest.config.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/tsconfig.json : Use strict type checking in TypeScript configuration
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.js
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.test.ts : Import test functions explicitly from 'vitest' instead of relying on globals (e.g., `import { describe, expect, it } from 'vitest';`)
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.js
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{unit,int}.test.ts : Use `.unit.test.ts` or `.int.test.ts` suffixes for test files in TypeScript
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.jsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/tsconfig.json : Enable `isolatedModules` in TypeScript configuration
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/vitest.config.ts
📚 Learning: 2025-11-24T19:45:01.582Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-11-24T19:45:01.582Z
Learning: Applies to **/*.{ts,tsx,js} : Node 16 module resolution - include file extensions in imports (`.js`)
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{ts,tsx} : Use `import type` for type-only imports
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.jsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{ts,tsx} : Add JSDocs to all exported functions, interfaces, and classes with documentation of the function, its parameters, return value, and all fields
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/web/eslint.config.js
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.{ts,tsx,js,jsx} : Follow ESM module resolution with TypeScript's `NodeNext` setting
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:45:01.582Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-11-24T19:45:01.582Z
Learning: Applies to **/*.{unit.test.ts,int.test.ts} : Always import vitest globals explicitly (describe, it, expect)
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.js
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Test broad behavior and common edge cases intelligently to avoid slowing down CI with excessive tests
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/admin/vitest.config.tsexamples/todo-with-auth0/apps/web/eslint.config.jsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.unit.test.{ts,tsx} : Unit tests are colocated with source files using `.unit.test.ts` suffix
Applied to files:
examples/todo-with-auth0/apps/web/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/tsconfig.node.jsonexamples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/web/eslint.config.js
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.int.test.{ts,tsx} : Integration tests use `.int.test.ts` suffix
Applied to files:
examples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/web/eslint.config.js
📚 Learning: 2025-07-30T13:27:20.000Z
Learnt from: kingston
Repo: halfdomelabs/baseplate PR: 623
File: plugins/plugin-auth/src/local-auth/core/generators/react-session/templates/src/app/user-session-provider.tsx:6-12
Timestamp: 2025-07-30T13:27:20.000Z
Learning: Ignore ESLint import ordering rules for files in templates/** directories as these are code generation templates, not direct source code.
Applied to files:
examples/todo-with-auth0/apps/admin/eslint.config.jsexamples/todo-with-auth0/apps/web/eslint.config.js
📚 Learning: 2025-04-23T06:44:30.952Z
Learnt from: kingston
Repo: halfdomelabs/baseplate PR: 510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In the project-builder-server test suite, Vitest automocks for 'node:fs' and 'node:fs/promises' are already configured to use memfs without needing explicit implementation replacement in each test file.
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.ts
📚 Learning: 2025-04-23T06:44:30.952Z
Learnt from: kingston
Repo: halfdomelabs/baseplate PR: 510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In this codebase, when testing file operations, Vitest's automocks for 'node:fs' and 'node:fs/promises' are used in conjunction with memfs, but without replacing the mock implementation explicitly in each test file. The virtual filesystem is populated using vol.fromJSON or similar methods, which works seamlessly with the automocks.
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Leverage TypeScript for type-safe mocking in tests
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.tsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-07-10T06:49:07.714Z
Learnt from: kingston
Repo: halfdomelabs/baseplate PR: 598
File: packages/fastify-generators/src/generators/yoga/yoga-plugin/templates/src/plugins/graphql/index.ts:18-18
Timestamp: 2025-07-10T06:49:07.714Z
Learning: In React projects using Vite, keep the .env file naming convention as .env.development, .env.production, etc. even when internal application environment values use shorter abbreviations like 'dev', 'stage', 'prod'. This follows Vite's mode conventions.
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.{ts,tsx} : Use `import type` for type-only imports in TypeScript
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.tsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{ts,tsx,js,jsx} : Always use .js extensions in import statements, even for TypeScript files. Example: `import { getSystemInfo } from 'src/system-info.js';`
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.tsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Each test should be independent and not rely on other tests
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.ts
📚 Learning: 2025-06-30T11:52:28.745Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.test.{ts,tsx} : For file system operations in tests, use memfs and mock 'node:fs' and 'node:fs/promises' with vi.mock
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Always mock external API calls and file system operations
Applied to files:
examples/todo-with-auth0/apps/admin/vitest.config.tsexamples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.{unit,int}.test.ts : Use `.unit.test.ts` or `.int.test.ts` suffixes for test files and collocate tests with source files
Applied to files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Focus on testing public methods and behaviors, not implementation details
Applied to files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Extract repeated logic into helper functions to reduce duplication
Applied to files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Use descriptive test names that explain what is being tested
Applied to files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Each test should verify one specific behavior
Applied to files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.{ts,tsx,js,jsx} : Always use .js extensions in import statements, even for TypeScript files (e.g., `import { getSystemInfo } from 'src/system-info.js';`)
Applied to files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-07-16T17:15:56.714Z
Learnt from: kingston
Repo: halfdomelabs/baseplate PR: 613
File: packages/react-generators/src/generators/core/react-components/templates/components/ui/circular-progress/circular-progress.tsx:0-0
Timestamp: 2025-07-16T17:15:56.714Z
Learning: For imports starting with `$` (template aliases), do not require `.js` extensions as these are resolved differently during the generation process, unlike regular file imports which require explicit `.js` extensions under Node 16 module resolution.
Applied to files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.{ts,tsx} : Always specify explicit return types for functions in TypeScript
Applied to files:
examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test E2E
🔇 Additional comments (10)
examples/todo-with-auth0/apps/admin/vitest.config.ts (1)
1-16: LGTM! Vitest configuration is properly set up.The configuration is correct with all necessary imports present and appropriate test options configured. The use of
loadEnv('development', ...)aligns with Vite's mode conventions, and the test options (clearMocks, maxWorkers, root) provide a solid foundation for testing.examples/todo-with-auth0/apps/web/tsconfig.node.json (1)
19-19: LGTM! TypeScript configuration correctly updated for Vitest.Adding
vitest.config.tsto the include array ensures TypeScript properly processes and type-checks the Vitest configuration file.examples/todo-with-auth0/apps/admin/tsconfig.node.json (1)
19-19: LGTM! TypeScript configuration correctly updated for Vitest.Adding
vitest.config.tsto the include array ensures TypeScript properly processes and type-checks the Vitest configuration file, consistent with the web app configuration.examples/blog-with-auth/apps/admin/src/services/apollo/apollo.unit.test.ts (5)
20-53: Well-structured dependency mocks.The mocks properly isolate external dependencies (error logger, logger, user session, Sentry link, and config) enabling focused unit testing of the Apollo client error handling behavior.
73-87: LGTM - proper test lifecycle management.The MSW server lifecycle hooks are correctly configured with
onUnhandledRequest: 'error'to catch unexpected requests, proper cleanup between tests, and server teardown.
89-130: Well-structured GraphQL error test with proper assertions.The test correctly verifies both logging behavior (
logger.error) and error reporting (logError), including verification that GraphQL error extensions are preserved in the reported error.
132-157: Good test for mutation error handling distinction.This test correctly verifies the intentional design decision that mutation errors are not automatically logged, allowing callers to handle them appropriately.
184-273: Comprehensive session error handling test coverage.The tests thoroughly cover the
sessionErrorLinkbehavior:
- Correctly triggers sign out only on 401 with
invalid-sessioncode- Properly ignores 401 responses with different error codes
- Correctly ignores non-401 status codes regardless of body content
- Handles non-JSON response bodies gracefully
This ensures robust session management that won't inadvertently sign users out.
examples/todo-with-auth0/apps/admin/eslint.config.js (1)
2-2: LGTM!The import of the Vitest ESLint plugin is correct.
examples/todo-with-auth0/apps/web/eslint.config.js (1)
2-2: LGTM!The import of the Vitest ESLint plugin is correct.
| // Vitest Configs | ||
| { | ||
| files: ['**/*.test.{ts,js,tsx,jsx}', 'tests/**'], | ||
| plugins: { vitest }, | ||
| rules: { | ||
| ...vitest.configs.recommended.rules, | ||
| // Helpful in dev but should flag as errors when linting | ||
| 'vitest/no-focused-tests': 'error', | ||
| }, | ||
| settings: { | ||
| vitest: { | ||
| typecheck: true, | ||
| }, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for vitest config files
fd -type f \( -name "vitest.config.*" -o -name "vite.config.*" \) examples/todo-with-auth0/apps/adminRepository: halfdomelabs/baseplate
Length of output: 236
🏁 Script executed:
# Also search the entire examples/todo-with-auth0 directory
fd -type f \( -name "vitest.config.*" -o -name "vite.config.*" \) examples/todo-with-auth0Repository: halfdomelabs/baseplate
Length of output: 236
🏁 Script executed:
# Check the actual test files to see if they import vitest functions explicitly
fd -type f -name "*.test.ts" examples/todo-with-auth0/apps/admin | head -5 | xargs -I {} sh -c 'echo "=== {} ===" && head -20 {}'Repository: halfdomelabs/baseplate
Length of output: 236
🏁 Script executed:
# Search for vitest config files with correct syntax
fd vitest.config examples/todo-with-auth0/apps/adminRepository: halfdomelabs/baseplate
Length of output: 118
🏁 Script executed:
# Search for vite config files
fd vite.config examples/todo-with-auth0/apps/adminRepository: halfdomelabs/baseplate
Length of output: 116
🏁 Script executed:
# Search for vitest config in the entire todo-with-auth0 directory
fd vitest.config examples/todo-with-auth0Repository: halfdomelabs/baseplate
Length of output: 224
🏁 Script executed:
# List test files in admin app and show their first imports
find examples/todo-with-auth0/apps/admin -name "*.test.ts" -o -name "*.test.tsx" | head -5 | xargs -I {} sh -c 'echo "=== {} ===" && head -15 {}'Repository: halfdomelabs/baseplate
Length of output: 48
🏁 Script executed:
# Read the vitest.config.ts to check globals setting
cat examples/todo-with-auth0/apps/admin/vitest.config.tsRepository: halfdomelabs/baseplate
Length of output: 478
🏁 Script executed:
# Search for test files using fd
fd '\.test\.ts' examples/todo-with-auth0/apps/admin | head -5Repository: halfdomelabs/baseplate
Length of output: 48
🏁 Script executed:
# Alternative search for test files
fd -e test.ts examples/todo-with-auth0/apps/admin | head -5Repository: halfdomelabs/baseplate
Length of output: 511
🏁 Script executed:
# Find test files using correct fd syntax
fd '\.test\.ts$' examples/todo-with-auth0/apps/adminRepository: halfdomelabs/baseplate
Length of output: 48
🏁 Script executed:
# Also try finding in src subdirectory
fd '\.test\.ts$' examples/todo-with-auth0/apps/admin/srcRepository: halfdomelabs/baseplate
Length of output: 48
🏁 Script executed:
# List all ts files to understand structure
find examples/todo-with-auth0/apps/admin -name "*.ts" -type f | grep -i test | head -10Repository: halfdomelabs/baseplate
Length of output: 194
🏁 Script executed:
# Look for test files more broadly
find examples/todo-with-auth0/apps/admin -type f -name "*test*"Repository: halfdomelabs/baseplate
Length of output: 194
🏁 Script executed:
# Check the eslint.config.js file mentioned in the review
cat examples/todo-with-auth0/apps/admin/eslint.config.js | head -50Repository: halfdomelabs/baseplate
Length of output: 1961
🏁 Script executed:
# Search for any test files in the entire todo-with-auth0 examples
find examples/todo-with-auth0 -type f -name "*.test.ts" | head -10Repository: halfdomelabs/baseplate
Length of output: 667
🏁 Script executed:
# Check a backend test file to see how it imports vitest functions
head -20 examples/todo-with-auth0/apps/backend/src/modules/storage/utils/mime.unit.test.tsRepository: halfdomelabs/baseplate
Length of output: 695
🏁 Script executed:
# Check another backend test file
head -20 examples/todo-with-auth0/apps/backend/src/modules/accounts/users/services/user.crud.int.test.tsRepository: halfdomelabs/baseplate
Length of output: 699
🏁 Script executed:
# Search for any test files in admin app with different pattern
find examples/todo-with-auth0/apps/admin -type f \( -name "*.test.ts" -o -name "*.unit.test.ts" -o -name "*.int.test.ts" \)Repository: halfdomelabs/baseplate
Length of output: 48
Add globals: false to the Vitest configuration to enforce explicit imports.
The admin app's vitest.config.ts is missing the globals: false setting. While the backend test files correctly import test functions explicitly (import { describe, expect, it } from 'vitest';), this setting should be enforced in the Vitest config to prevent accidental reliance on global test functions. Update the test config in examples/todo-with-auth0/apps/admin/vitest.config.ts to include globals: false within the test object:
test: {
clearMocks: true,
env: loadEnv('development', process.cwd(), ''),
globals: false,
maxWorkers: 1,
passWithNoTests: true,
root: './src',
},
🤖 Prompt for AI Agents
In examples/todo-with-auth0/apps/admin/eslint.config.js around lines 308 to 322,
the Vitest rule block is fine but the project's Vitest configuration file needs
to enforce explicit imports; open
examples/todo-with-auth0/apps/admin/vitest.config.ts and inside the exported
test object add globals: false alongside the existing properties (e.g.
clearMocks, env, maxWorkers, passWithNoTests, root) so tests must import
describe/it/expect explicitly; save and run lint/tests to verify no globals are
available.
| // Vitest Configs | ||
| { | ||
| files: ['**/*.test.{ts,js,tsx,jsx}', 'tests/**'], | ||
| plugins: { vitest }, | ||
| rules: { | ||
| ...vitest.configs.recommended.rules, | ||
| // Helpful in dev but should flag as errors when linting | ||
| 'vitest/no-focused-tests': 'error', | ||
| }, | ||
| settings: { | ||
| vitest: { | ||
| typecheck: true, | ||
| }, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find vitest configuration files in the project
fd -type f 'vitest\.(config|setup)' -e ts -e js examples/todo-with-auth0Repository: halfdomelabs/baseplate
Length of output: 236
🏁 Script executed:
# Also check the complete eslint.config.js to see the full Vitest ESLint configuration
cat -n examples/todo-with-auth0/apps/web/eslint.config.js | sed -n '300,330p'Repository: halfdomelabs/baseplate
Length of output: 872
🏁 Script executed:
# Search for any globals configuration in eslint.config.js related to vitest
rg 'globals|vitest' examples/todo-with-auth0/apps/web/eslint.config.js -A 3 -B 3Repository: halfdomelabs/baseplate
Length of output: 1174
🏁 Script executed:
# Find vitest config files
find examples/todo-with-auth0 -name 'vitest.config*' -o -name 'vitest.setup*' 2>/dev/nullRepository: halfdomelabs/baseplate
Length of output: 224
🏁 Script executed:
# Check for any mention of 'globals' in relation to vitest in the entire project
rg 'globals.*:.*false|vitest.*globals' examples/todo-with-auth0 -A 2 -B 2Repository: halfdomelabs/baseplate
Length of output: 492
🏁 Script executed:
# Check the complete languageOptions section in eslint.config.js to understand how globals are set
cat examples/todo-with-auth0/apps/web/eslint.config.js | head -80Repository: halfdomelabs/baseplate
Length of output: 3200
🏁 Script executed:
# Look at the full vitest configs section to see if there's a languageOptions block
rg -A 15 '// Vitest Configs' examples/todo-with-auth0/apps/web/eslint.config.jsRepository: halfdomelabs/baseplate
Length of output: 452
🏁 Script executed:
# Check the vitest.config.ts for the web app to see if globals are disabled there
cat examples/todo-with-auth0/apps/web/vitest.config.tsRepository: halfdomelabs/baseplate
Length of output: 478
🏁 Script executed:
# Also check the other vitest configs for consistency
cat examples/todo-with-auth0/apps/admin/vitest.config.tsRepository: halfdomelabs/baseplate
Length of output: 478
Add globals: false to Vitest configuration to enforce explicit imports.
The project guideline (CLAUDE.md) requires importing test functions explicitly from 'vitest' without globals, but the current configuration does not enforce this:
vitest.config.tsfiles (web/admin/backend) omit theglobals: falsesetting, which defaults totruein Vitest- The ESLint Vitest config (eslint.config.js:308-322) lacks
languageOptions: { globals: {} }to prevent test globals during linting
Add globals: false in the test config of vitest.config.ts files and add languageOptions: { globals: {} } to the ESLint Vitest config block to enforce explicit imports as documented.
🤖 Prompt for AI Agents
In examples/todo-with-auth0/apps/web/eslint.config.js around lines 308 to 322,
the Vitest ESLint block lacks languageOptions to disable test globals; update
this block to add languageOptions: { globals: {} } so eslint will not recognize
Vitest globals. Also, in the project's Vitest config files (vitest.config.ts in
web, admin, backend), set test: { globals: false } (or add globals: false at the
top-level test config) so Vitest itself requires explicit imports; make both
changes together to enforce the CLAUDE.md policy requiring explicit imports of
test helpers.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.ts (1)
5-23: Add JSDocs to exported function.The exported
setupfunction is missing JSDocs documentation. Per coding guidelines, all exported functions should include documentation describing the function, its parameters, and return value.🔎 Proposed JSDocs addition
+/** + * Global setup function for Prisma test database. + * Creates a separate test database and runs migrations when not in unit test mode. + * @param project - The Vitest test project containing environment configuration + * @returns A promise that resolves when setup is complete + */ export default async function setup(project: TestProject): Promise<void> {Based on coding guidelines for examples/todo-with-auth0/**/*.{ts,tsx}.
packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.ts (1)
7-25: Add JSDocs to exported function.The exported
setupfunction is missing JSDocs documentation. Per coding guidelines, all exported functions should include documentation describing the function, its parameters, and return value.🔎 Proposed JSDocs addition
+/** + * Global setup function for Prisma test database. + * Creates a separate test database and runs migrations when not in unit test mode. + * @param project - The Vitest test project containing environment configuration + * @returns A promise that resolves when setup is complete + */ export default async function setup(project: TestProject): Promise<void> {Based on coding guidelines for **/*.{ts,tsx}.
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts (1)
5-23: Add JSDocs to exported function.The exported
setupfunction is missing JSDocs documentation. Per coding guidelines, all exported functions should include documentation describing the function, its parameters, and return value.🔎 Proposed JSDocs addition
+/** + * Global setup function for Prisma test database. + * Creates a separate test database and runs migrations when not in unit test mode. + * @param project - The Vitest test project containing environment configuration + * @returns A promise that resolves when setup is complete + */ export default async function setup(project: TestProject): Promise<void> {Based on coding guidelines for examples/blog-with-auth/**/*.{ts,tsx}.
examples/todo-with-auth0/apps/web/src/services/apollo/index.ts (1)
35-68: Add bounds check before accessingerror.errors[0].Line 58 accesses
error.errors[0]without verifying the array is non-empty. ThelogErrorfunction (inerror-logger.ts) defensively checksif (error.errors.length > 0)before the same access. Apply consistent defensive programming here.🔎 Suggested fix
- // we just record the first error (usually only one) in order to avoid over-reporting - // e.g. if a sub-resolver fails for each item in a large array - const graphQLError = error.errors[0]; - logError(new GraphQLError(graphQLError.message, graphQLError)); + // we just record the first error (usually only one) in order to avoid over-reporting + // e.g. if a sub-resolver fails for each item in a large array + if (error.errors.length > 0) { + const graphQLError = error.errors[0]; + logError(new GraphQLError(graphQLError.message, graphQLError)); + }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (7)
examples/blog-with-auth/apps/backend/baseplate/generated/src/tests/scripts/global-setup-prisma.tsis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/admin/baseplate/generated/src/services/apollo/index.tsis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/admin/src/generated/graphql.tsxis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/backend/baseplate/generated/src/tests/scripts/global-setup-prisma.tsis excluded by!**/generated/**,!**/generated/**examples/todo-with-auth0/apps/web/baseplate/generated/src/services/apollo/index.tsis excluded by!**/generated/**,!**/generated/**tests/simple/apps/backend/baseplate/generated/src/tests/scripts/global-setup-prisma.tsis excluded by!**/generated/**,!tests/**,!**/generated/**tests/simple/apps/backend/src/tests/scripts/global-setup-prisma.tsis excluded by!tests/**
📒 Files selected for processing (7)
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.tsexamples/todo-with-auth0/apps/admin/src/services/apollo/index.tsexamples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tsexamples/todo-with-auth0/apps/web/src/services/apollo/index.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsplugins/plugin-auth/src/auth0/generators/react/auth0-apollo/auth0-apollo.generator.tsplugins/plugin-auth/src/auth0/generators/react/auth0-apollo/templates/auth-link.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- examples/todo-with-auth0/apps/admin/src/services/apollo/index.ts
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/code-style.mdc)
**/*.{ts,tsx}: Use TypeScript with strict type checking enabled
Always include return types on top-level functions including React components (React.ReactElement)
Include absolute paths in import statements via tsconfig paths (@src/is the alias forsrc/)
If a particular interface or type is not exported, change the file so it is exported
If caught on a typing loop where forcing theanytype is necessary, do not iterate too much - leave the typing as broken and let the user fix itIf target code is not easily testable, refactor it to be more testable (e.g., export types or functions)
**/*.{ts,tsx}: Import components from '@baseplate-dev/ui-components' package for UI development (e.g., Button, Input, Card, Dialog, etc.)
Use form components with React Hook Form controller variants (InputField, TextareaField, SelectField, CheckboxField, SwitchField, ComboboxField, MultiComboboxField, ColorPickerField, DatePickerField, DateTimePickerField)
Use SidebarLayout, Card, Breadcrumb, NavigationMenu, and NavigationTabs components for consistent layout structure from @baseplate-dev/ui-components
Use Dialog, ConfirmDialog, and useConfirmDialog from @baseplate-dev/ui-components for modal dialogs and confirmation interactions
Always usecompareStringsfrom@baseplate-dev/utilsinstead ofString.prototype.localeCompare()for code generation, file sorting, and internal data structures
If a particular interface or type is not exported, modify the file to export it
Use TsCodeFragment for composable code pieces and TsCodeUtils for manipulating fragments when generating TypeScript code
Create generators usingcreateGeneratorwith configuration via descriptor schema (Zod), organizing into one or more tasks created withcreateGeneratorTask
Tasks should haverun(initialization) andbuild(code generation) phases, export and consume providers, and may be organized into phases for ordered execution
Use provider scopes to control visibility and prevent collisions be...
Files:
plugins/plugin-auth/src/auth0/generators/react/auth0-apollo/auth0-apollo.generator.tsexamples/todo-with-auth0/apps/web/src/services/apollo/index.tsexamples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.tsplugins/plugin-auth/src/auth0/generators/react/auth0-apollo/templates/auth-link.ts
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/code-style.mdc)
**/*.{ts,tsx,js}: Node 16 module resolution - include file extensions in imports (.js)
Sort imports by group: external libs first, then local imports
Use camelCase for variables/functions, PascalCase for types/classes
Order functions such that functions are placed below the variables/functions they use
Prefer using nullish coalescing operator (??) instead of logical or (||), enforced via ESLint rule
Prefer barrel exports e.g.export * from './foo.js'instead of individual named exports
Use console.info/warn/error instead of console.log
Files:
plugins/plugin-auth/src/auth0/generators/react/auth0-apollo/auth0-apollo.generator.tsexamples/todo-with-auth0/apps/web/src/services/apollo/index.tsexamples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.tsplugins/plugin-auth/src/auth0/generators/react/auth0-apollo/templates/auth-link.ts
examples/todo-with-auth0/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (examples/todo-with-auth0/CLAUDE.md)
Always use .js extensions in import statements, even for TypeScript files. Example:
import { getSystemInfo } from '@src/system-info.js';
Files:
examples/todo-with-auth0/apps/web/src/services/apollo/index.tsexamples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.ts
examples/todo-with-auth0/**/*.{ts,tsx}
📄 CodeRabbit inference engine (examples/todo-with-auth0/CLAUDE.md)
examples/todo-with-auth0/**/*.{ts,tsx}: Useimport typefor type-only imports
Always specify explicit return types for functions
Add JSDocs to all exported functions, interfaces, and classes with documentation of the function, its parameters, return value, and all fields
Files:
examples/todo-with-auth0/apps/web/src/services/apollo/index.tsexamples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.ts
examples/blog-with-auth/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (examples/blog-with-auth/CLAUDE.md)
examples/blog-with-auth/**/*.{ts,tsx,js,jsx}: Always use .js extensions in import statements, even for TypeScript files (e.g.,import { getSystemInfo } from '@src/system-info.js';)
Follow ESM module resolution with TypeScript'sNodeNextsetting
Add JSDocs to all exported functions, interfaces, and classes with documentation of the function, its parameters, return value, and all fields
Files:
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
examples/blog-with-auth/**/*.{ts,tsx}
📄 CodeRabbit inference engine (examples/blog-with-auth/CLAUDE.md)
examples/blog-with-auth/**/*.{ts,tsx}: Useimport typefor type-only imports in TypeScript
Always specify explicit return types for functions in TypeScript
Files:
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
🧠 Learnings (22)
📓 Common learnings
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{unit,int}.test.ts : Import test functions explicitly from 'vitest' instead of using globals. Example: `import { describe, expect, it } from 'vitest';`
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.test.ts : Import test functions explicitly from 'vitest' instead of relying on globals (e.g., `import { describe, expect, it } from 'vitest';`)
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-11-24T19:45:01.582Z
Learning: Applies to **/*.{unit.test.ts,int.test.ts} : Always import vitest globals explicitly (describe, it, expect)
📚 Learning: 2025-11-25T22:46:20.505Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-25T22:46:20.505Z
Learning: Applies to **/*.{ts,tsx} : Use TsCodeFragment for composable code pieces and TsCodeUtils for manipulating fragments when generating TypeScript code
Applied to files:
plugins/plugin-auth/src/auth0/generators/react/auth0-apollo/auth0-apollo.generator.ts
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{unit,int}.test.ts : Import test functions explicitly from 'vitest' instead of using globals. Example: `import { describe, expect, it } from 'vitest';`
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.test.ts : Import test functions explicitly from 'vitest' instead of relying on globals (e.g., `import { describe, expect, it } from 'vitest';`)
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:45:01.582Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-11-24T19:45:01.582Z
Learning: Applies to **/*.{unit.test.ts,int.test.ts} : Always import vitest globals explicitly (describe, it, expect)
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-04-23T06:44:30.952Z
Learnt from: kingston
Repo: halfdomelabs/baseplate PR: 510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In the project-builder-server test suite, Vitest automocks for 'node:fs' and 'node:fs/promises' are already configured to use memfs without needing explicit implementation replacement in each test file.
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{unit,int}.test.ts : Use `.unit.test.ts` or `.int.test.ts` suffixes for test files in TypeScript
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{ts,tsx} : Use `import type` for type-only imports
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:44:46.506Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/todo-with-auth0/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:46.506Z
Learning: Applies to examples/todo-with-auth0/**/*.{ts,tsx} : Add JSDocs to all exported functions, interfaces, and classes with documentation of the function, its parameters, return value, and all fields
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.test-helper.{ts,tsx} : Extract common setup code into test helpers in `*.test-helper.ts` files
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Leverage TypeScript for type-safe mocking in tests
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-04-23T06:44:30.952Z
Learnt from: kingston
Repo: halfdomelabs/baseplate PR: 510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: When testing file operations in this codebase, the pattern is to use Vitest automocks for 'node:fs' and 'node:fs/promises' (without explicit implementation replacement) while populating a virtual filesystem with vol.fromJSON() from memfs. File operations in tests are performed directly via vol.promises methods.
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-04-23T06:44:30.952Z
Learnt from: kingston
Repo: halfdomelabs/baseplate PR: 510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In this codebase, when testing file operations, Vitest's automocks for 'node:fs' and 'node:fs/promises' are used in conjunction with memfs, but without replacing the mock implementation explicitly in each test file. The virtual filesystem is populated using vol.fromJSON or similar methods, which works seamlessly with the automocks.
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Structure tests with Arrange-Act-Assert: clear setup, execution, and verification phases
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : For file system operations in tests, use memfs and mock `node:fs` and `node:fs/promises`
Applied to files:
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.tspackages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.tsexamples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Test broad behavior and common edge cases intelligently to avoid slowing down CI with excessive tests
Applied to files:
packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:45:19.136Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-24T19:45:19.136Z
Learning: Applies to **/*.{unit,int}.test.{ts,tsx} : Focus on testing public methods and behaviors, not implementation details
Applied to files:
packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-06-30T11:52:28.745Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.test.{ts,tsx} : For file system operations in tests, use memfs and mock 'node:fs' and 'node:fs/promises' with vi.mock
Applied to files:
packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.{ts,tsx} : Use `import type` for type-only imports in TypeScript
Applied to files:
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/tsconfig.json : Use strict type checking in TypeScript configuration
Applied to files:
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/tsconfig.json : Use `NodeNext` module resolution in TypeScript configuration
Applied to files:
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
📚 Learning: 2025-11-24T19:44:33.994Z
Learnt from: CR
Repo: halfdomelabs/baseplate PR: 0
File: examples/blog-with-auth/CLAUDE.md:0-0
Timestamp: 2025-11-24T19:44:33.994Z
Learning: Applies to examples/blog-with-auth/**/*.{unit,int}.test.ts : Use `.unit.test.ts` or `.int.test.ts` suffixes for test files and collocate tests with source files
Applied to files:
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts
🧬 Code graph analysis (4)
plugins/plugin-auth/src/auth0/generators/react/auth0-apollo/auth0-apollo.generator.ts (1)
packages/core-generators/src/renderers/typescript/imports/builder.ts (1)
tsImportBuilder(74-82)
examples/todo-with-auth0/apps/web/src/services/apollo/index.ts (1)
examples/todo-with-auth0/apps/web/src/services/error-logger.ts (1)
logError(44-90)
examples/todo-with-auth0/apps/backend/src/tests/scripts/global-setup-prisma.ts (3)
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts (1)
setup(5-23)packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.ts (1)
setup(7-25)packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/helpers/db.test-helper.ts (1)
createTestDatabase(29-54)
packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/scripts/global-setup-prisma.ts (2)
examples/blog-with-auth/apps/backend/src/tests/scripts/global-setup-prisma.ts (1)
setup(5-23)packages/fastify-generators/src/generators/vitest/prisma-vitest/templates/src/tests/helpers/db.test-helper.ts (1)
createTestDatabase(29-54)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Lint Examples (todo-with-auth0)
- GitHub Check: Verify Sync (todo-with-auth0)
- GitHub Check: Verify Sync (blog-with-auth)
- GitHub Check: Lint
- GitHub Check: test
- GitHub Check: Test E2E
🔇 Additional comments (6)
plugins/plugin-auth/src/auth0/generators/react/auth0-apollo/auth0-apollo.generator.ts (1)
45-47: The import change fromsetContexttoSetContextLinkis correct for Apollo Client v4. The template fileauth-link.tsproperly usesSetContextLinkwithnew SetContextLink(async () => { ... }), matching the Apollo Client v4 API which requires a class constructor instead of a helper function.plugins/plugin-auth/src/auth0/generators/react/auth0-apollo/templates/auth-link.ts (1)
4-10: No action required — API usage is correct.The Apollo Client v4
SetContextLinkAPI is correctly used. Verification confirms:
SetContextLinkis the correct Apollo Client v4 API and is properly imported from@apollo/client/link/contextby the generator code- The generator (auth0-apollo.generator.ts) properly generates the import statement
- This pattern is already used in the codebase examples and matches Apollo Client v4 specifications
examples/todo-with-auth0/apps/web/src/services/apollo/index.ts (4)
70-76: The SetContextLink migration looks correct.The change from
setContexttonew SetContextLinkaligns with the v4 migration pattern. The callback logic remains unchanged and correctly returns authentication headers.
83-90: The ApolloLink.from usage looks correct.The migration from
from([...])toApolloLink.from([...])is consistent with v4. The link composition order (error handling → monitoring → auth → transport) follows best practices.
33-33: The return type change fromApolloClient<NormalizedCacheObject>toApolloClientis correct for Apollo Client v4. The TCacheShape generic parameter was removed in v4, soApolloClientwithout the generic is the proper pattern and matches the library's API design.
1-4: Apollo Client v4 import paths and types are correct. All imports match the documented v4 API, and usage patterns (type guards withCombinedGraphQLErrors.is()andServerError.is(), SetContextLink constructor, ApolloLink.from() composition) are consistent with the migration.
Enables tests to web frontends as well
Summary by CodeRabbit
New Features
Tests
Bug Fixes
Chores
✏️ Tip: You can customize this high-level summary in your review settings.