-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose "toExtend" functions #36
Comments
Ah I think I was confused reading through code. Looks like this is effectively I guess the followup is instead to support the strict "branded" version of |
This is |
Fixes #17 Closes #36 (by documenting that `toMatchTypeOf` ~= `toExtend`) Closes #37 (by documenting that helper types are not part of the API surface) Closes #32 Closes #4 Closes #6 (by documenting that you _can't_ use `.not.toBeCallableWith(...)`) Closes #38 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.snap` 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: - [x] See if the `expectTypeOf({a: 1}).toMatchTypeOf({a: 'one'})` case can also be improved. - [x] 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" Note: I have publish v0.17.0-1 based on this PR and will hopefully be able to use [that version in vitest](vitest-dev/vitest#4206) as a test before merging.
Alongside the existing
ExpectTypeOf
methods, a method to check for successful extension of types would be helpful. Perhaps a strict/branded version as well.Proposed syntax:
I would be happy to submit a PR for this. Especially since the
Extends
andStrictExtends
types are already implemented, just not directly exposed in the main method.My current workaround is:
Admittedly the grammar is a bit different (most methods start with
toBe
) so open to a renaming to match.toBeExtending
...?The text was updated successfully, but these errors were encountered: