-
-
Notifications
You must be signed in to change notification settings - Fork 274
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.20.0 #774
Open
renovate
wants to merge
1
commit into
master
Choose a base branch
from
renovate/expect-type-0.x
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
2 times, most recently
from
June 20, 2023 18:31
7a61dcd
to
09a96cd
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
July 1, 2023 04:45
09a96cd
to
4b1f06b
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
July 10, 2023 05:20
4b1f06b
to
c380e77
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
7 times, most recently
from
July 22, 2023 12:22
20688c2
to
75a573a
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
July 28, 2023 06:29
75a573a
to
3f40c4d
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
August 7, 2023 04:47
3f40c4d
to
029708e
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
2 times, most recently
from
August 22, 2023 04:42
3507c1e
to
8a33180
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
August 29, 2023 07:02
8a33180
to
761ae42
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
2 times, most recently
from
September 12, 2023 07:46
bd6ae4d
to
c7f05c9
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
2 times, most recently
from
September 26, 2023 03:19
3e466f8
to
faa7998
Compare
renovate
bot
changed the title
chore(deps): update dependency expect-type to ^0.16.0
chore(deps): update dependency expect-type to ^0.17.0
Oct 3, 2023
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
October 3, 2023 04:42
faa7998
to
16810b5
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
October 17, 2023 06:27
16810b5
to
8c08bba
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
3 times, most recently
from
November 14, 2023 03:21
5dc4c34
to
d682d7f
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
4 times, most recently
from
November 21, 2023 10:04
ee1a039
to
c7d83bd
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
5 times, most recently
from
July 16, 2024 11:33
5d24ac0
to
7ba5579
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
2 times, most recently
from
July 30, 2024 06:44
c96aefc
to
944e3bc
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
August 6, 2024 06:25
944e3bc
to
27d41a6
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
August 13, 2024 06:29
27d41a6
to
c1bc834
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
2 times, most recently
from
August 20, 2024 19:38
93d9724
to
a4535cf
Compare
renovate
bot
changed the title
chore(deps): update dependency expect-type to ^0.19.0
chore(deps): update dependency expect-type to ^0.20.0
Aug 20, 2024
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
3 times, most recently
from
August 27, 2024 08:32
b6b6447
to
0980631
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
2 times, most recently
from
September 10, 2024 06:48
034fd12
to
f02c2d0
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
3 times, most recently
from
September 29, 2024 06:55
3a01573
to
44e2df5
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
October 18, 2024 10:07
44e2df5
to
c6ef92a
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
2 times, most recently
from
October 30, 2024 06:35
b261311
to
89feba9
Compare
renovate
bot
force-pushed
the
renovate/expect-type-0.x
branch
from
October 30, 2024 06:38
89feba9
to
9fb2ce4
Compare
renovate
bot
changed the title
chore(deps): update dependency expect-type to ^0.20.0
chore(deps): update dependency expect-type to ^0.20.0 - autoclosed
Dec 8, 2024
renovate
bot
changed the title
chore(deps): update dependency expect-type to ^0.20.0 - autoclosed
chore(deps): update dependency expect-type to ^0.20.0
Dec 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
None yet
0 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^0.15.0
->^0.20.0
Release Notes
mmkal/expect-type (expect-type)
v0.20.0
Compare Source
Breaking changes
This change updates how overloaded functions are treated. Now,
.parameters
gives you a union of the parameter-tuples that a function can take. For example, given the following type:Behvaiour before:
Behaviour now:
There were similar changes for
.returns
,.parameter(...)
, and.toBeCallableWith
. Also, overloaded functions are now differentiated properly when using.branded.toEqualTypeOf
(this was a bug that it seems nobody found).See #83 for more details or look at the updated docs (including a new section called "Overloaded functions", which has more info on how this behaviour differs for TypeScript versions before 5.3).
What's Changed
1e37116
@internal
JSDoc tag (#104)4c40b07
overloads.ts
file (#107)5ee0181
0bbeffa
Full Changelog: mmkal/expect-type@v0.19.0...v0.20.0
v0.19.0
Compare Source
What's Changed
.omit()
to work similarly toOmit
by @aryaemami59 in https://github.com/mmkal/expect-type/pull/54test
import inREADME.md
by @aryaemami59 in https://github.com/mmkal/expect-type/pull/65Full Changelog: mmkal/expect-type@0.18.0...0.19.0
v0.18.0
Compare Source
What's Changed
.pick
and.omit
by @aryaemami59 in https://github.com/mmkal/expect-type/pull/51New Contributors
Full Changelog: mmkal/expect-type@v0.17.3...0.18.0
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
v0.16.0
Compare Source
What's Changed
this
parameters by @mmkal and @papb in https://github.com/mmkal/expect-type/pull/15Equal
to use the equality check fromReadonlyEquivalent
exclusively by @trevorade in https://github.com/mmkal/expect-type/pull/21Note that #21 has affected behavior for intersection types, which can result in (arguably) false errors:
Full Changelog: mmkal/expect-type@v0.15.0...v16.0.0
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.