Improve each template literal infer

[MathieuFedrigo]

Summary

Small improvement to continue the work done mainly on this PR to improve type safety/inference on the Template literals syntax of .each.

Currently, when using the template literals syntax with .each, the args type is inferred if you don't provide the generic type argument.

If all inputs (variables inside the template literal) are of the same type, the args will be inferred to the same type.

import {test} from '@jest/globals';
test.each`
  a    | b    | expected
  ${1} | ${2} | ${3}
  ${3} | ${4} | ${7}
  ${5} | ${6} | ${11}
`('template literal example same type', ({a, b, expected}) => {
  // all arguments are of type `number` because all inputs (a, b, expected) are of type `number`
});

But if the inputs are of different types, the args will be inferred to type unknown.

import {test} from '@jest/globals';
test.each`
  a    | b    | expected
  ${1} | ${2} | ${'three'}
  ${3} | ${4} | ${'seven'}
  ${5} | ${6} | ${'eleven'}
`('template literal example different types', ({a, b, expected}) => {
  // Without the generic argument explicitly provided, args types would default to `unknown`
});

This PR aims to improve the type inference for this second case. Now, args will be inferred to a type representing the union of all input types (automatically inferred from the input types inside the template literal).

import {test} from '@jest/globals';
test.each`
  a    | b    | expected
  ${1} | ${2} | ${'three'}
  ${3} | ${4} | ${'seven'}
  ${5} | ${6} | ${'eleven'}
`('template literal example different types', ({a, b, expected}) => {
  //All arguments are of type `number | string` because some inputs (a, b) are of type `number` and some others (expected) are of type `string`
});

This provides more type safety IMO because otherwise, with type unknown you can cast to non-permitted types without any warning. It will also encourage the use of an explicitly provided generic which is the safest solution regarding types currently.

Test plan

The tests already existed but were expecting unknown. I updated them.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: MathieuFedrigo / name: Mathieu Fedrigo (f4f8533, 9969aed, bdf450c)
• ✅ login: SimenB / name: Simen Bekkhus (b4af639, acf875e, fcc5d18)

[netlify]

✅ Deploy Preview for jestjs ready!

Name	Link
🔨 Latest commit	acf875e
🔍 Latest deploy log	https://app.netlify.com/sites/jestjs/deploys/65f6c09a1840130008615d16
😎 Deploy Preview	https://deploy-preview-14920--jestjs.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.

[MathieuFedrigo]

This behaviour is not related to this PR, but since I'm editing the docs, I tried to clarify it 🙂

[mrazauskas]

The idea here was to start with a simple and correctly working example.

I find it strange showing how something does not work. If a feature does not work, why it is shipped? Just remove it.

It is just an option, but I think documentation should show how to use a library instead of focussing on what does not work.

[mrazauskas]

Also your change makes this feature work better. Why to say something does not work? Hey, look! This works like a charm. Use it!

[MathieuFedrigo]

I'm not sure what part you're referring to but I simplified it!

If case you were talking about the last part (2nd commit), I chose to leave it here, but more as a pitfall. wdyt?

[mrazauskas]

Hm.. to be honest I find this behaviour confusing. item cannot be boolean. Again, just an opinion, but isn't it better to explicitly tell that type cannot be inferred instead of providing misleading / incorrect type?

[MathieuFedrigo]

Hmm, I see what you mean. Not sure if there is a standard & this might ultimately be opinion.

To clarify my reasoning, there are 2 advantages to using a union imo:

1. Less need to cast. When 1 input can actually be of different types (this might not happen often I recon, except maybe for generic functions):

test.each`
  a       | expected
  ${0}    | ${'0'}
  ${true} | ${'true'}
  ${'a'}  | ${'a'}
`('strange stringify', ({a, expected}) => {
  expect(toString(a)).toBe(expected); // no need to cast `a` here with union
});

2. Identify abusive casting: you can cast unknown to anything, but not the union.
   (the following example is strange, but something similar could happen during refactoring or when a test is updated)

test.each`
  a    | b    | expected
  ${1} | ${2} | ${'three'}
  ${3} | ${4} | ${'seven'}
`('strange stringify', ({a, expected}) => {
  const shouldError = expected as any[]
  // With `unknown`: no error 😬
  // With union: Conversion of type 'string | number' to type 'any[]' may be a mistake because neither type sufficiently overlaps with the other.
});

wdyt?

[mrazauskas]

Thanks for the proposal, but I don’t see it as improvement. Wrong types are wrong types (;

This is only an opinion. I cannot merge PRs in this repo.

[SimenB]

I think it's an improvement to say "this can be a union of these types" over unknown, even if the union is too broad. Ideally we'd be able to key to the correct value, but I think this is an improvement, even if we'd want to go further

[SimenB]

Thanks!

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

[SimenB]

https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.4