protect against any more

[mmkal]

@aryaemami59 @mrazauskas

Proposal for protecting against any in a fairly simple way. This might break some people's tests, but I imagine 99% are in cases where an any has unexpectedly snuck in.

Related: this comment

[mrazauskas]

This looks interesting. I checked out this branch quickly with:

expectTypeOf<any>().toEqualTypeOf<{a: number}>() // not allowed
expectTypeOf<any>().toMatchTypeOf<{a: number}>() // not allowed

expectTypeOf<{a: any}>().toEqualTypeOf<{a: number}>() // fail
expectTypeOf<{a: any}>().toMatchTypeOf<{a: number}>() // pass !!!

expectTypeOf<any[]>().toEqualTypeOf<number[]>() // fail
expectTypeOf<any[]>().toMatchTypeOf<number[]>() // pass !!!

Nested anys are not handled. Hm.. Feels like current implementation is more predictable. It just needs to be documented.

Please understand me right, I do admire all the effort which went into writing this library. My brain could hardly come up with something similar. All I can contribute are these tests for edge cases. No ideas how to handle these anys using generic types.

[mmkal]

Nested anys are not handled. Hm.. Feels like current implementation is more predictable. It just needs to be documented.

Yes, this looking for nested anys would be straying too far from what vanilla typescript does, IMO. The cases you gave above seem right to me. toMatchTypeOf is meant to be a loose check. any is unfortunately more loose than most would want even for an officially-loose check. But there isn't currently an option for something in between toEqualTypeOf and toMatchTypeOf, which is maybe what you want.

I have thought about adding an assertion like this, which might be a useful "did I do anything stupid, anywhere" check:

const myValue = {
  deeply: {
    nested: {
      property: {
        value: JSON.parse('{}'), // whoops, this is an any
      },
    },
  },
}

expectTypeOf(myValue).notToHaveAnyAnys()

Which would fail with some helpful error containing a message along the lines of 'any' found at path 'deeply.nested.property.value'.

Please understand me right, I do admire all the effort which went into writing this library. My brain could hardly come up with something similar. All I can contribute are these tests for edge cases. No ideas how to handle these anys using generic types.

Thank you - it's helpful!

[aryaemami59]

@mmkal This is good, however I think this should probably be opt in, and since it's checking nested fields, TypeScript might not be able to handle it well especially on lower versions. Here is an idea, we can implement this to sort of mirror .branded. So we can have .branded.toEqualTypeOf() and .strict.toMatchTypeOf(). This way we avoid a breaking change and implement a new feature that is syntactically similar to an already existing feature.

[mmkal]

Having let this sit for a while, I'm inclined to not do it. Esp since the feedback is "don't do this, it's inconsistent" or "make it opt in, it's inconsistent". I'd like to avoid too many different ways to do things, so I think we should just accept that anys can trip up toMatchTypeOf, just like they can trip up pretty much everything in the TypeScript world.

Maybe for a future major version (v2 or beyond).