vitest browser mode or just more playwright specs, 2 devs one repo Playwright

Split by failure mode rather than by tool.

Component tests catch "this combination of props renders wrong". E2E catches "this button is wired to the wrong action". Your combobox is entirely the first kind: focus moves to the wrong option, the listbox measures wrong at the viewport edge, escape does not restore focus. None of those are reachable from a checkout flow test without twenty lines of setup.

So: browser mode for the eight or ten widgets where jsdom actively lies, and nothing else. Do not migrate the 400 unit tests. Pure logic in jsdom is fine and it is fast.

We did the "Playwright against a component route" thing for about eighteen months. It works. Two things eventually pushed us off it:

• roughly 700ms per spec versus 90ms, and it compounds
• you cannot assert on props or callbacks, so you end up asserting on data-testid soup that exists purely for the test

If the browsers are already installed for your e2e suite, browser mode is a much smaller step than it looks from the outside. Same locators, same trace viewer.

Contrarian data point: we deleted about 200 component tests and our production bug rate did not move. What did change is that a redesign stopped costing two days of test edits, because most of those tests asserted on markup rather than behaviour.

For a two person team, e2e over the five flows that make money plus unit tests over the pure logic is a defensible whole strategy. Add component tests for the specific widgets that keep breaking, not as a layer.

Whatever you choose: one runner, one command. Two test commands is fine. Three configs is where a two person team quietly starts skipping the one that is red.

Playwright does have its own component testing but it has been experimental for a long time and I would not build a small team's daily workflow on it right now.