Validate unidirectional assignability

[SamVerschueren]

Since 0.9.0, expectType assertions are strict. Buy maybe this isn't always what we want.

type Color = 'red' | 'blue';

expectType<Color>('red');

This will fail because Color is not assignable to red unless you explicitly cast it to Color.

type Color = 'red' | 'blue';

expectType<Color>('red' as Color);

Should we add a loose (or unidirectional) expectType variant for these cases?

[SamVerschueren]

We could either expose a new assertion type, which has the same behaviour as the old expectType assertion. Or we can add a config flag or object as second parameter.

expectTypeLoose<Color>('red');

expectType<Color>('red', false);

Second parameter is a boolean indicating if the assertion is strict or not.

I think I'm slightly more in favour of a separate assertion as the intention is much clearer.

[danvk]

Instead of expectTypeLoose, how about expectAssignable? Since I think that's really what you're testing.

[SamVerschueren]

I like that...

[sindresorhus]

I like expectAssignable. Should there also be a expectNotAssignable?

[SamVerschueren]

I believe a not counter part for maybe all assertions might be a good idea. For example, expectNotType might be useful as well.

[sindresorhus]

Agreed

[SamVerschueren]

I created a new issue (see #54) which I need to create the expectNotAssignable assertion. So for now, I will only implement expectAssignable until #54 is fixed.

[SamVerschueren]

When I was in the shower this morning, I figured out how I could easily add the expectNotAssignable assertion. So here it is, added it as well 🎉 :).