Was attempting to use expectTypeOf with unioned types and I was surprised that expectTypeOf was always mismatching.

See this repro showcasing the problems of union types that get stuck in Extends.

Note: This only impacts the LHS of the extends.

Makes DeepBrand more comprehensive to cover more cases. See the updated usage.test.ts test cases to get an idea of what is supported now.

Most things in TypeScript can have properties attached to them. There are also some things that DeepBrand can only check for by just directly including value: T such as private properties on classes.

Hello,

This is not an issue, I just wanted to thank you for making this library. I learned many things by reading the source code. In particular I liked the DeepBrand type.

I was using the following simple custom types to unit test types

export type Is<T extends true> = T
export type Equal<X, Y> = Exclude<X, Y> | Exclude<Y, X> extends never ? true : false

// To test that two types A and B are equal, I do
type Test = Is<Equal<A, B>>

As you see, this works for simple cases, but will fail to check optional properties for example ...

I will be using this library instead :)

Feel free to close this issue once you read it ;)

Repro:

import { expectTypeOf } from 'expect-type'

type NoThisParam = (a: number) => void
type DateThisParam = (this: Date, a: number) => void
type UndefinedThisParam = (this: undefined, a: number) => void
type UnknownThisParam = (this: unknown, a: number) => void
type AnyThisParam = (this: any, a: number) => void

// `NoThisParam` and `UnknownThisParam` are the only ones that should be considered equivalent.

expectTypeOf<NoThisParam>().toEqualTypeOf<NoThisParam>();
expectTypeOf<NoThisParam>().not.toEqualTypeOf<DateThisParam>(); // Fails!
expectTypeOf<NoThisParam>().not.toEqualTypeOf<UndefinedThisParam>(); // Fails!
expectTypeOf<NoThisParam>().toEqualTypeOf<UnknownThisParam>();
expectTypeOf<NoThisParam>().not.toEqualTypeOf<AnyThisParam>(); // Fails!

Playground

Note: I extracted a very small part of this PR to https://github.com/mmkal/expect-type/pull/20

This is a breaking change as I opted to remove the types that were no longer needed. They are exported though so it's likely some people depend on them. I can add these back as desired.

This took a lot of tinkering. This topic and this equality check is discussed extensively at https://github.com/Microsoft/TypeScript/issues/27024

The main three edge-cases this implementation worked around are:

1. Explicitly handling any separately
2. Supporting identity unions
3. Supporting identity intersections

The only remaining known issue with this implementation is:

  // @ts-expect-error This is the bug.
  expectTypeOf<{foo: number} & {bar: string}>().toEqualTypeOf<{foo: number; bar: string}>()

@shicks and I could not find a tweak to the Equality check to make this work.

Instead, I added a workaround in the shape of a new .simplified modifier that works similar to .not:

  // The workaround is the new optional .simplified modifier.
  expectTypeOf<{foo: number} & {bar: string}>().simplified.toEqualTypeOf<{foo: number; bar: string}>()

I'm not entirely sure what to do with documenting .simplified because it's something you should never use unless you need it. The simplify operation tends to lose information about the types being tested (e.g., functions become {} and classes lose their constructors). I'll definitely update this PR to reference the .simplified modifier but I wanted to get a review on this approach first. One option would be to keep around all the DeepBrand stuff and to have .deepBranded or something being the modifier instead. That would have the benefit of preserving all the exported types making this less of a breaking change.

I introduced this package some weeks ago in the storybook monorepo and I love it.

However I get complains that the error messages are unreadable:

Which I agree on, but I learned myself some tricks to debug that. I do something like this:

expectTypeOf(meta).toEqualTypeOf<
  ComponentAnnotations<
    VueFramework,
    {
      readonly disabled: boolean;
      readonly label: string;
      onMyChangeEvent?: (id: number) => any;
      onMyClickEvent?: (id: number) => any;
    }
  >
>();

// debugging the error
const _: ComponentAnnotations<
  VueFramework,
  {
    readonly disabled: boolean;
    readonly label: string;
    onMyChangeEvent?: (id: number) => any;
    onMyClickEvent?: (id: number) => any;
  }
> = meta;

const __: typeof meta = _;

However, we can not expect that from any (external) contributor.

Would it be possible to make those errors more readable?

Use generics to give better error messages than "Arguments for the rest parameter 'MISMATCH' were not provided" for most toEqualTypeOf cases and many toMatchTypeOf cases. This trades off some implementation complexity for better end-user error messages. Essentially, write a special <Expected extends ...> constraint for each overload of each method, which does some crazy conditional logic, which boil down to:

• <Expected extends Actual> for toEqualTypeOf (when we aren't in a .not context)
• <Expected extends Satisfies<Actual>> for toMatchTypeOf

Anyone interested, have a look at the snapshot updates in errors.test.ts to see what the real world difference is.

Each of these constraints apply only when we know it's going to "fail" - i.e. Satisfies<...> is a fairly meaningless helper type that is used to try to show errors at the type-constraint level rather than the ...MISMATCH: MismatchArgs<...> level which won't give good error messages.

When using .not, the constraint just becomes extends unknown, and you'll have to squint as before.

See also: #14 for the better long-term solution, if the TypeScript team decide to merge the throw types PR. See also: #13 for a hopefully-complementary improvement to the information on hover, which will improve the cases this doesn't cover.

TODO:

• [ ] See if the expectTypeOf({a: 1}).toMatchTypeOf({a: 'one'}) case can also be improved.
• [ ] Document. The constraints are a bit different to what most users would be used to, so it's worth highlighting the best way to read error messages and clarify when they might default to "Arguments for the rest parameter 'MISMATCH' were not provided"

Copy-paste of https://github.com/mmkal/ts/pull/152

Note - since this is a copy paste of a mod of an old version, a few features that have gone in since then may be regressed. This isn't going to go in anyway unless throw-types are added to TypeScript officially though.

Updates MismatchArgs to, rather than create the tuple [never], creates a tuple with an object literal containing the Actual type and the expected type.

How the expected type is shown depends on the specific match. I will most likely post screenshots showing the errors for the various matchers in the PR conversation.

I left toBeCallableWith and toBeConstructibleWith alone as these do not use MismatchArgs and I couldn't work out how to use Variadic Tuple Types to make it work. These error messages are easier to understand anyways.

If https://github.com/microsoft/TypeScript/pull/40468 is merged, we could drop MismatchArgs in favor of having a return that, rather than return true, uses a type throw if the type does not match.

Thank you for authoring this library! I'd like to start using it in my work but want to make sure that we're attributing it correctly.

Can you please add a short copyright notice to the index.ts file?

Some examples:

// Copyright 2022 [name of copyright owner]

/**
 * Copyright 2022 [name of copyright owner]
 * @license Apache-2.0
 */