✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	55a96d5
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/6799555426be480008a3c9e6
😎 Deploy Preview	https://deploy-preview-7374--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.

I can't really figure out why the test fails. It seems that the fnMap in the runner gets re-inited, somehow that module is being imported twice.

But while I was creating it, the test was passing.

I haven't fully understood the logic around here, but potentially this delete task.suite might prevent what you're trying to do?

@hi-ogawa so when I just initialize the task with the suite in suite.ts, everything works in my repo. It only removes the suite if the id is '', which is fine for my use case.

I suppose the test.only errors can be disabled for linting, but linting seems to pass?

The problem is that somehow the runner support map.ts is imported twice. When I put a console.log in the module, it sometimes fires twice, and then the test functions added for getFn are undefined. When using vitest from an npm install, this doesn't happen.

@hi-ogawa oh disregard sorry, I now found the actual error you explained https://github.com/vitest-dev/vitest/actions/runs/13021120069/job/36321826300?pr=7374#step:8:226
Fixing now.

Does this support getting ancestor like test.suite.suite? This might also require assigning suite of suite early here?

@hi-ogawa I didn't look into the suite logic really. What matters is that the extendTaskContext will get the same suite name as runTask.

I couldn't easily find where the suite id gets set, isn't that known from the start?

Maybe the suite could be set in the task only if suite.name is defined?

I think there's a way to properly fix the initialization, but it might require more careful considerations (maybe something like this #7414). In the mean time, I don't mind having your use case fixed with a simple change and follow up separately. I'll check with team.

@wmertens Btw, do you have your custom runner somewhere in open source? It would be nice to know more context and concrete code if it's available.

@hi-ogawa Well, it's fully open-sourced in this PR now ;) we use it internally, because our e2e test suite does expensive initializations and we want to reuse them in subsequent tests.

For example, suppose you want to test an S3 bucket, filling it with 1000 files for various things, this runner allows you to do it in stages, skipping stages you're not testing right now etc.

I'd be happy to help make this part of the actual API as well. Another API approach would be to export a result() function and have test() return a handle:

import {it, result} from 'vitest'

const init = it('should initialize', async () => {
  const stuff = await makeStuff()
  expect(stuff.foo).toEqual(500)
  return stuff
})

it('should bar', async () => {
  const stuff = await result(init)
  await expect(stuff.doThing()).resolves.toBeTruthy()
})

you could also allow -1, -2 etc as arguments to result(), which would refer to previous tests, but that's more error prone when inserting tests.

@hi-ogawa is there anything I can do in the meanwhile?

I updated my PR and it's ready for review #7414.