test(vapor): use browser mode instead of pupeteer to run tests

[sheremet-va]

This PR rewrites the tests for Vue Vapor mode to use Vitest Browser Mode. The logic of the test stayed the same, although it maybe also good to rewrite some of it or split it into separate tests. There are no big noticeable changes in speed.

Happy to get any feedback.

If there is desire, I can also update older e2e tests.

Running tests with --browser.headless=false also shows Vitest UI:

[coderabbitai[bot]]

[!IMPORTANT]

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions[bot]]

Size Report

Bundles

File	Size	Gzip	Brotli
compiler-dom.global.prod.js	85.2 kB	29.9 kB	26.4 kB
runtime-dom.global.prod.js	108 kB	40.5 kB	36.5 kB
vue.global.prod.js	166 kB	60.5 kB	53.9 kB

Usages

Name	Size	Gzip	Brotli
createApp (CAPI only)	48.2 kB	18.8 kB	17.2 kB
createApp	57.2 kB	22 kB	20.1 kB
createApp + vaporInteropPlugin	96 kB	35.4 kB	32 kB
createVaporApp	42 kB	15.5 kB	14.1 kB
createSSRApp	61.6 kB	23.8 kB	21.7 kB
defineCustomElement	63.3 kB	23.8 kB	21.7 kB
overall	71.9 kB	27.2 kB	24.8 kB

[pkg-pr-new[bot]]

Open in StackBlitz

@vue/compiler-core

npm i https://pkg.pr.new/@vue/compiler-core@13934

@vue/compiler-dom

npm i https://pkg.pr.new/@vue/compiler-dom@13934

@vue/compiler-sfc

npm i https://pkg.pr.new/@vue/compiler-sfc@13934

@vue/compiler-ssr

npm i https://pkg.pr.new/@vue/compiler-ssr@13934

@vue/compiler-vapor

npm i https://pkg.pr.new/@vue/compiler-vapor@13934

@vue/reactivity

npm i https://pkg.pr.new/@vue/reactivity@13934

@vue/runtime-core

npm i https://pkg.pr.new/@vue/runtime-core@13934

@vue/runtime-dom

npm i https://pkg.pr.new/@vue/runtime-dom@13934

@vue/runtime-vapor

npm i https://pkg.pr.new/@vue/runtime-vapor@13934

@vue/server-renderer

npm i https://pkg.pr.new/@vue/server-renderer@13934

@vue/shared

npm i https://pkg.pr.new/@vue/shared@13934

vue

npm i https://pkg.pr.new/vue@13934

@vue/compat

npm i https://pkg.pr.new/@vue/compat@13934

commit: 8da4595

[edison1105]

I've actually been planning to switch e2e tests to vitest browser mode too, but I haven't done it yet since vitest browser mode is still experimental. I have a question: after switching to vitest browser mode, does the e2e test execution time increase or decrease? If the difference isn't too significant, I think this PR is worthwhile.

[sheremet-va]

have a question: after switching to vitest browser mode, does the e2e test execution time increase or decrease? If the difference isn't too significant, I think this PR is worthwhile.

The time is unpredictable with the previous approach for me, the first time it's ~2s, the second time ~1,5s. The browser mode runs for 2s (the MVC test is always 1,5s unlike with pupeteer where it's either 1,5s or 700ms). I think it might be because the previous setup was modifying the DOM directly (by setting input.value or doing a element.click() instead of using CDP which is slower). If we keep the previous implementation, I think the time will be the same, if not a little bit faster.

[edison1105]

@sheremet-va Sounds good to me. Let's move all e2e tests to vitest browser mode.

[sheremet-va]

I will come back to this PR at some point. @edison1105 right now I am struggling with running unit tests in Vitest beta. It seems like BaseTransition.spec.ts is failing with the latest version (it's not the only test that fails) and I am not sure why. It seems like something was introduce in Vitest (probably related to spying) that is causing this. Can you help me debug it?

[edison1105]

@sheremet-va I'll take a look later

[sheremet-va]

The main issue I am having with VItest 4 is that unit tests are failing. Did you have a loot at them yet, @edison1105?

[edison1105]

@sheremet-va

// in vitest 3.2.4
const hook = vi.fn((el, done) => {})
test('hook length', () => {
  expect(hook.length).toBe(2) // true
})

// in vitest 4.x
const hook = vi.fn((el, done) => {})
test('hook length', () => {
  expect(hook.length).toBe(2) // should be 2 but got 0
})

The above difference is the cause of the BaseTransition.spec.ts failed. Internally, Transition uses hook.length to determine whether the animation has ended. If hook.length <= 1, done will be called.

https://github.com/vuejs/core/blob/45547e69b25baa99a0ed52ba5110c5bd8b4a35e4/packages/runtime-core/src/components/BaseTransition.ts#L360-L371

---

Another test case (componentPublicInstance.spec.ts:348:28) failed. Simply change the 4 to 3. Refer to the comments in L344. (It equals 3 in jest) - You already fixed it via https://github.com/vuejs/core/pull/13934/commits/7e56f8d045b2334bee9b63ab5c210cb400ba12da. https://github.com/vuejs/core/blob/45547e69b25baa99a0ed52ba5110c5bd8b4a35e4/packages/runtime-core/tests/componentPublicInstance.spec.ts#L344-L348

[sheremet-va]

Another test case (componentPublicInstance.spec.ts:348:28) failed. Simply change the 4 to 3. Refer to the comments in L344. (It equals 3 in jest) - You already fixed it via 7e56f8d.

That one is an expected breaking change, yeah.

The above difference is the cause of the BaseTransition.spec.ts failed. Internally, Transition uses hook.length to determine whether the animation has ended. If hook.length <= 1, done will be called.

Thank you so much for investigating, this is indeed a bug in Vitest!