Skip to content

chore(deps): update dependency ts-pattern to v5.8.0 #60

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
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps): update dependency ts-pattern to v5.8.0 #60

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented May 23, 2024 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
ts-pattern 5.0.8 -> 5.8.0 age confidence

Release Notes

gvergnaud/ts-pattern (ts-pattern)

v5.8.0

Compare Source

TS-Pattern v5.8.0 Release Notes

New Feature: .narrow() Method for Deep Type Narrowing

.narrow() gives you fine-grained control over type narrowing of deeply nested union types during pattern matching.

What is .narrow()?

The .narrow() method allows you to explicitly narrow the input type to exclude all values that have been handled by previous patterns. This is especially useful when working with:

  • Deeply nested union types
  • Nullable properties at any nesting level
  • Complex type structures where you need precise type information
When to Use .narrow()

By default, TS-Pattern automatically narrows top-level union types as you pattern match. However, for deeply nested types, this narrowing doesn't happen automatically to maintain optimal TypeScript performance. The .narrow() method gives you explicit control over when to perform this more computationally expensive operation.

Example Usage
type Input = { user: { role: 'admin' | 'editor' | 'viewer' } };

declare const input: Input;

const result = match(input)
  .with({ user: { role: 'admin' } }, handleAdmin)
  .narrow() // Explicitly narrow remaining cases
  .with({ user: { role: 'editor' } }, handleEditor)
  .narrow() // Narrow again if needed
  .otherwise((remaining) => {
    // remaining.user.role is now precisely 'viewer'
    handleViewer(remaining);
  });
Additional Improvements
  • Improvements to release scripts
  • Updated dependencies

Full Changelog: gvergnaud/ts-pattern@v5.7.1...v5.8.0

PRs

v5.7.1

Compare Source

Type inference bug fixes

This new release fixes the following bug in exhaustiveness checking when matching on optional properties:

type Input = { type?: 'one' } | { type: 'two' };

const f1 = (input: Input) =>
  match(input)
    .with({ type: 'one' }, () => {})
    .with({ type: 'two' }, () => {})
    .exhaustive(); // shouldn't type-check, but does 👎

const f2 = (input: Input) =>
  match(input)
    .with({ type: 'one' }, () => {})
    .with({ type: 'two' }, () => {})
    .with({ type: undefined }, () => {}) // <- the type key needs to be present.
    .exhaustive();  // shouldn't type-check, but does 👎

These two cases don't type check anymore. They fail with a NonExhaustiveError<{ type?: undefined; }>. To fix it, you should do:

type Input = { type?: 'one' } | { type: 'two' };

const f = (input: Input) =>
  match(input)
    .with({ type: 'one' }, () => {})
    .with({ type: 'two' }, () => {})
    .with({ type: P.optional(undefined) }, () => {}) // <- the type property may not be there
    .exhaustive(); // ✅

This is a purely type-level change, the runtime behavior is still the same.

What's Changed

Full Changelog: gvergnaud/ts-pattern@v5.7.0...v5.7.1

v5.7.0

Compare Source

New feature

Exhaustive callback

By default, .exhaustive() will throw an error if the input value wasn't handled by any .with(...) clause. This should only happen if your types are incorrect.

It is possible to pass your own handler function as a parameter to decide what should happen if an unexpected value has been received. You can for example throw your own custom error:

match(...)
  .with(...)
  .exhaustive((unexpected: unknown) => {
    throw MyCustomError(unexpected);
  })

Or log an error and return a default value:

match<string, number>(...)
  .with(P.string, (str) => str.length)
  .exhaustive((notAString: unknown) => {
    console.log(`received an unexpected value: ${notAString}`);
    return 0;
  })

Improved narrowing for isMatching

isMatching didn't have full feature parity with match in terms of type narrowing, but now does.

What's Changed

Full Changelog: gvergnaud/ts-pattern@v5.6.2...v5.7.0

v5.6.2

Compare Source

What's Changed

Full Changelog: gvergnaud/ts-pattern@v5.6.1...v5.6.2

v5.6.1

Compare Source

What's Changed

Full Changelog: gvergnaud/ts-pattern@v5.6.0...v5.6.1

v5.6.0

Compare Source

This release contains two changes:

Typecheck pattern when using isMatching with 2 parameter.

It used to be possible to pass a pattern than could never match to isMatching. The new version checks that the provide pattern does match the value in second parameter:

type Pizza = { type: 'pizza'; topping: string };
type Sandwich = { type: 'sandwich'; condiments: string[] };
type Food = Pizza | Sandwich;

const fn = (food: Pizza | Sandwich) => {
    if (isMatching({ type: 'oops' }, food)) {
        //                  👆 used to type-check, now doesn't!
    }
}
Do not use P.infer as an inference point

When using P.infer<Pattern> to type a function argument, like in the following example:

const getWithDefault = <T extends P.Pattern>(
  input: unknown,
  pattern: T,
  defaultValue: P.infer<T> //  👈
): P.infer<T> =>
  isMatching(pattern, input) ? input : defaultValue

TypeScript could get confused and find type errors in the wrong spot:

const res = getWithDefault(null, { x: P.string }, 'oops') 
//                                     👆           👆 type error should be here
//                                 but it's here 😬

This new version fixes this problem.

What's Changed

Full Changelog: gvergnaud/ts-pattern@v5.5.0...v5.6.0

v5.5.0

Compare Source

What's Changed

New Contributors

Full Changelog: gvergnaud/ts-pattern@v5.4.0...v5.5.0

v5.4.0

Compare Source

The main thing — Faster type checking 🚀

This release brings a significant perf improvement to exhaustiveness checking, which led to a ~16% decrease in the time to type-check the full test suite of TS-Pattern:

