Interesting point, but I wonder what is the point of setting esbuild to es5 in Vitest since we don't even support any runtimes with that target (the lowest we support is Node18 which is way ahead of es5). Maybe in our case we can forcefully set it higher 🤔

@sheremet-va
Note that this is about using esbuild target ES2015, not ES5.

But a valid case would be that the user uses Angular with vitest.

Angular can not use async/await natively if zone.js is used
https://angular.dev/guide/experimental/zoneless#why-use-zoneless

ZoneJS works by patching browser APIs but does not automatically have patches for every new browser API. Some APIs simply cannot be patched effectively, such as async/await, and have to be downleveled to work with ZoneJS.

In this case the user must set esbuild to ES2015, ES2016 (or esbuild.supported.['async-await'] = false), but for any of those settings, fixture don't work anymore as reproduced above, as the following regex won't match:

Edit the following config also won't work with fixtures:

    target: 'ES2015',
    // OR
    target: 'ES2016',
    // OR
    supported: {
      'async-await': false,
    }

That being said, angular is moving away from Zone.js for those kind of reasons.
And you can already disable zoneless.js:
https://angular.dev/guide/experimental/zoneless

Then I think we can just support esbuild's __async output in the regexp since we know esbuild is the compiler.

@hi-ogawa Thanks for working on this!

I tried it out, but there are still cases that break. For example, async method() syntax gives an error:

const test = base.extend<Fixture>({
  simple: async ({}, use) => {
    await use("simple");
  },
  async method ({ simple }, use) {
    await use("method:" + simple);
  },
});

Error: The first argument inside a fixture must use object destructuring pattern, e.g. ({ test } => {}). Instead, received "_0".
    at getUsedProps (file:///Users/kasperpeulen/code/github/vitest/packages/runner/dist/index.js:247:11)
    at file:///Users/kasperpeulen/code/github/vitest/packages/runner/dist/index.js:119:25
    at Array.forEach (<anonymous>)
    at mergeContextFixtures (file:///Users/kasperpeulen/code/github/vitest/packages/runner/dist/index.js:117:16)
    at Function.taskFn.extend (file:///Users/kasperpeulen/code/github/vitest/packages/runner/dist/index.js:667:22)
    at /Users/kasperpeulen/code/github/vitest/test/config/fixtures/fixture-no-async/basic.test.ts:9:19
    at VitestExecutor.runModule (file:///Users/kasperpeulen/code/github/vitest/packages/vite-node/dist/client.mjs:399:5)
    at VitestExecutor.directRequest (file:///Users/kasperpeulen/code/github/vitest/packages/vite-node/dist/client.mjs:381:5)
    at VitestExecutor.cachedRequest (file:///Users/kasperpeulen/code/github/vitest/packages/vite-node/dist/client.mjs:206:14)
    at VitestExecutor.executeId (file:///Users/kasperpeulen/code/github/vitest/packages/vite-node/dist/client.mjs:173:12)

@kasperpeulen Hmm, interesting. I thought we only supported arrow functions for fixtures, so haven't considered that case.

I've only seen arrow functions, but the doc has this too https://vitest.dev/guide/test-context.html#fixture-initialization, which probably also breaks. Let me check it again.