feat(browser): add page.route intercept support

[apple-yagi]

Description

Adds first-class network interception support to Vitest browser mode. page.route, page.unroute, and page.unrouteAll are now available to tests, piping through new RPC commands and provider hooks. The Playwright backend reuses its native routing while WebdriverIO integrates with browser.mock (BiDi) so both providers can fulfill, continue, or abort requests. Tests cover fulfill/abort flows and cleanup guarantees.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.
• Please check Allow edits by maintainers to make review process faster. Note that this option is not available for repositories that are owned by Github organizations.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[netlify]

✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	a0ffdd7
🔍 Latest deploy log	https://app.netlify.com/projects/vitest-dev/deploys/69143765a136070008bbb6bc
😎 Deploy Preview	https://deploy-preview-9011--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[sheremet-va]

Thank you for your work, but we do not plan to have support for playwright Route API. If anything, we would prefer the MSW API.

[apple-yagi]

@sheremet-va Thanks for the feedback. My thinking was that supporting the Playwright Route API would let us avoid bringing in third-party tooling like MSW and improve the developer experience. Could you explain why MSW would be preferable here? I may not fully understand Vitest’s direction, so I’d appreciate a bit more context.

[sheremet-va]

Could you explain why MSW would be preferable here? I may not fully understand Vitest’s direction, so I’d appreciate a bit more context.

I am not saying MSW would be preferable, but MSW API, if we ever implement HTTP interception. I see several reasons:

• MSW users can reuse the handlers. The convention is already to have handlers separated from MSW's createServer
• MSW API promotes the usage of standards by accepting Response and providing Request
• We already promote using MSW in the documentation and providing a different API is confusing
• MSW also exposes its primitives, so we can build on top of them

In general, we don't provide all playwright APIs, we provide APIs that we consider to be good. I really like locators, for example. But I think the route API is worse than what MSW provides.

[apple-yagi]

@sheremet-va Thank you very much for your explanation! That really helped me understand the situation. I appreciate your help. I'll go ahead and close this pull request.

[sheremet-va]

As a note, I think the interception you implemented is really good, I would just prefer if the user-facing API (page.*) would follow MSW interface

[apple-yagi]

@sheremet-va Taking the feedback into account, would it be alright if I submit another PR sometime? I’m not sure when yet, but I’d like to give it another shot.

[sheremet-va]

@sheremet-va Taking the feedback into account, would it be alright if I submit another PR sometime? I’m not sure when yet, but I’d like to give it another shot.

Yes, if you want to work on it