Category Before After Evolution (%)
Instantiations 6,735,991 4,562,378 -32.33%
Memory used 732,233K 746,454K 1.95%
Assignability cache size 209,959 205,926 -1.92%
Identity cache size 28,093 28,250 0.56%
Check time 5.78s 4.83s -16.44%

What's Changed

New Contributors

Full Changelog: gvergnaud/ts-pattern@v5.3.1...v5.4.0

v5.3.1

Compare Source

Pattern-matching on symbol keys

Symbols used to be ignored in object patterns. They are now taken into account:

const symbolA = Symbol('symbol-a');
const symbolB = Symbol('symbol-b');

const obj = { [symbolA]: { [symbolB]: 'foo' } };
    
if (isMatching({ [symbolA]: { [symbolB]: 'bar' } }, obj)) {
   //  👆 Used to return true, now returns false!
   
   //  Since TS-Pattern wasn't reading symbols, this pattern used to be equivalent
   //  to the `{}` pattern that matches any value except null and undefined.
}

.exhaustive now throws a custom error

People have expressed the need to differentiate runtime errors that .exhaustive() might throw when the input is of an unexpected type from other runtime errors that could have happened in the same match expression. It's now possible with err instanceof NonExhaustiveError:

import { match, P, NonExhaustiveError }  from 'ts-pattern';

const fn = (input: string | number) => {
  return match(input)
    .with(P.string, () => "string!")
    .with(P.number, () => "number!")
    .exhaustive()
}

try {
  fn(null as string) // 👈 💥 
} catch (e) {
  if (e instanceof NonExhaustiveError) {
    // The input was invalid
  } else {
    // something else happened
  }
}

What's Changed

New Contributors

Full Changelog: gvergnaud/ts-pattern@v5.2.0...v5.3.1

v5.3.0

Compare Source

v5.2.0

Compare Source

The main thing

new P.string.length(n) pattern

P.string.length(len) matches strings with exactly len characters.

const fn = (input: string) =>
  match(input)
    .with(P.string.length(2), () => '🎉')
    .otherwise(() => '❌');

console.log(fn('ok')); // logs '🎉'

What's Changed

New Contributors

Full Changelog: gvergnaud/ts-pattern@v5.1.2...v5.2.0

v5.1.2

Compare Source

The main thing

When combining P.nonNullable and P.nullish, you should get an exhaustive pattern matching expression, but the following case was incorrectly considered non-exhaustive:

declare const input: {
  nested: string | number | null | undefined;
};

const res = match(input)
  .with({ nested: P.nonNullable }, (x) => {/* ... */})
  .with({ nested: P.nullish }, (x) => {/* ... */})
  // should type-check
  .exhaustive();

This is fixed now.

What's Changed

New Contributors

Full Changelog: gvergnaud/ts-pattern@v5.1.1...v5.1.2

v5.1.1

Compare Source

What's Changed

Full Changelog: gvergnaud/ts-pattern@v5.1.0...v5.1.1

v5.1.0

Compare Source

New features

P.nonNullable wildcard

Add a new P.nonNullable pattern that will match any value except null or undefined.

import { match, P } from 'ts-pattern';

const input = null;

const output = match<number | null | undefined>(input)
  .with(P.nonNullable, () => 'it is a number!')
  .otherwise(() => 'it is either null or undefined!');

console.log(output);
// => 'it is either null or undefined!'

Closes #​60 #​154 #​190 and will be a work-around for #​143.

What's Changed

Full Changelog: gvergnaud/ts-pattern@v5.0.8...v5.1.0

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

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

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

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

@changeset-bot changeset-bot
Copy link

changeset-bot bot commented May 23, 2024 •
edited
Loading

⚠️ No Changeset found

Latest commit: 9a11f12

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from 902b856 to 66ea1e1 Compare May 24, 2024 08:41
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.1.1 chore(deps): update dependency ts-pattern to v5.1.2 May 24, 2024
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from 66ea1e1 to 5da84cc Compare June 15, 2024 02:36
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.1.2 chore(deps): update dependency ts-pattern to v5.2.0 Jun 15, 2024
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from 5da84cc to 218b535 Compare August 12, 2024 05:32
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.2.0 chore(deps): update dependency ts-pattern to v5.3.1 Aug 12, 2024
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.3.1 chore(deps): update dependency ts-pattern to v5.4.0 Sep 26, 2024
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from 218b535 to d42c3a2 Compare September 26, 2024 08:38
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from d42c3a2 to ac5b231 Compare October 16, 2024 05:56
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.4.0 chore(deps): update dependency ts-pattern to v5.5.0 Oct 16, 2024
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from ac5b231 to 8bafe2c Compare December 16, 2024 01:47
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.5.0 chore(deps): update dependency ts-pattern to v5.6.0 Dec 16, 2024
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from 8bafe2c to 5660d8c Compare January 20, 2025 19:37
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.6.0 chore(deps): update dependency ts-pattern to v5.6.1 Jan 20, 2025
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.6.1 chore(deps): update dependency ts-pattern to v5.6.2 Jan 24, 2025
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from 5660d8c to 4153956 Compare January 24, 2025 03:49
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.6.2 chore(deps): update dependency ts-pattern to v5.7.0 Mar 29, 2025
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from 4153956 to 12fc4f3 Compare March 29, 2025 11:54
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from 12fc4f3 to db3f50e Compare May 18, 2025 19:21
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.7.0 chore(deps): update dependency ts-pattern to v5.7.1 May 18, 2025
@renovate renovate bot changed the title chore(deps): update dependency ts-pattern to v5.7.1 chore(deps): update dependency ts-pattern to v5.8.0 Aug 4, 2025
@renovate renovate bot force-pushed the renovate/ts-pattern-5.x branch from db3f50e to 9a11f12 Compare August 4, 2025 19:02
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