Skip to content
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

Unreadable error messages #17

Closed
kasperpeulen opened this issue Oct 27, 2022 · 1 comment · Fixed by #16
Closed

Unreadable error messages #17

kasperpeulen opened this issue Oct 27, 2022 · 1 comment · Fixed by #16

Comments

@kasperpeulen
Copy link

kasperpeulen commented Oct 27, 2022

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:

843F203A-565E-4401-8790-2BC41A429AFA

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?

@kasperpeulen
Copy link
Author

Oh I see this would be fixed by:
#16

Thanks!

@mmkal mmkal mentioned this issue Oct 1, 2023
2 tasks
@mmkal mmkal closed this as completed in #16 Oct 3, 2023
mmkal added a commit that referenced this issue Oct 3, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant