Migrate from jest to vitest and stop using jsdom based tests

[AbhiPrasad]

After v8 gets merged in, let's look at migrating from jest to vitest. vitest is way faster, and doesn't fall into the same traps jest does in terms of esm compatibility. Example attempt with Vue SDK: #11071

In addition, we should stop using jsdom based tests, and instead move tests that rely on the browser to use playwright instead. Simulating jsdom in an node environment always has it's faults, easier to not attempt to do that.

First we should align on a common vitest testing standard. Right now we use set globals via vitest/globals, but this is not recommended by vitest themselves. We should instead use direct imports like import { describe, test, expect } from 'vitest';.

sentry-javascript/tsconfig.dev.json

Line 8 in 780875f

"types": ["node", "jest", "vitest/globals"]

There's probably some other discussion that needs to be done here too. We can validate our decisions by changing our vitest usage in the Astro and SvelteKit SDKs.

Update existing vitest usage

Preview Give feedback

1. test(astro): Switch to explicit vitest imports #13093
   +0
   
2. test(nestjs): Switch to explicit vitest imports #13214
   +0
   
3. Nuxt SDK
4. test(solid): Switch to explicit vitest imports #13028
   +0
   
5. SolidStart SDK
6. test(svelte): Switch to explicit vitest imports #13026
   +0
   
7. test(sveltekit): Switch to explicit vitest imports #12960
   +0
   
8. test(replay): Switch to explicit vitest imports #13027
   +0
   

We can then tackle the following list in whatever order we want!

Convert to using vitest

Preview Give feedback

1. Angular feat(v8/angular): Merge angular and angular-ivy packages and start Angular support at v14 #11091
2. test(browser): Switch from jest to vitest #13092
   +0
   
3. Switch to vitest in @sentry/core #13434
   Migrated +1
   
4. Browser Utils
5. test(feedback): Migrate from jest to vitest #15497
   +0
   
6. test(gatsby): Migrate to vitest #15494
   +0
   
7. test(node): Switch from Jest to vitest #13605
   +0
   
8. test(react): Migrate to vitest #15492
   +0
   
9. test(replay-canvas): Switch to using vitest #12964
   +0
   
10. feat(replay): Use vitest instead of jest #11899
    +0
11. test(replay): Switch to using vitest for replay worker #12961
    +0
    
12. test(vercel-edge): Switch to using vitest #12958
    +0
    
13. test(vue): Switch to using vitest #12955
    +0
    
14. Wasm
15. test(node-integration): Migrate to Vitest #15499
    +0
16. test(nextjs): Migrate to Vitest #15546
    +0

We also have some packages that use mocha. We should try to drop that dependency and make them use vitest

Remove mocha

Preview Give feedback

1. ref(eslint): Remove mocha #11296
   +0
   
2. test: Port captureException and captureMessage tests from karma runner #11412
   +0
   
3. test: Port breadcrumb tests from karma runner #11436
   +0
   
4. test: Port ignoreErrors and denyUrls tests from karma runner #11449
   +0
   
5. test: Port onerror tests to playwright #11666
   +0
   
6. test: Port loader tests from karma to playwright #11688
   +0
   
7. test(browser): Port builtin tests to playwright #11733
   +0
   
8. test(browser): Port unhandledrejection tests to playwright #11758
   +0
   

[AbhiPrasad]

ref #6040

[s1gr1d]

vistest was already added to Angular here: #11091
I will check it on the list 👍🏻

[billyvg]

@AbhiPrasad Replay was migrated here: #11899

edit though we are using globals and not importing everything from vitest

[timfish]

Looks like the task list needs updating because Node v14 doesn't support vitest?

[AbhiPrasad]

I updated it - looks like we are stuck with jest longer than I thought.

[timfish]

Almost everything is now migrated to Vitest.

There are a couple of packages where I've created branches to migrate them but got stuck on some blockers:

@sentry/remix

Branch - https://github.com/getsentry/sentry-javascript/tree/timfish/test/vitest-remix

• upload-sourcemaps.test.ts tests the the files in ./scripts/** which are all CJS and Vitest cannot not mock require so they can't be tested directly with Vitest

Maybe these files should be in TypeScript and transpiled to the output directory anyway?

@sentry/google-cloud-serverless

Branch - https://github.com/getsentry/sentry-javascript/tree/timfish/test/vitest-google

• google-cloud-grpc.test.ts test fails with UNAUTHENTICATED: Request had invalid authentication credentials
• Looks like dns isn't getting mocked because it hits Google and gets an auth error?

@sentry/nextjs

Branch - https://github.com/getsentry/sentry-javascript/tree/timfish/test/vitest-nextjs

• constructWebpackConfig.test.ts failures because mocks don't appear to be working and other strange behaviour

[AbhiPrasad]

upload-sourcemaps.test.ts tests the the files in ./scripts/** which are all CJS and Vitest cannot not mock require so they can't be tested directly with Vitest

maybe you can try the hack I added for gatsby that patches Module.load to do CJS patching:

sentry-javascript/packages/gatsby/test/gatsby-node.test.ts

Lines 3 to 28 in ba4586f

	vi.hoisted(
	() =>
	void mock('@sentry/webpack-plugin', {
	sentryWebpackPlugin: vi.fn().mockReturnValue({}),
	}),
	);
	// Need to override mock because `gatsby-node.js` loads `@sentry/webpack-plugin` as a CJS file.
	async function mock(mockedUri: string, stub: any) {
	const { Module } = await import('module');
	// @ts-expect-error test
	Module._load_original = Module._load;
	// @ts-expect-error test
	Module._load = (uri, parent) => {
	if (uri === mockedUri) return stub;
	// @ts-expect-error test
	return Module._load_original(uri, parent);
	};
	}
	import { onCreateWebpackConfig } from '../gatsby-node';
	describe('onCreateWebpackConfig', () => {
	// eslint-disable-next-line @typescript-eslint/no-var-requires
	const { sentryWebpackPlugin } = require('@sentry/webpack-plugin');

Looks like dns isn't getting mocked because it hits Google and gets an auth error?

These tests are so hard to debug 😬

I'd be open to try to just completely rewrite them.

constructWebpackConfig.test.ts failures because mocks don't appear to be working and other strange behaviour

let's open a draft PR for this one, we can ask Luca and Charly to help take a look given they have more experience with these tests.