fix(browser): fix mocking from outside of root

[hi-ogawa]

Description

• Closes vi.mock not working in browser mode with test files outside of root #7595

It seems like a very odd use case to call vi.mock from outside of root, but join(root, importer) also felt a bit odd. Not sure when that happens. If this is necessary, then we could also call another resolveId to resolve importer itself. (Well, it looks like this happens with custom mock server usage like in teste/public-mocker.)

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.

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	fde59e5
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/67ee52e4aa28a000082fe88e
😎 Deploy Preview	https://deploy-preview-7789--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 site configuration.

[sheremet-va]

the current logic is that if it doesn't start with root, then it's /relative-from-root.js, so we can safely just join them. The resolveId here seems over complicated, importer should always be resolved/partially resolved

I assume importer here has /@fs/ or something (this is what vite does to files outside of root), so we can just strip it

[hi-ogawa]

I assume importer here has /@fs/ or something (this is what vite does to files outside of root), so we can just strip it

This wasn't the case since normal usages (other than public-mocker test) already has fully resolved absolute path (i.e. resolved id), for example on test/browser/fixtures/mocking-out-of-root test case:

root: (abs-path)/project1
id: (abs-path)/project3/lib.js
importer: (abs-path)/project3/index.js

This wasn't about /@fs, which is already stripped out during getImporter and stack trace parsing:

vitest/packages/utils/src/source-map.ts

Lines 69 to 72 in eeded51

	if (url.startsWith('/@fs/')) {
	const isWindows = /^\/@fs\/[a-zA-Z]:\//.test(url)
	url = url.slice(isWindows ? 5 : 4)
	}

Non fully resolved id only happend for public-mocker test which doesn't have the same logic. Alternative is to add extra mocker option to applying joining only for public-mocker usage.

[hi-ogawa]

Alright, I just realized project root path is not only public-mocker test, for example test/browser/fixtures/mocking-out-of-root/project1/imported-test.js:

{ rawId: './lib.js', importer: '/imported-test.js' }

We'll need to somehow tell mocker about whether (abs-path)/project3/index.js was originally with /@fs or not, so we can skip the joining.

[hi-ogawa]

I still think this extra resolveId is also fine. If you know other idea, I would be happy to hear.

[sheremet-va]

And I still think resolveId is overkill because we know exactly how this value is resolved already. Maybe we can just check moduleGraph.getByUrl and return the module.file if it exists, with a fallback to importer without joining