Implement module mocking in browser mode

[christian-bromann]

Describe the bug

The following test:

import { test, vi } from 'vitest'
import { v4 } from 'uuid'

vi.mock('uuid', () => ({
    v4: 'I am mocked'
}))

test('I live in the browser', () => {
    console.log('YES', window.navigator.userAgent, v4)
})

throws an error:

 FAIL  tests/browser.test.js [ tests/browser.test.js ]
TypeError: this._mocker.queueMock is not a function
 ❯ VitestUtils.mock http:/localhost:63315/node_modules/.vite/deps/chunk-DGJ3HNQR.js?v=22cddd7a:10193:18
 ❯ http:/localhost:63315/private/tmp/vitestbrowser/tests/browser.test.js?v=1679345265563:4:4

Reproduction

see above

System Info

System:
    OS: macOS 12.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 420.98 MB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 18.7.0 - ~/.nvm/versions/node/v18.7.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.7.0/bin/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v18.7.0/bin/npm
  Browsers:
    Brave Browser: 111.1.49.120
    Chrome: 111.0.5563.64
    Firefox: 109.0
    Firefox Nightly: 111.0a1
    Safari: 15.2
  npmPackages:
    @vitest/browser: ^0.29.7 => 0.29.7
    vitest: ^0.29.7 => 0.29.7

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sheremet-va]

Mocking in the browser is not supported yet.

[christian-bromann]

Mocking in the browser is not supported yet.

Yes, I remember reviewing the original PR that landed the browser runner. My suggestion then would be to throw a more meaningful error for users.

[lmiller1990]

@sheremet-va have you got any ideas on how best to support browser ESM mocks? We are working on something similar at Cypress for our cypress/vite-dev-server: cypress-io/cypress#22355.

Maybe we can collaborate and solve ESM mocks in the browser for both Vitest and Cypress. We can put some time and effort into contributing to both Cypress and Vitest, and Vite/esbuild if needed, to get this moving.

[sheremet-va]

have you got any ideas on how best to support browser ESM mocks?

Module mocking is already implemented in webdriverio, as far as I understand. I took a brief glance at the code, and the idea seems solid, but we will probably need to make some adjustments:

• move vi.mock to the top
• rewrite spec static imports into dynamic ones, so vi.mock is called before all imports
• when vi.mock is called, send a request to the server asking it to wait for the factory to resolve
• when the factory is resolved, send returned keys to the server, so we can generate a new module (see later)
• rewrite mock imports into /@mock/\id?spec= for better caching on Vite side(?)
• when mock is imported, generate something like

  export const name = __hiddenMockState['path']['name']`

But this is about module mocking with a factory/automock. To support stub(esmModule, 'namedExport'), we will probably need to rewrite imports into something like this:

import { name } from './some-path.js'
const { something } = await import('./some-path.js')

// ->

import * as __vite_import_1__ from './some-path.js'
const { name } = __vitestModule(__vite_import_1__)

const { something } = __vitestModule(await import('./some-path.js'))

Where __vitestModule is implemented as a module accessor.

const modulesCache = new WeakMap()
function __vitestModule(module) {
  if (!modulesCache.has(module)) {
    // so ESM module loses restrictions
    modulesCache.set(module, Object.assign({}, module))
  }
  return modulesCache.get(module)
}

This is what Vite already does for optimized dependencies and for SSR.

[lmiller1990]

Gotcha... this is pretty much in line with what I was expecting for implementing this in Vitest.

Module mocking is already implemented in webdriverio, as far as I understand.

I haven't seen how they handle this, will take a look.

I saw another non-runner specific way, using importmaps. You then just combine with something like sinon. Also looking to do some exploration around this - a non-runner specific solution sure would be nice.

[sheremet-va]

a non-runner specific solution sure would be nice

It would be nice, but I don't think it's possible to make it work with the same API Vitest has, unfortunately. The general solution is not DX-friendly.

[marpme]

To summarize it: the current workaround for mocking or spying in vitest with browser mode enabled is to use libraries like sinon.js until the official implementation is done.

or do you see any other alternatives to this?

[sheremet-va]

To summarize it: the current workaround for mocking or spying in vitest with browser mode enabled is to use libraries like sinon.js until the official implementation is done.

or do you see any other alternatives to this?

vi.spyOn and vi.fn work as usual. Sinon also cannot spy on module exports (no library can).

[marpme]

vi.spyOn and vi.fn work as usual. Sinon also cannot spy on module exports (no library can).

Fair point, I was under the impression that those functionalities would also be impacted by this missing implementation. Thank you for further clarifying 🥇

[lmiller1990]

We looked into this more at Cypress and arrived at a similar conclusion - the whole "ESM mocking" is hard to solve generally. We will solve it for Vite and webpack via a plugins, I will link the code here once we write it, maybe we can collaborate with the Vitest team to build a general vite-plugin-esm-mocks plugin, or something to that meaning.

[Aslemammad]

@lmiller1990 I believe it'd be a nice idea, so other libraries and applications can use it easily.

[kettanaito]

Just a quick plug here that in ESM, importing modules is fetching them via HTTP, and you can use libraries like MSW to intercept module requests and respond to them with whichever application/javascript response you want.

cc @sheremet-va

[sheremet-va]

Just a quick plug here that in ESM, importing modules is fetching them via HTTP, and you can use libraries like MSW to intercept module requests and respond to them with whichever application/javascript response you want.

cc @sheremet-va

Hm, this might actually be easier than the current implementation 🤔 The current one also doesn't work if you import original module that imports itself somewhere in the import chain, but we can bypass that with MSW maybe 🤔

[christian-bromann]

I've I would would have just known about MSW earlier in my life 😭 this is amazing!

[kettanaito]

@sheremet-va, feel free to add me to reviewers if you ever decide to give MSW a shot in module mocking. I will be happy to help you spot mistakes and suggest improvements.

@christian-bromann, but you've discovered it now, and that all that matters! ❤️

[sheremet-va]

feel free to add me to reviewers if you ever decide to give MSW a shot in module mocking. I will be happy to help you spot mistakes and suggest improvements.

The first version is already implemented (and merged) here: #5853
It is a bit hard to review without the knowledge of how internals work, but you can give it a look 😄 I did not look into how this would work with custom service workers yet.