Migrate to Vitest

[Mrtenz]

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-kernel
• create-release-pr: Migrate to Vitest create-release-branch#167

[socket-security]

Report too large to display inline

View full report↗︎

[socket-security]

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert	Package	Note	Source	CI
Network access	npm/[email protected]	Module: net Location: Package overview	package.json yarn.lock	🚫
Network access	npm/[email protected]	Module: http Location: Package overview	package.json yarn.lock	🚫
Shell access	npm/[email protected]	Module: child_process Location: Package overview	package.json yarn.lock	🚫
Network access	npm/[email protected]	Module: https Location: Package overview	package.json yarn.lock	🚫
Network access	npm/[email protected]	Module: tls Location: Package overview	package.json yarn.lock	🚫

Ignoring: npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected]

View full report↗︎

Next steps

What is network access?

This module accesses the network.

Packages should remove all network access that is functionally unnecessary. Consumers should audit network access to ensure legitimate use.

What is shell access?

This module accesses the system shell. Accessing the system shell increases the risk of executing arbitrary code.

Packages should avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced.

Take a deeper look at the dependency

Take 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 package

If 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 risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/[email protected] or ignore all packages with @SocketSecurity ignore-all

• @SocketSecurity ignore npm/[email protected]

[Mrtenz]

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.

[mcmire]

Yeah this is amazing, I had no clue!

[Mrtenz]

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.

[mcmire]

Agreed!

[Mrtenz]

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!');

[mcmire]

Great!

[Mrtenz]

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.

[Mrtenz]

@SocketSecurity ignore npm/[email protected]
@SocketSecurity ignore npm/[email protected]

These are expected to use child_process as they are used by Vitest.

@SocketSecurity ignore npm/[email protected]

Network access is ok. Esbuild uses network access to download the right binary version depending on the platform.

@SocketSecurity ignore npm/[email protected]

New author is ok.

[mcmire]

This looks good, I just had a few questions.

[mcmire]

@Mrtenz I'm seeing a peer dep warning when installing dependencies, is this important?

@metamask/metamask-module-template@workspace:. doesn't provide @typescript-eslint/utils (pdb740), requested by @vitest/eslint-plugin.

[Mrtenz]

@Mrtenz I'm seeing a peer dep warning when installing dependencies, is this important?

@metamask/metamask-module-template@workspace:. doesn't provide @typescript-eslint/utils (pdb740), requested by @vitest/eslint-plugin.

It's installed regardless by other dependencies, but if it's a peer dependency, it makes sense to explicitly add it. We should update the installation instructions in eslint-config to mention this.

[mcmire]

Looks good!

[mcmire]

This reminds me, we need to convert this file YAML so we can add comments to this file.

[Mrtenz]

Sounds good, but out of scope for this PR

[mcmire]

Of course, I meant to say that. I created a ticket here: #265