chore(deps): update devdependency expect-type to v0.20.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
expect-type	0.15.0 -> 0.20.0

---

Release Notes

mmkal/expect-type (expect-type)

v0.20.0

Compare Source

Breaking changes

• improve overloads support, attempt 2 by @​mmkal in https://github.com/mmkal/expect-type/pull/83

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:

type Factorize = {
  (input: number): number[]
  (input: bigint): bigint[]
}

Behvaiour before:

expectTypeOf<Factorize>().parameters.toEqualTypeOf<[bigint]>()

Behaviour now:

expectTypeOf<Factorize>().parameters.toEqualTypeOf<[number] | [bigint]>()

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

• Fix rendering issue in readme by @​mrazauskas in https://github.com/mmkal/expect-type/pull/69
• Fix minor issues in docs by @​aryaemami59 in https://github.com/mmkal/expect-type/pull/91
• create utils file by @​mmkal in https://github.com/mmkal/expect-type/pull/93
• branding.ts and messages.ts by @​mmkal in https://github.com/mmkal/expect-type/pull/95
• improve overloads support, attempt 2 by @​mmkal in https://github.com/mmkal/expect-type/pull/83
• Extends: explain myself 1e37116
• Mark internal APIs with @internal JSDoc tag (#​104) 4c40b07
• Re-export everything in overloads.ts file (#​107) 5ee0181
• JSDoc improvements (#​100) 0bbeffa

Full Changelog: mmkal/expect-type@v0.19.0...v0.20.0

v0.19.0

Compare Source

What's Changed

• Fix .omit() to work similarly to Omit by @​aryaemami59 in https://github.com/mmkal/expect-type/pull/54
• Add JSDocs to everything by @​aryaemami59 in https://github.com/mmkal/expect-type/pull/56
• Remove test import in README.md by @​aryaemami59 in https://github.com/mmkal/expect-type/pull/65

Full Changelog: mmkal/expect-type@0.18.0...0.19.0

v0.18.0

Compare Source

What's Changed

• Add .pick and .omit by @​aryaemami59 in https://github.com/mmkal/expect-type/pull/51

New Contributors

• @​aryaemami59 made their first contribution in https://github.com/mmkal/expect-type/pull/51

Full Changelog: mmkal/expect-type@v0.17.3...0.18.0

v0.17.3

Compare Source

• docs: why-is-my-assertion-failing 907b8aa
• I think the previous build was out of date somehow too, so see https://github.com/mmkal/expect-type/releases/v0.17.2

v0.17.2

Compare Source

• Improve tuple errors (#​40) 4b38117

Diff(truncated - scroll right!):

test('toEqualTypeOf with tuples', () => {
  const assertion = `expectTypeOf<[[number], [1], []]>().toEqualTypeOf<[[number], [2], []]>()`
  expect(tsErrors(assertion)).toMatchInlineSnapshot(`
-    "test/test.ts:999:999 - error TS2344: Type '[[number], [2], []]' does not satisfy the constraint '{ [x: number]: { [x: number]: number; [iterator]: (() => IterableIterator<1>) | (() => IterableIterator<number>) | (() => IterableIterator<never>); [unscopables]: (() => { copyWithin: boolean; entries: boolean; fill: boolean; find: boolean; findIndex: boolean; keys: boolean; values: boolean; }) | (() => { copyWithin: boolean; entries: boolean; fill: boolean; find: boolean; findIndex: boolean; keys: boolean; values: boolean; }) | (() => { copyWithin: boolean; entries: boolean; fill: boolean; find: boolean; findIndex: boolean; keys: boolean; values: boolean; }); length: 0 | 1; toString:  ... truncated!!!!'.
-      Types of property 'sort' are incompatible.
-        Type '(compareFn?: ((a: [] | [number] | [2], b: [] | [number] | [2]) => number) | undefined) => [[number], [2], []]' is not assignable to type '\\"Expected: function, Actual: function\\"'.
+    "test/test.ts:999:999 - error TS2344: Type '[[number], [2], []]' does not satisfy the constraint '{ 0: { 0: number; }; 1: { 0: \\"Expected: literal number: 2, Actual: literal number: 1\\"; }; 2: {}; }'.
+      The types of '1[0]' are incompatible between these types.
+        Type '2' is not assignable to type '\\"Expected: literal number: 2, Actual: literal number: 1\\"'.
    999 expectTypeOf<[[number], [1], []]>().toEqualTypeOf<[[number], [2], []]>()
                                                          ~~~~~~~~~~~~~~~~~~~"
  `)
})

v0.17.1

Compare Source

• disallow .not and .branded together cf38918

(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 a MismatchInfo type to try to make explicit what the expectation is. For example:

expectTypeOf({a: 1}).toEqualTypeOf<{a: string}>()

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:

test/test.ts:999:999 - error TS2344: Type '{ a: string; }' does not satisfy the constraint '{ a: \\"Expected: string, Actual: number\\"; }'.
  Types of property 'a' are incompatible.
    Type 'string' is not assignable to type '\\"Expected: string, Actual: number\\"'.

999 expectTypeOf({a: 1}).toEqualTypeOf<{a: string}>()

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 (like toBeString, toBeNumber, toBeVoid etc.) fail by resolving to a non-callable type when the Actual type under test doesn't match up. For example, the failure for an assertion like expectTypeOf(1).toBeString() will look something like this:

test/test.ts:999:999 - error TS2349: This expression is not callable.
  Type 'ExpectString<number>' has no call signatures.

999 expectTypeOf(1).toBeString()
                    ~~~~~~~~~~

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:

expectTypeOf({a: 1}).toEqualTypeOf({a: ''})

Will be less helpful than for an assertion like this:

expectTypeOf({a: 1}).toEqualTypeOf<{a: string}>()

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 generic Mismatch type. So, where possible, use a typearg rather than a concrete type for .toEqualTypeOf and toMatchTypeOf. If it's much more convenient to compare two concrete types, you can use typeof:

const one = valueFromFunctionOne({some: {complex: inputs}})
const two = valueFromFunctionTwo({some: {other: inputs}})

expectTypeOf(one).toEqualTypeof<typeof two>()

---

Kinda-breaking changes: essentially none, but technically, .branded no longer returns a "full" ExpectTypeOf instance at compile-time. Previously you could do this:

expectTypeOf<{a: {b: 1} & {c: 1}}>().branded.not.toEqualTypeOf<{a: {b: 1; c: ''}}>()
expectTypeOf<{a: {b: 1} & {c: 1}}>().not.branded.toEqualTypeOf<{a: {b: 1; c: ''}}>()

Now that won't work (and it was always slightly nonsensical), so you'd have to use // @​ts-expect-error instead of not if you have a negated case where you need branded:

// @​ts-expect-error
expectTypeOf<{a: {b: 1} & {c: 1}}>().branded.not.toEqualTypeOf<{a: {b: 1; c: ''}}>()

---

What's Changed

• Improve CLI error messages by @​mmkal in https://github.com/mmkal/expect-type/pull/16
• expect-type is usually a dev dependency by @​SerkanSipahi in https://github.com/mmkal/expect-type/pull/39

New Contributors

• @​SerkanSipahi made their first contribution in https://github.com/mmkal/expect-type/pull/39

Full Changelog: mmkal/expect-type@v0.16.0...v0.17.0

v0.16.0

Compare Source

What's Changed

• support functions with this parameters by @​mmkal and @​papb in https://github.com/mmkal/expect-type/pull/15
• Prevent the .not modifier from being chained by @​trevorade in https://github.com/mmkal/expect-type/pull/20
• Rewrite Equal to use the equality check from ReadonlyEquivalent exclusively by @​trevorade in https://github.com/mmkal/expect-type/pull/21

Note that #​21 has affected behavior for intersection types, which can result in (arguably) false errors:

// @​ts-expect-error the following line doesn't compile, even though the types are arguably the same.
// See https://github.com/mmkal/expect-type/pull/21
expectTypeOf<{a: 1} & {b: 2}>().toEqualTypeOf<{a: 1; b: 2}>()

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.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[socket-security]

👍 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.

View full report↗︎

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/expect-type@0.20.0	None	0	109 kB	mmkale

🚮 Removed packages: npm/expect-type@0.15.0)

View full report↗︎

[coderabbitai]

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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.

Commits

Files that changed from the base of the PR and between 4fc724c and a67d41d.

Walkthrough

The recent update in the package.json file reflects a version upgrade of the expect-type package from 0.15.0 to 0.20.0. This change aims to enhance type-checking capabilities in TypeScript, potentially adding new features and improvements. While the specifics of these enhancements are not detailed, the update is expected to contribute positively to type safety and the overall developer experience.

Changes

Files	Change Summary
package.json	Updated expect-type version from 0.15.0 to 0.20.0

Poem

In the garden of code, I hop with delight,
A new version blooms, oh what a sight! 🌼
With expect-type shining, so bright and true,
Type safety's a treasure, for me and for you!
Hopping through changes, with joy in my heart,
Let's celebrate progress, it's a wonderful start! 🐰✨

---

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?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

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)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 29e0786 and 4fc724c.

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 of expect-type version update.

The expect-type package has been updated from 0.15.0 to 0.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: