[next] feat(vitest): migrate from jest to vitest

[raimund-schluessler]

This migrates the test runner from jest to vitest for the vue 3 next branch.

Edit: Fixed, see #4599 (comment) for details.

[raimund-schluessler]

However, there seems to be an issue with nextcloud/vite-config. With the config in place, the test runner just gives

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Error: Parse failure: Unexpected token (16:95)
At file: /@vite/env
Contents of line 16: const defines = {"globalThis.process.env.NODE_ENV": ("test"), "globalThis.process.env.": (({}).), "global.process.env.NODE_ENV": ("test"), "global.process.env.": (({}).), "process.env.": (({}).), "__VUE_OPTIONS_API__": true, "__VUE_PROD_DEVTOOLS__": false, };
 ❯ ssrTransformScript node_modules/vite/dist/node/chunks/dep-df561101.js:55343:15
 ❯ ssrTransform node_modules/vite/dist/node/chunks/dep-df561101.js:55318:12
 ❯ Object.ssrTransform node_modules/vite/dist/node/chunks/dep-df561101.js:64992:20
 ❯ ViteNodeServer._transformRequest node_modules/vite-node/dist/server.mjs:360:36
 ❯ ViteNodeServer._fetchModule node_modules/vite-node/dist/server.mjs:329:17
 ❯ MessagePort.<anonymous> node_modules/vitest/dist/vendor-index.b271ebe4.js:59:20

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

Without the config file vite.config.mts, the tests run. @susnux Do you have an idea what could be wrong?

@susnux It seems that vitest stumbles upon a dot in the vitest baseConfig. Adjusting it like this:
nextcloud-libraries/nextcloud-vite-config@10dfa94
makes the tests run. Is this dot there for a reason?

[susnux]

makes the tests run. Is this dot there for a reason?

Yes, it replaces e.g. process.env. (see the dot) with ({}].
Basically removing process.env access, I have to look a bit deeper into this as I think it only should be replaced for apps and not libraries.

[raimund-schluessler]

makes the tests run. Is this dot there for a reason?

Yes, it replaces e.g. process.env. (see the dot) with ({}]. Basically removing process.env access, I have to look a bit deeper into this as I think it only should be replaced for apps and not libraries.

Should we wait for this until we merge this PR? Or already go ahead since it seems to work for now?

[ShGKme]

I removed my review request here because I don't feel confident to take responsibility for migration to Vitest.

While it simplifies configuration by sharing Vite bundling config, works with ESM, and in some cases faster (but in some other slower because of re-initialization of each imported module in each test again), from my feelings, it's still quite a young tool with a small team. Even Vite, with all its support, still has many issues with almost every minor update.

At the same time, I don't have much experience with Vitest or its source to know its "special spots".

[ShGKme]

I removed my review request here because I don't feel confident to take responsibility for migration to Vitest.

While it simplifies configuration by sharing Vite bundling config, works with ESM, and in some cases faster (but in some other slower because of re-initialization of each imported module in each test again), from my feelings, it's still quite a young tool with a small team. Even Vite, with all its support, still has many issues with almost every minor update.

At the same time, I don't have much experience with Vitest or its source to know its "special spots".

Though @nextcloud/vue is not large and we don't have many unit tests, so, we can go back if we find many issues.

[susnux]

Though @nextcloud/vue is not large and we don't have many unit tests, so, we can go back if we find many issues.

That is true and it is a lot easier to configure, especially as dependencies move to ESM and we already getting problems with them. As we can not externalize them for CJS build. Sometime in the future we will have to ESM only too.

[raimund-schluessler]

I rebased the vite-config to the latest changes in main and switched to happy-dom. Should be good now.

I think even though vitest is still quite young, its configuration is a lot easier than for jest. If we really find an unfixable problem, we can still go back.