Recent searches
Search options
Is there a tool for #TypeScript that checks static type assertions similar to the following one?
// %inferred-type: (string | number | boolean)[]
const arr = [1, 'a', true];
I have written such a tool but it’s not ready for public consumption ATM, so such a tool already existing would save me the work of publishing what I have.
My tool is loosely similar to unit test runners such as Mocha—it enables static unit tests, if you will.
@vbraun Looks good, thanks! A different style than what I’m used to, with different pros and cons.
@rauschma Not _quite_ sure what you mean, but here is a tool that might fall into that range of tools at least:
zod - TypeScript-first schema validation with static type inference:
@rauschma I wrote this for type testing: https://github.com/esfx/esfx/blob/main/packages/type-model/src/test.ts part of `@esfx/type-model` on npm.
![TypeScript Code:
import type { Test, ExpectType } from '@esfx/type-model/test';
const arr = [1, 'a', true];
type _ = [
Test<ExpectType<typeof arr, (string | number | boolean)[]>>
];](https://cdn.fosstodon.org/media_attachments/files/109/400/692/848/940/166/original/95c12c6c7767a5e6.png "TypeScript Code:
import type { Test, ExpectType } from '@esfx/type-model/test';
const arr = [1, 'a', true];
type _ = [
Test<ExpectType<typeof arr, (string | number | boolean)[]>>
];")
@rauschma this is different than `satisfies`, right?
@rauschma It sounds like the new satisfies operator does what you need (new in v4.9):
> const arr = [1, 'a', true];
undefined
> arr satisfies (string | number | boolean)[]
{{{no typescript error}}}
> const arr2 = [1, 'a', true, new Date()];
undefined
> arr2 satisfies (string | number | boolean)[];
<repl>.ts:8:16 - error TS1360: Type '(string | number | boolean | Date)[]' does not satisfy the expected type '(string | number | boolean)[]'.
@vincentrolfs Alas, it’s not strict enough:
const a = 123;
(a satisfies number | boolean | string); // no error
@rauschma How about something like this? See also https://stackoverflow.com/questions/53807517/how-to-test-if-two-types-are-exactly-the-same.
@vincentrolfs Yes, that looks similar to some of the other suggestions in the replies! I’ll have to think about it—different from what I’m currently doing, with different pros and cons.
There is `satisfies` in upcoming TS version
https://devblogs.microsoft.com/typescript/announcing-typescript-4-9/#the-satisfies-operator
And you can create a generic type that would do the same job, by the way.
I have it in my work chats, can dig it up if you want.
It relies on basically putting a variable of a type X as an argument into a function. But with a creative twist you don't actually call any function, just create a type of it — which falls apart if type doesn't match. Errors are even quite useful.
Of course `satisfies` is a one-sided check: type X can pass as Y, but not vice versa.
I bet you can do both ways too, in clunkier syntax.
@rauschma definitely typed uses special comments compared textually and I would recommend tsd’s approach instead. The comment doesn’t look like a test to humans, there’s no editor support from typescript, and textual comparison causes tests to be fragile across typescript versions. You do get more precision—the ability to assert exactly what people will see in quickinfo.
(The rule is in Microsoft/definitelytyped-tools/packages/dtslint/src/rules/expectRule.ts)
@shivelysanders Good points, thanks!
I still miss one feature:
– In JS unit testing, there is assert.throws (or similar).
– My tool supports the equivalent for TS types—it compares text after @ ts-expect-error with the error message that it suppresses:
// @ts-expect-error: Type 'Person' is not assignable to type 'Color'.
// Types have separate declarations of a private property
// 'branded'. (2322)
const color: Color = person;
// Remaining code: https://exploringjs.com/tackling-ts/ch_class-related-types.html#switching-off-structural-typing
Any ideas?
@rauschma @shivelysanders I think this is something I could add to my type-model tests (ie., an ExpectNotType)
@rbuckton @shivelysanders
I’m wondering if that always works. I’ve collected how I use (a)ts-expect-error in my TypeScript book: https://gist.github.com/rauschma/4d1ee06e47e03545d4c4b31b59700786
@rauschma you can add the explicit type to the definition ala `const arr: (number | string | boolean)[] = [1, 'a', true]`, or if you add `as const` ala `const arr = [1, 'a', true] as const`, you can then use the new `satisfies` keyword with more precision.
(But I may be misunderstanding what you're after?)
@rauschma there's an ESLint plugin that includes twoslash assertions: https://github.com/JoshuaKGoldberg/eslint-plugin-expect-type
https://effectivetypescript.com/2022/05/28/eslint-plugin-expect-type
@JoshuaKGoldberg This looks good!