feat: Upgrade vitest to 3.2.4 #628
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including You can disable this status message by setting the WalkthroughThe changes update the version of the "vitest" package from 3.0.7 to 3.2.4 in both the core packages constant and the pnpm workspace configuration. Additionally, a test file was modified to adjust type imports and assertions related to provider dependency maps without changing functionality. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
✨ Finishing Touches🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
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: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/sync/src/generators/generators.unit.test.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (9)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (CLAUDE.md)
**/*.{ts,tsx}: Import UI components from the@baseplate-dev/ui-componentspackage as shown in the provided examples.
Use both standalone and React Hook Form controller variants for form components from@baseplate-dev/ui-componentsas appropriate.
If a particular interface or type is not exported, change the file so it is exported.
**/*.{ts,tsx}: TypeScript with strict type checking
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
Files:
packages/sync/src/generators/generators.unit.test.ts
**/*.{unit,int}.test.ts
📄 CodeRabbit Inference Engine (.cursor/rules/code-style.mdc)
Unit tests use
.unit.test.tssuffix, integration tests use.int.test.ts
Files:
packages/sync/src/generators/generators.unit.test.ts
**/*.{js,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/code-style.mdc)
Node 16 module resolution - include file extensions in imports (
.js)
Files:
packages/sync/src/generators/generators.unit.test.ts
**/*.test.ts
📄 CodeRabbit Inference Engine (.cursor/rules/code-style.mdc)
Always import vitest globals explicitly (describe, it, expect)
Files:
packages/sync/src/generators/generators.unit.test.ts
**/*.{ts,tsx,js}
📄 CodeRabbit Inference Engine (.cursor/rules/code-style.mdc)
**/*.{ts,tsx,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
We use the prefer using nullish coalescing operator (??) ESLint rule instead of a logical or (||), as it is a safer operator
Use console.info/warn/error instead of console.log
Files:
packages/sync/src/generators/generators.unit.test.ts
**/*
📄 CodeRabbit Inference Engine (.cursor/rules/code-style.mdc)
Use kebab-case for file names
Files:
packages/sync/src/generators/generators.unit.test.ts
**/*.test.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/testing.mdc)
**/*.test.{ts,tsx}: Use descriptive test names that explain what is being tested
Structure tests with clear setup, execution, and verification phases (Arrange-Act-Assert)
Always mock external API calls and file system operations in tests
Each test should be independent and not rely on others
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 to keep tests simple
For file system operations in tests, use memfs and mock 'node:fs' and 'node:fs/promises'
When using globby in tests, pass the mocked fs adapter
Files:
packages/sync/src/generators/generators.unit.test.ts
**/*.{test,test-helper}.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/testing.mdc)
Extract repeated logic into reusable helper functions
Files:
packages/sync/src/generators/generators.unit.test.ts
**/*.unit.test.ts
📄 CodeRabbit Inference Engine (.cursor/rules/testing.mdc)
Unit tests are colocated with source files using
.unit.test.tssuffix
Files:
packages/sync/src/generators/generators.unit.test.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/dev-commands.mdc:0-0
Timestamp: 2025-07-22T09:11:00.767Z
Learning: Test a single file in a package using `pnpm vitest <path/to/file.unit.test.ts>`
Learnt from: kingston
PR: halfdomelabs/baseplate#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.
Learnt from: kingston
PR: halfdomelabs/baseplate#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.
Learnt from: kingston
PR: halfdomelabs/baseplate#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.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:70-79
Timestamp: 2025-05-08T12:56:11.723Z
Learning: In the check-changesets.ts script for monorepo validation, `npm pack ${pkg.name}@latest` is intentionally used to pack the most recently published version (not local changes) for comparison purposes to determine if changes require new changesets.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-07-22T09:10:31.413Z
Learning: Applies to **/*.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T09:09:23.016Z
Learning: Run `pnpm lint:affected` and `pnpm typecheck` before committing changes.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/dev-commands.mdc:0-0
Timestamp: 2025-07-22T09:11:00.767Z
Learning: Test all files in a package using `pnpm test` from within the package directory
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/dev-commands.mdc:0-0
Timestamp: 2025-07-22T09:11:00.767Z
Learning: Test a single file from the repository root using `./run-vitest.js <path/to/file.unit.test.ts>`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/dev-commands.mdc:0-0
Timestamp: 2025-07-22T09:11:00.767Z
Learning: Test affected files from the repository root using `pnpm test:affected`
packages/sync/src/generators/generators.unit.test.ts (20)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Applies to **/*.test.{ts,tsx} : Leverage TypeScript for type-safe mocking in tests
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-07-22T09:10:31.413Z
Learning: Applies to **/*.{unit,int}.test.ts : Unit tests use .unit.test.ts suffix, integration tests use .int.test.ts
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Applies to **/*.unit.test.ts : Unit tests are colocated with source files using .unit.test.ts suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-07-22T09:10:31.413Z
Learning: Applies to **/*.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Applies to **/*.test-helper.ts : Extract common setup code into test helpers, which can be new files named *.test-helper.ts
Learnt from: kingston
PR: #521
File: packages/react-generators/src/generators/admin/admin-crud-list/admin-crud-list.generator.ts:163-166
Timestamp: 2025-05-05T06:37:51.001Z
Learning: For certain templates in the codebase, the importMapProviders property is not explicitly required as the template extractor will automatically determine and infer the necessary import map providers.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.unit.test.{ts,tsx} : Unit tests are colocated with source files using .unit.test.ts suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-22T09:09:23.016Z
Learning: Applies to **/*.{ts,tsx} : If a particular interface or type is not exported, change the file so it is exported.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Refactor code to be more easily testable, such as exporting types or functions
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to src/tests/**/*.{ts,tsx} : Test helpers are located in src/tests/ directory
Learnt from: kingston
PR: #606
File: plugins/plugin-auth/src/auth/core/generators/auth-apollo/auth-apollo.generator.ts:24-32
Timestamp: 2025-07-12T19:56:08.559Z
Learning: For generator functions and configuration object methods like those in createGeneratorTask, inferred return types are acceptable when the structure is clear from the implementation. ESLint rules handle enforcement of explicit return types where truly needed, so manual review for this is not necessary.
Learnt from: kingston
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.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Applies to src/tests/**/*.ts : Test helpers are located in the src/tests/ directory
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/dev-commands.mdc:0-0
Timestamp: 2025-07-22T09:11:00.767Z
Learning: Test a single file from the repository root using ./run-vitest.js <path/to/file.unit.test.ts>
Learnt from: kingston
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.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Applies to **/*.test.{ts,tsx} : Each test should be independent and not rely on others
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/dev-commands.mdc:0-0
Timestamp: 2025-07-22T09:11:00.767Z
Learning: Test a single file in a package using pnpm vitest <path/to/file.unit.test.ts>
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Applies to **/*.{test,test-helper}.{ts,tsx} : Extract repeated logic into reusable helper functions
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Applies to src/mocks/**/*.ts : Manual mocks are in src/__mocks__/ directory
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-22T09:11:16.930Z
Learning: Applies to **/*.test.{ts,tsx} : Structure tests with clear setup, execution, and verification phases (Arrange-Act-Assert)
🧬 Code Graph Analysis (1)
packages/sync/src/generators/generators.unit.test.ts (1)
packages/sync/src/generators/generators.ts (3)
ProviderDependencyMap(40-45)InferExportProviderMap(50-54)InferDependencyProviderMap(61-67)
⏰ 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). (3)
- GitHub Check: test
- GitHub Check: Lint
- GitHub Check: Test E2E
🔇 Additional comments (3)
packages/sync/src/generators/generators.unit.test.ts (3)
8-8: LGTM! Import addition is correct.The
ProviderDependencyMaptype import is properly added and aligns with its usage in the test.
31-34: LGTM! Type definition correctly uses imported generic type.The change from interface to type alias using
ProviderDependencyMapis appropriate and maintains the same structure while leveraging the utility type.
45-48: LGTM! Type expectations correctly reflect undefined possibility.The assertion method change is consistent with the vitest upgrade, and the updated expected types with
| undefinedcorrectly align with theProviderDependencyMaptype definition that allows undefined values.
| expectTypeOf<InferredExportMap>().toMatchObjectType<{ | ||
| test: TestProvider; | ||
| config: ConfigProvider; | ||
| }>(); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the vitest API change for type assertions.
The change from toMatchTypeOf to toMatchObjectType appears to be related to the vitest upgrade. Please ensure this is the correct API method in vitest 3.2.4.
🌐 Web query:
What are the correct type assertion methods in vitest 3.2.4 for TypeScript type testing?
💡 Result:
In Vitest 3.2.4, you can perform TypeScript type assertions using the following methods:
-
expectTypeOf: This function allows you to assert the type of a value.-
Usage:
import { expectTypeOf } from 'vitest'; expectTypeOf(value).toEqualTypeOf<ExpectedType>(); expectTypeOf(value).toMatchTypeOf<ExpectedType>();
-
Matchers:
toEqualTypeOf: Asserts that the value's type is exactly equal to the expected type.toMatchTypeOf: Asserts that the value's type matches the expected type, allowing for structural compatibility.
-
Example:
import { expectTypeOf } from 'vitest'; const num = 42; expectTypeOf(num).toEqualTypeOf<number>(); expectTypeOf(num).toMatchTypeOf<number | string>();
-
-
assertType: This function is used to assert that a value matches a specific type.-
Usage:
import { assertType } from 'vitest'; assertType<ExpectedType>(value);
-
Example:
import { assertType } from 'vitest'; const str = 'Hello, world!'; assertType<string>(str);
-
To enable type checking during your tests, ensure you run Vitest with the --typecheck flag:
vitest --typecheckThis setup will allow you to perform type assertions effectively in your TypeScript tests using Vitest.
Citations:
- 1: https://vitest.dev/api/expect-typeof.html?utm_source=openai
- 2: https://v0.vitest.dev/api/assert-type.html?utm_source=openai
Fix incorrect Vitest matcher in type assertion
Vitest 3.2.4’s expectTypeOf API does not include toMatchObjectType. To assert structural compatibility, use toMatchTypeOf (or toEqualTypeOf for exact matches).
• File: packages/sync/src/generators/generators.unit.test.ts
Lines 38–41:
- expectTypeOf<InferredExportMap>().toMatchObjectType<{
- test: TestProvider;
- config: ConfigProvider;
- }>();
+ expectTypeOf<InferredExportMap>().toMatchTypeOf<{
+ test: TestProvider;
+ config: ConfigProvider;
+ }>();📝 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.
| expectTypeOf<InferredExportMap>().toMatchObjectType<{ | |
| test: TestProvider; | |
| config: ConfigProvider; | |
| }>(); | |
| expectTypeOf<InferredExportMap>().toMatchTypeOf<{ | |
| test: TestProvider; | |
| config: ConfigProvider; | |
| }>(); |
🤖 Prompt for AI Agents
In packages/sync/src/generators/generators.unit.test.ts at lines 38 to 41,
replace the incorrect Vitest matcher `toMatchObjectType` with the correct
matcher `toMatchTypeOf` to properly assert structural compatibility using the
`expectTypeOf` API.
Summary by CodeRabbit