You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
Clear and concise description of the problem
Currently,
it.eachanddescribe.eachwill attempt to infer loose types about passed-in arguments, often requiring one to addas constto the provided array to obtain desired results.TS Playground snippet
In the above example, TS attempts to infer the value type of
numas wide as it can (numberinstead of1 | 2), resulting in type errors unless an explicitas constis provided.Suggested solution
Change the type parameters of
it.eachanddescribe.eachfromTtoconst 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 constor 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
ViteTypeOptionsinterface to allow selectively tightening itsImportMetaEnvhandling).Validations