-
Notifications
You must be signed in to change notification settings - Fork 37
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
chore(deps): update dependency expect-type to ^0.17.0 - autoclosed #1014
Conversation
Run & review this pull request in StackBlitz Codeflow. |
|
Estimated impact to a consuming app, depending on which bundle is imported
|
Preview URLsreadme: https://39b61782.ember-resources.pages.dev |
d5aca97
to
7f7433a
Compare
357d2a0
to
bc533d3
Compare
bc533d3
to
9f982cd
Compare
2d62e41
to
5c9032e
Compare
b4c5bf4
to
7066fe2
Compare
66bfb4a
to
6dcbf90
Compare
6dcbf90
to
945b004
Compare
67012ba
to
fa5c0d9
Compare
2502045
to
f581043
Compare
f581043
to
3beeee7
Compare
3beeee7
to
b93a598
Compare
b93a598
to
e0f5f29
Compare
e0f5f29
to
13381ce
Compare
13381ce
to
6c81183
Compare
6c81183
to
2a5f815
Compare
2a5f815
to
1656000
Compare
1656000
to
eabf13b
Compare
eabf13b
to
67ebbbe
Compare
67ebbbe
to
5d20305
Compare
5d20305
to
6076411
Compare
6076411
to
87b4b2e
Compare
This PR contains the following updates:
^0.16.0
->^0.17.0
Release Notes
mmkal/expect-type (expect-type)
v0.17.3
Compare Source
907b8aa
v0.17.2
Compare Source
4b38117
Diff(truncated - scroll right!):
v0.17.1
Compare Source
.not
and.branded
togethercf38918
(this was actually documented in the v0.17.0 release but really it was only pushed here)
v0.17.0
Compare Source
#16 went in to - hopefully - significantly improve the error messages produce on failing assertions. Here's an example of how vitest's failing tests were improved:
Before:
After:
Docs copied from the readme about how to interpret these error messages
Error messages
When types don't match,
.toEqualTypeOf
and.toMatchTypeOf
use a special helper type to produce error messages that are as actionable as possible. But there's a bit of an nuance to understanding them. Since the assertions are written "fluently", the failure should be on the "expected" type, not the "actual" type (expect<Actual>().toEqualTypeOf<Expected>()
). This means that type errors can be a little confusing - so this library produces aMismatchInfo
type to try to make explicit what the expectation is. For example:Is an assertion that will fail, since
{a: 1}
has type{a: number}
and not{a: string}
. The error message in this case will read something like this:Note that the type constraint reported is a human-readable messaging specifying both the "expected" and "actual" types. Rather than taking the sentence
Types of property 'a' are incompatible // Type 'string' is not assignable to type "Expected: string, Actual: number"
literally - just look at the property name ('a'
) and the message:Expected: string, Actual: number
. This will tell you what's wrong, in most cases. Extremely complex types will of course be more effort to debug, and may require some experimentation. Please raise an issue if the error messages are actually misleading.The
toBe...
methods (liketoBeString
,toBeNumber
,toBeVoid
etc.) fail by resolving to a non-callable type when theActual
type under test doesn't match up. For example, the failure for an assertion likeexpectTypeOf(1).toBeString()
will look something like this:The
This expression is not callable
part isn't all that helpful - the meaningful error is the next line,Type 'ExpectString<number> has no call signatures
. This essentially means you passed a number but asserted it should be a string.If TypeScript added support for "throw" types these error messagess could be improved. Until then they will take a certain amount of squinting.
Concrete "expected" objects vs typeargs
Error messages for an assertion like this:
Will be less helpful than for an assertion like this:
This is because the TypeScript compiler needs to infer the typearg for the
.toEqualTypeOf({a: ''})
style, and this library can only mark it as a failure by comparing it against a genericMismatch
type. So, where possible, use a typearg rather than a concrete type for.toEqualTypeOf
andtoMatchTypeOf
. If it's much more convenient to compare two concrete types, you can usetypeof
:Kinda-breaking changes: essentially none, but technically,
.branded
no longer returns a "full"ExpectTypeOf
instance at compile-time. Previously you could do this:Now that won't work (and it was always slightly nonsensical), so you'd have to use
// @​ts-expect-error
instead ofnot
if you have a negated case where you needbranded
:What's Changed
New Contributors
Full Changelog: mmkal/expect-type@v0.16.0...v0.17.0
Configuration
📅 Schedule: Branch creation - "after 9pm on sunday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.