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.

Sign up for GitHub

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

Jump to bottom

chore(deps): update npm dependencies (minor) #145

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

chore(deps): update npm dependencies (minor) #145

wants to merge 1 commit into from

Conversation

alma-renovate-bot[bot]
Copy link
Contributor

@alma-renovate-bot alma-renovate-bot bot commented Sep 23, 2024 •
edited
Loading

This PR contains the following updates:

Package Type Update Change Age Confidence
@babel/plugin-proposal-export-default-from (source) devDependencies minor 7.24.7 -> 7.25.9 age confidence
@babel/plugin-transform-react-jsx (source) devDependencies minor 7.24.7 -> 7.25.9 age confidence
@babel/plugin-transform-runtime (source) devDependencies minor 7.24.7 -> 7.25.9 age confidence
@babel/preset-env (source) devDependencies minor 7.24.8 -> 7.26.0 age confidence
@babel/preset-react (source) devDependencies minor 7.24.7 -> 7.25.9 age confidence
@babel/preset-typescript (source) devDependencies minor 7.24.7 -> 7.26.0 age confidence
core-js (source) devDependencies minor 3.37.1 -> 3.39.0 age confidence
expect-type devDependencies minor ^0.9.2 -> ^0.20.0 age confidence

Release Notes

babel/babel (@​babel/plugin-proposal-export-default-from)

v7.25.9

Compare Source

🐛 Bug Fix
🏠 Internal
🏃‍♀️ Performance

v7.25.8

Compare Source

🐛 Bug Fix
🏠 Internal
  • babel-parser, babel-plugin-proposal-async-do-expressions, babel-plugin-proposal-destructuring-private, babel-plugin-proposal-do-expressions, babel-plugin-proposal-explicit-resource-management, babel-plugin-proposal-export-default-from, babel-plugin-proposal-function-bind, babel-plugin-proposal-function-sent, babel-plugin-proposal-import-defer, babel-plugin-proposal-partial-application, babel-plugin-proposal-throw-expressions, babel-plugin-transform-async-generator-functions, babel-plugin-transform-class-static-block, babel-plugin-transform-dynamic-import, babel-plugin-transform-export-namespace-from, babel-plugin-transform-json-strings, babel-plugin-transform-logical-assignment-operators, babel-plugin-transform-nullish-coalescing-operator, babel-plugin-transform-numeric-separator, babel-plugin-transform-object-rest-spread, babel-plugin-transform-optional-catch-binding, babel-plugin-transform-optional-chaining, babel-plugin-transform-private-property-in-object, babel-preset-env

v7.25.7

Compare Source

🐛 Bug Fix
💅 Polish
🏠 Internal
  • babel-core
  • babel-helper-compilation-targets, babel-helper-plugin-utils, babel-preset-env
  • babel-plugin-proposal-destructuring-private, babel-plugin-syntax-decimal, babel-plugin-syntax-import-reflection, babel-standalone
  • babel-generator
🏃‍♀️ Performance
zloirock/core-js (core-js)

v3.39.0

Compare Source

v3.38.1

Compare Source

v3.38.0

Compare Source

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:

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

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

v0.19.0

Compare Source

What's Changed

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

v0.18.0

Compare Source

What's Changed

New Contributors

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

v0.17.3

Compare Source

v0.17.2

Compare Source

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:

image

After:

image

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 // @&#8203;ts-expect-error instead of not if you have a negated case where you need branded:

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

What's Changed

New Contributors

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

v0.16.0

Compare Source

What's Changed

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

// @&#8203;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

v0.15.0

Compare Source

What's Changed

New Contributors

Full Changelog: mmkal/expect-type@v0.14.2...v0.15.0

v0.14.2

Compare Source

  • update homepage in package.json c29243d

v0.14.1

Compare Source

Pure docs update

v0.14.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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

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

This PR has been generated by Renovate Bot.

@alma-renovate-bot alma-renovate-bot bot requested a review from a team September 23, 2024 10:23
@alma-renovate-bot alma-renovate-bot bot force-pushed the renovate/npm-dependencies branch 2 times, most recently from 692fea7 to e300c99 Compare October 7, 2024 10:18
@alma-renovate-bot alma-renovate-bot bot force-pushed the renovate/npm-dependencies branch 2 times, most recently from 19ca882 to 9236647 Compare October 21, 2024 10:16
@sonarcloud SonarCloud
Copy link

sonarcloud bot commented Nov 11, 2024

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants