Hey folks,
I want to be upfront about where this library sits in 2026.
user-event was built for a world where most component tests ran in jsdom. It does a great job approximating browser behavior by dispatching the right DOM events in the right order. That still matters if your tests run in jsdom/happy-dom.
But if you can run tests in a real browser, you should. The highest-fidelity "user events" are no longer something you need to simulate in userland:
- Vitest Browser Mode ships a
userEvent from vitest/browser that intentionally mirrors this library's API, but drives the browser through CDP/WebDriver instead of faking events. Vitest's own docs recommend that over @testing-library/user-event in browser mode.
- Playwright (and Playwright component testing) has first-class locator actions (
click(), fill(), press(), etc.) with auto-waiting and actionability checks. That's a different API, and for E2E/browser component tests it's usually the better tool.
What I recommend
- New browser-based tests: use Vitest's
userEvent / locators, or Playwright's locators. Don't add @testing-library/user-event there.
- Existing jsdom/RTL unit tests: this package is still a reasonable choice. No need to rip it out for its own sake.
- If you're choosing where to invest: prefer moving important interaction tests toward a real browser over deepening reliance on event simulation.
Maintenance reality
This repo is not getting active feature work. I'll still try to keep the lights on for security/release breakage when I can, but I don't want people starting new projects on the assumption that user-event is the long-term center of gravity for user interactions.
Cheers,
Kent
Hey folks,
I want to be upfront about where this library sits in 2026.
user-eventwas built for a world where most component tests ran in jsdom. It does a great job approximating browser behavior by dispatching the right DOM events in the right order. That still matters if your tests run in jsdom/happy-dom.But if you can run tests in a real browser, you should. The highest-fidelity "user events" are no longer something you need to simulate in userland:
userEventfromvitest/browserthat intentionally mirrors this library's API, but drives the browser through CDP/WebDriver instead of faking events. Vitest's own docs recommend that over@testing-library/user-eventin browser mode.click(),fill(),press(), etc.) with auto-waiting and actionability checks. That's a different API, and for E2E/browser component tests it's usually the better tool.What I recommend
userEvent/ locators, or Playwright's locators. Don't add@testing-library/user-eventthere.Maintenance reality
This repo is not getting active feature work. I'll still try to keep the lights on for security/release breakage when I can, but I don't want people starting new projects on the assumption that
user-eventis the long-term center of gravity for user interactions.Cheers,
Kent