vitest-dev / vitest-dev/vitest

Add `const T` type parameter to `it.each`/`describe.each` to preserve type narrowness

Open
#10,282 1 comment 1 reaction 2 assignees View on GitHub

@sheremet-va is already working on this.

Since May 7, 2026.

  • #10291 by @copilot-swe-agent — closed without merging
enhancement: pending triage
Dominant language
TypeScript
Stars
17.1k
Forks
2k
Avg merge
1d 22h
Merged PRs (30d)
94

Description

Clear and concise description of the problem

Currently, it.each and describe.each will attempt to infer loose types about passed-in arguments, often requiring one to add as const to the provided array to obtain desired results.

TS Playground snippet

In the above example, TS attempts to infer the value type of num as wide as it can (number instead of 1 | 2), resulting in type errors unless an explicit as const is provided.

Suggested solution

Change the type parameters of it.each and describe.each from T to const T.
This will result in the destructured values having a union of the exact values being specified specified rather than their widened forms ("foo" instead of "string").

[!IMPORTANT]
While this could potentially be a breaking typing change in certain cases, it would only break functions that actively produce type errors if passed a literal value. Not impossible, yes, but niche enough to render breakages extremely unlikely.

Alternative

Force users to use as const or explicitly specify type arguments simply to force typescript to preserve literal unions (the former gets old quickly; the latter can be extremely unwieldly).

Additional context

If we really REALLY want to be backwards-compatible, we could use interface merging to make the new type-checking behaviour opt-in (similar to how Vite uses its ViteTypeOptions interface to allow selectively tightening its ImportMetaEnv handling).

Validations

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.