-
-
Notifications
You must be signed in to change notification settings - Fork 5
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 devdependency expect-type to v0.20.0 #488
base: main
Are you sure you want to change the base?
Conversation
👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎ This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
ffd9108
to
1a3aaf6
Compare
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/expect-type@0.15.0) |
8bf044f
to
0ae4112
Compare
0c70e7e
to
4843f0a
Compare
25b0a8a
to
ee853c1
Compare
0c66b86
to
b1a4ab1
Compare
Warning Rate limit exceeded@renovate[bot] has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 28 minutes and 40 seconds before requesting another review. How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe recent update in the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
9dbac99
to
7783771
Compare
9f22acf
to
557205c
Compare
557205c
to
b430eb4
Compare
506b5c9
to
83f4dc5
Compare
c1bd828
to
8941bc8
Compare
5fc6eeb
to
d57645f
Compare
de9f0a8
to
ec71c5e
Compare
c0e2986
to
e27eb5c
Compare
e27eb5c
to
6961496
Compare
aa48df6
to
f4a7565
Compare
f4a7565
to
e0148dc
Compare
e0148dc
to
4fc724c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
pnpm-lock.yaml
is excluded by!**/pnpm-lock.yaml
Files selected for processing (1)
- package.json (1 hunks)
Additional comments not posted (1)
package.json (1)
58-58
: Verify compatibility ofexpect-type
version update.The
expect-type
package has been updated from0.15.0
to0.20.0
. Ensure that this update is compatible with your codebase and does not introduce any breaking changes.Run the following script to check for any breaking changes or compatibility issues:
4fc724c
to
a67d41d
Compare
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 - "before 4am on Monday" (UTC).
🚦 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.