Migrate to Vitest #260
Migrate to Vitest #260
Conversation
|
👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎ This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. Ignoring: Next stepsTake a deeper look at the dependencyTake a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev. Remove the packageIf you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency. Mark a package as acceptable riskTo ignore an alert, reply with a comment starting with |
src/index.test-d.ts
Outdated
There was a problem hiding this comment.
This file demonstrates that Vitest has support for type tests out of the box. I figured it may be helpful to make developers aware of this.
| @@ -1,6 +1,8 @@ | |||
| import { describe, it, expect } from 'vitest'; | |||
There was a problem hiding this comment.
Vitest doesn't inject globals like describe, it, expect by default. We could enable a setting for this, but I think importing is preferred over using globals.
There was a problem hiding this comment.
Since Vite uses esbuild under the hood, tests aren't type checked by default. Using a separate tsconfig seemed to be the most reliable way to get type checking and tests working.
For example, if a test in a test-d.ts file fails, Vitest outputs the following error:
FAIL src/index.test-d.ts > greeter > returns a string
TypeCheckError: Type 'number' does not satisfy the constraint '"Expected number, Actual string"'.
❯ src/index.test-d.ts:7:49
5| describe('greeter', () => {
6| it('returns a string', () => {
7| expectTypeOf(greeter('Huey')).toEqualTypeOf<number>();
| ^
8| });
9| });
And type errors in regular test files are detected as well, as unhandled source errors:
TypeCheckError: Type 'string' is not assignable to type 'number'.
❯ src/index.test.ts:7:11
5| describe('greeter', () => {
6| it('greets', () => {
7| const name: number = 'Huey';
| ^
8| const result = greeter(name);
9| expect(result).toBe('Hello, Huey!');
| "skipLibCheck": true, | ||
| "skipDefaultLibCheck": true, |
There was a problem hiding this comment.
Vite's own declarations seem to rely on "dom" types. I don't think we should worry about Vite's declarations, and we can simply ignore checking those. These two options potentially speed up type checking slightly as well.
|
@SocketSecurity ignore npm/tinypool@1.0.2 These are expected to use @SocketSecurity ignore npm/esbuild@0.25.0 Network access is ok. Esbuild uses network access to download the right binary version depending on the platform. @SocketSecurity ignore npm/istanbul-lib-report@3.0.1 New author is ok. |
| "forceConsistentCasingInFileNames": true, | ||
| "lib": ["ES2023"], | ||
| "module": "ES2022", | ||
| "moduleResolution": "Bundler", |
| @@ -0,0 +1,19 @@ | |||
| { | |||
| "compilerOptions": { | |||
There was a problem hiding this comment.
Is it worth extending from tsconfig.json?
| "esModuleInterop": true, | ||
| "exactOptionalPropertyTypes": true, | ||
| "forceConsistentCasingInFileNames": true, | ||
| "lib": ["ES2023"], |
There was a problem hiding this comment.
Where does ES2023 come from, and why does module use a different number?
This replaces Jest with Vitest. Vitest has better support for ESM (which we use in some repositories), works with Prettier 3, and generally "just works," without too much additional configuration.
Examples
We are using Vitest in a few repos, including:
ocap-kernelcreate-release-pr: Migrate to Vitest create-release-branch#167