Clear and concise description of the problem

Right now, I have an async function that I use to create and start a server:

async function startServer(port) {
  // ...
}

Within a test file, I have a setup that looks something like this

describe("Description", () => {
  let server: Awaited<ReturnType<typeof startServer>>;

  beforeAll(async () => {
    server = await startServer(port);
  });

  afterAll(() => {
    server.close();
  });

  // ...
});

For brevity, I'd like to write my code like this instead:

describe("Description", () => {
  let server: Awaited<ReturnType<typeof startServer>>;

  beforeAll(async () => (server = await startServer(port)));
  afterAll(() => server.close());
  // ...
});

But I can't, because the current types for before*/after* forbid returning an actual value.

Suggested solution

It would be great if these return types (for before* and after*) could be updated so that developers could shorthand their setup/teardown blocks. For simple setup/teardown steps, this would reduce the lines of code by 2 per function call (assuming a formatter like Prettier is being used).

Alternative

Currently, developers can circumvent the problem by using void. But the appearance of this operator in a codebase is usually considered a smell.

Additional context

I think that this change would make Vitest "more compatible" with Jest users (from a TypeScript perspective). However, I noticed from the docs that beforeAll accepts a cleanup function. So if this feature request was accepted, there'd probably need to be a proper typeof check put in place. (There might already be one in place.)

Search Words: before after promise
Related Issues: #2149

I can understand the reasoning for restricting before*, but I think it would still be nice if after* could be looser in its type (assuming that its return value is not operated on outside of a Promise check). Note: The after* consideration is why I'm keeping this issue separate instead of commenting on the old one.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.