[Snyk] Upgrade ts-pattern from 5.0.5 to 5.8.0

[Smejia11]

Snyk has created this PR to upgrade ts-pattern from 5.0.5 to 5.8.0.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

---

• The recommended version is 18 versions ahead of your current version.

• The recommended version was released a month ago.

Release notes

Package name: ts-pattern

• 5.8.0 - 2025-07-26
  

  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: v5.7.1...v5.8.0

  PRs

  • feat: .narrow() method & typechecking perf improvement by @ gvergnaud in #261
• 5.7.1 - 2025-05-18
  

  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

  • fix(.exhaustive): optional discriminant by @ gvergnaud in #319

  Full Changelog: v5.7.0...v5.7.1

• 5.7.0 - 2025-03-28
  

  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

  • build(deps-dev): bump bun from 1.0.4 to 1.1.30 in /benchmarks by @ dependabot in #303
  • isMatching: improve narrowing by @ gvergnaud in #311
  • feat(exhaustive): Add support for passing a fallback function by @ gvergnaud in #253

  Full Changelog: v5.6.2...v5.7.0

• 5.6.2 - 2025-01-21
  

  What's Changed

  • fix(isMatching): Fix non-object patterns by @ gvergnaud in #307

  Full Changelog: v5.6.1...v5.6.2

• 5.6.1 - 2025-01-19
  

  What's Changed

  • fix(isMatching): Allow unknown properties in pattern by @ gvergnaud in #305

  Full Changelog: v5.6.0...v5.6.1

• 5.6.0 - 2024-12-15
  

  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

  • Improvements to P.infer and isMatching by @ gvergnaud in #302
  • build(deps-dev): bump rollup from 2.79.1 to 2.79.2 by @ dependabot in #289

  Full Changelog: v5.5.0...v5.6.0

• 5.5.0 - 2024-10-14
  

  What's Changed

  • Export Pattern types in package.json by @ GGomez99 in #292 closing issue #291

  New Contributors

  • @ GGomez99 made their first contribution in #292

  Full Changelog: v5.4.0...v5.5.0

• 5.4.0 - 2024-09-25
  

  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

  • build(deps-dev): bump braces from 3.0.2 to 3.0.3 by @ dependabot in #273
  • build(deps-dev): bump webpack from 5.91.0 to 5.94.0 in /examples/gif-fetcher by @ dependabot in #276
  • build(deps): bump serve-static and express in /examples/gif-fetcher by @ dependabot in #283
  • perf: improve type checking performance of BuildMany by @ gvergnaud in #286
  • Fixes type InvertPatternForExcludeInternal to work with readonly array by @ changwoolab in #284

  New Contributors

  • @ changwoolab made their first contribution in #284

  Full Changelog: v5.3.1...v5.4.0

• 5.3.1 - 2024-08-11
  

  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

  • build(deps-dev): bump braces from 3.0.2 to 3.0.3 in /examples/gif-fetcher by @ dependabot in #262
  • feat: throw custom ExhaustiveError when no matched pattern by @ adamhamlin in #270
  • Symbols as keys by @ Ayc0 in #272

  New Contributors

  • @ adamhamlin made their first contribution in #270
  • @ Ayc0 made their first contribution in #272

  Full Changelog: v5.2.0...v5.3.1

• 5.3.0 - 2024-08-11
• 5.2.0 - 2024-06-12
  

  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

  • docs: fix typo in P.when patterns code example by @ grigorischristainas in #260
  • feat: Added P.string.length by @ JUSTIVE in #257

  New Contributors

  • @ grigorischristainas made their first contribution in #260

  Full Changelog: v5.1.2...v5.2.0

• 5.1.2 - 2024-05-23
• 5.1.1 - 2024-04-06
• 5.1.1-rc.0 - 2024-04-06
• 5.1.0 - 2024-03-31
• 5.0.8 - 2024-02-15
• 5.0.7 - 2024-02-15
• 5.0.6 - 2023-12-03
• 5.0.5 - 2023-08-06

from ts-pattern GitHub release notes

---

Important

• Check the changes in this PR to ensure they won't cause issues with your project.
• This PR was automatically created by Snyk using the credentials of a real user.

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

• 🧐 View latest project report
• 📜 Customise PR templates
• 🛠 Adjust upgrade PR settings
• 🔕 Ignore this dependency or unsubscribe from future upgrade PRs

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
porfolio	Ready	Preview	Comment	Sep 10, 2025 4:26pm