react-testing-library accepts some of these options directly: https://testing-library.com/docs/react-testing-library/api . Should we do the same? What are your thoughts, @hi-ogawa, @nstepien? It might just be outdated, and we can improve here or follow the same pattern

Documentation at vitest.dev should also be updated: https://github.com/vitest-dev/vitest/blob/main/docs/api/browser/react.md

Ah good catch. I didn't check what testing library did. I vote for aligning with them if no obvious reason to diverge.

RTL only supports onCaughtError and onRecoverableError (source), so there's some divergence already.

I think a separate object is better:

• it avoids conflicting names if vitest-browser-react or React add more options in the future
• it's obvious which options control vitest-browser-react, and which options control React
• it helps discover what options are offered IMO
• it's easier to add more options for other stuff that render handles for us
  • for example if React adds new props to StrictMode, it'd be trivial to add { strictModeProps }
  • otherwise destructuring all the options would need to be done carefully, it'd add to the lib's maintenance, and users couldn't make use of new React options as soon as they're available

Those are my thoughts, I can flatten the options if you insist. 👍

Tangentially, maybe vitest-browser-react will allow testing SSR via hydrateRoot in the future.
hydrateRoot has the same options, at least as of writing.
Would the API be similar?

await page.hydrate(<div />, {
  hydrateRootOptions: {}
})