createTaskCollector behaves differently when using .each in version 1.3.0

[gudleik]

Describe the bug

Using createTaskCollector, the argument order is different in version 1.3.0 when using test.each() and test().
From custom.test.ts in the reproduction example (see link below):

// copied from https://vitest.dev/advanced/runner.html#your-task-function
export const test = createTaskCollector(function (
  this: any,
  name,
  fn,
  options
) {
  console.dir(
    {
      name,
      fn,
      options,
    },
    { showHidden: true, depth: null }
  );

  getCurrentSuite().task(name, {
    ...this, // so "todo"/"skip"/... is tracked correctly
    meta: {
      customPropertyToDifferentiateTask: true,
    },
    handler: async (...args: any[]) => {
      return fn.apply(this, args);
    },
    options,
  });
});

test('test', () => {
  expect(true).toBe(true);
});

test.each([true, false] as const)('test.each', (bool) => {
  expect(bool).toBe(bool);
});

The output from console.dir:

{
  name: 'test',
  fn: [Function (anonymous)] { [length]: 0, [name]: '' },
  options: undefined
}
{
  name: 'test.each',
  fn: {},
  options: [Function (anonymous)] { [length]: 0, [name]: '' }
}
{
  name: 'test.each',
  fn: {},
  options: [Function (anonymous)] { [length]: 0, [name]: '' }
}

This works fine in version 1.2.2

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-gxa45z?file=test%2Fcustom.test.ts

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.18.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.14.0 - /usr/local/bin/pnpm
  npmPackages:
    @vitest/ui: 1.3.0 => 1.3.0 
    vite: latest => 5.1.3 
    vitest: 1.3.0 => 1.3.0

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]

The order was changed in #5142, but I guess we can keep the old order for the collector (it's not the public order) for now since it looks like a breaking change 🤔

[JCMais]

so, any change was made to keep this on the same order? 🤔