Skip to content

build(deps): bump the all-dependencies group with 8 updates - #371

Merged
mbianchidev merged 1 commit into
mainfrom
dependabot/npm_and_yarn/all-dependencies-44674f26d6
Oct 27, 2026
Merged

build(deps): bump the all-dependencies group with 8 updates#371
mbianchidev merged 1 commit into
mainfrom
dependabot/npm_and_yarn/all-dependencies-44674f26d6

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 27, 2026

Copy link
Copy Markdown
Contributor

Bumps the all-dependencies group with 8 updates:

Package From To
@llamaindex/liteparse 2.15.1 2.17.0
electron-updater 6.8.9 6.8.11
i18next 26.4.7 26.5.10
react-i18next 17.0.21 17.1.8
react-router 8.4.0 8.5.0
electron 44.9.3 45.0.0
electron-builder 26.17.0 26.18.0
vite 8.3.4 8.3.5

Updates @llamaindex/liteparse from 2.15.1 to 2.17.0

Release notes

Sourced from @​llamaindex/liteparse's releases.

Crates & CLI v2.17.0

What's Changed

New Contributors

Full Changelog: run-llama/liteparse@crates-v2.16.0...crates-v2.17.0

Node.js v2.17.0

What's Changed

New Contributors

Full Changelog: run-llama/liteparse@crates-v2.16.0...node-v2.17.0

Python v2.17.0

What's Changed

... (truncated)

Commits
  • a47f56d bump pdfium version
  • c22343d v2.17.0
  • 946da37 Merge pull request #514 from OsamaAnsar/fix/node-cli-batch-parse-and-version
  • 25a1ead Merge pull request #509 from mkh09353/fix/markdown-dropped-text
  • 384479e Merge remote-tracking branch 'origin/main' into fix/markdown-dropped-text
  • 49581f8 Merge pull request #518 from run-llama/fix/ruled-table-note-row
  • 0982ef5 Don't end ruled tables at a lone mid-table note row
  • 0938b63 Merge pull request #507 from hebbia/hebbia/table-fixes
  • 2da9251 Merge pull request #506 from cestercian/fix/split-backward-jump-after-short-run
  • 8ef3c68 Merge pull request #508 from gun29may/feat/indraocr-server
  • Additional commits viewable in compare view

Updates electron-updater from 6.8.9 to 6.8.11

Release notes

Sourced from electron-updater's releases.

electron-updater@6.8.11

Patch Changes

electron-updater@6.8.10

Patch Changes

  • Fix: make multi-range differential downloads work on real servers. Three independent defects made downloadUpdate fall back to a full download with Response ends without calling any handlers: [#10219](https://github.com/electron-userland/electron-builder/tree/HEAD/packages/electron-updater/issues/10219) 7dd7f8a @​claude

    • DataSplitter only recognised CRLF. Some CDNs answer multipart/byteranges with bare LF line endings, so no part was ever split and the whole response accumulated in memory. Header lists now end at whichever of \r\n\r\n / \n\n comes first, and the <EOL>--boundary separator size follows the line ending the server actually uses.
    • A header-list terminator split across two chunks was never found: only the new chunk was searched, the buffered bytes never were, so the parser locked onto the next part's header instead. Only the last few bytes of an unfinished header list are now carried over and searched together with the next chunk, instead of accumulating the whole list.
    • The 10s watchdog armed when a batch response ends was never disarmed after that batch succeeded. With more than 1000 operations (several range requests) it failed the whole download whenever a later batch took longer than the grace period.

  • Fix: keep the cached blockmap consistent with the cached installer. A download round that did not produce a new blockmap (e.g. the differential download was skipped because the cached installer was evicted) now removes the cached current.blockmap instead of leaving a stale one next to the freshly cached file, which poisoned the next differential download and surfaced as a generic sha512 checksum mismatch before falling back to a full download (#10097). Leftover pending blockmaps from previous update rounds are also cleared before a fresh download. sha512-mismatch logging now distinguishes a differential download that failed against stale/corrupt cached inputs (including whether the old blockmap came from the local cache or the server) from a genuine checksum failure of a fully downloaded file. [#10163](https://github.com/electron-userland/electron-builder/tree/HEAD/packages/electron-updater/issues/10163) 1dfe1a9 @​claude

Changelog

Sourced from electron-updater's changelog.

6.8.11

Patch Changes

6.8.10

Patch Changes

  • Fix: make multi-range differential downloads work on real servers. Three independent defects made downloadUpdate fall back to a full download with Response ends without calling any handlers: [#10219](https://github.com/electron-userland/electron-builder/tree/HEAD/packages/electron-updater/issues/10219) 7dd7f8a @​claude

    • DataSplitter only recognised CRLF. Some CDNs answer multipart/byteranges with bare LF line endings, so no part was ever split and the whole response accumulated in memory. Header lists now end at whichever of \r\n\r\n / \n\n comes first, and the <EOL>--boundary separator size follows the line ending the server actually uses.
    • A header-list terminator split across two chunks was never found: only the new chunk was searched, the buffered bytes never were, so the parser locked onto the next part's header instead. Only the last few bytes of an unfinished header list are now carried over and searched together with the next chunk, instead of accumulating the whole list.
    • The 10s watchdog armed when a batch response ends was never disarmed after that batch succeeded. With more than 1000 operations (several range requests) it failed the whole download whenever a later batch took longer than the grace period.

  • Fix: keep the cached blockmap consistent with the cached installer. A download round that did not produce a new blockmap (e.g. the differential download was skipped because the cached installer was evicted) now removes the cached current.blockmap instead of leaving a stale one next to the freshly cached file, which poisoned the next differential download and surfaced as a generic sha512 checksum mismatch before falling back to a full download (#10097). Leftover pending blockmaps from previous update rounds are also cleared before a fresh download. sha512-mismatch logging now distinguishes a differential download that failed against stale/corrupt cached inputs (including whether the old blockmap came from the local cache or the server) from a genuine checksum failure of a fully downloaded file. [#10163](https://github.com/electron-userland/electron-builder/tree/HEAD/packages/electron-updater/issues/10163) 1dfe1a9 @​claude

Commits
  • e2a8604 chore(deploy): Release v26.18.0 (electron-updater@6.8.11) (v26) (#10250)
  • e5e3b41 fix(updater): validate cached update filenames (v26 backport of #10115) (#10300)
  • 5cdf017 chore(deploy): Release v26.17.0 (electron-updater@6.8.10) (v26) (#10191)
  • 7dd7f8a fix(updater): make multi-range differential downloads work on real servers (v...
  • 1dfe1a9 fix(electron-updater): keep cached blockmap consistent with cached installer ...
  • See full diff in compare view

Updates i18next from 26.4.7 to 26.5.10

Release notes

Sourced from i18next's releases.

v26.5.10

  • fix: when none of the detected languages is in supportedLngs, the best match no longer picks a different language whose code only starts with the same letters. The last fuzzy check took any supported code starting with the language part, so with supportedLngs: ['en', 'fil-PH'] a Finnish user (fi-FI) got Filipino instead of the fallback language, and ha (Hausa) picked haw-US (Hawaiian). Other regions of the same language still match as before (de-CH → de-DE, pt-PT → pt-BR, fil → fil-PH). Compatibility note: a two-letter code no longer matches a supported three-letter code that extends it, like ar → arz-EG, sw → swh-KE or no → nob-NO; list the two-letter code in supportedLngs (or map it with fallbackLng) if you relied on that. Thanks @​Pharex38 (#2460).

v26.5.9

  • fix: nested lookups no longer resolve to methods inherited from the prototype, like constructor, toString or map. Only the top level was guarded, so {{constructor}} was treated as missing, but {{user.constructor}} rendered the function source (with a class instance, the full source code of the class), and {{user.toString}}, {{items.map}} or a class method like {{user.greet}} did the same. The same lookup is used for translation keys when ignoreJSONStructure is on (the default): a nested key named like an inherited method that is missing in the current language (t('roles.constructor') with roles.constructor only in the fallback language) returned function Object() { [native code] } instead of falling back, and exists('roles.valueOf') returned true. These keys are now missing, so the fallback language, missingInterpolationHandler, saveMissing and the missing key handler apply as for any other missing key. Getters defined on a class ({{user.fullName}} with get fullName()) still work. Nested lookups also no longer walk into the prototype via __proto__, so {{user.__proto__.constructor}} no longer prints the class source either. Thanks @​Pharex38 (#2459).

v26.5.8

  • fix: arrays returned with joinArrays now get the same resolved details as strings. The joined value was extended with lastKey in the place of the resolved lookup, so with postProcessPassResolved a post processor got no usedLng, usedNS or exactUsedKey (t('steps', { joinArrays: ' / ' }) reported undefined/undefined:undefined). This affected the subliminal post processor used by the locize InContext editor, which could not map a joined array to its key. The nesting recursion guard did not get the parent key either, so arrays that nest each other (listA: ['a', '$t(listB)'], listB: ['b', '$t(listA)']) threw Maximum call stack size exceeded. They now stop at the guard, as strings do. An i18nFormat plugin with handleAsObject and parse also no longer throws Cannot read properties of undefined (reading 'usedNS') on joined arrays. Thanks @​nk-batman21 (#2458).

v26.5.7

  • fix: with the default cacheInBuiltFormats: true, built-in formats now also work when the t() options contain a BigInt or a circular object. The cache key was built with JSON.stringify over all options, including the interpolation values, which throws on those, so every built-in format in that call returned the raw value: t('num', { val: 12345678901234567890n }) with 'Total: {{val, number}}' returned 'Total: 12345678901234567890' instead of 'Total: 12,345,678,901,234,567,890', and passing an object with a back-reference (like an ORM entity) left all numbers, dates and lists of that call unformatted. When the key cannot be built, the value is now formatted without the cache, as with cacheInBuiltFormats: false. This also applies to formatters added with addCached. Other calls still use the cache as before. Thanks @​nk-batman21 (#2457).

v26.5.6

  • fix: cloneInstance({ forkResourceStore: true }) now copies the resources at every level. It copied them only down to the namespace objects, so nested keys and arrays stayed shared with the original instance: addResource() with a nested key (fork.addResource('en', 'translation', 'greeting.hello', 'Hi')) or a deep addResourceBundle() on the fork also changed the original instance and every other fork. Flat keys were already isolated. Forking a large store takes a bit longer: with 300k keys in nested groups, about 11 ms instead of 3 ms per fork. Clones without forkResourceStore still share the store as before. Thanks @​nk-batman21 (#2456, follow-up to #2270).

v26.5.5

  • fix: with the default skipOnVariables: true, a {{placeholder}} inside a value inserted with an unescaped {{- var}} now stays literal, as it already did for {{var}}. The escape pass ran after the unescaped values were written and scanned them again, so t('{{- a}}', { a: '{{b}}', b: 'c' }) returned 'c' instead of '{{b}}'. With pre-built HTML that carries user text, like t('You may contact {{name}} at {{- emailHTML}}.', { name, emailHTML }), that text could pull another variable of the same t() call into the output. Results with skipOnVariables: false, and values without placeholders, are unchanged. Compatibility note: a {{- var}} value whose placeholders were meant to be filled from the same t() call now keeps them literally; skipOnVariables: false restores the old behavior. Thanks @​nk-batman21 (#2455, reported in #1595).

v26.5.4

  • fix: with the default skipOnVariables: true, a {{placeholder}} inside an interpolated value now stays literal also when the same placeholder appears later in the translation. Each value was written with String.replace, which replaces the first copy of the placeholder text, and that could be the copy inside an earlier value: t('{{name}} has {{count}} items', { name: '{{count}}', count: 5 }) returned '5 has {{count}} items' instead of '{{count}} has 5 items'. The value is now written at the position of the matched placeholder. Results with skipOnVariables: false are unchanged. Thanks @​nk-batman21 (#2454, reported in #1595).
  • fix: with useRawValueToEscape: true, a non-string value in an unescaped {{- var}} placeholder or with escapeValue: false no longer throws val.replace is not a function; it is converted to a string like any other value.

v26.5.3

  • fix(types): with the selector API, a plural key now requires count also when the call passes an explicit ns. t(($) => $.item) already failed without count, but t(($) => $.item, { ns: 'items' }) compiled, although at runtime it looks up item instead of item_one / item_other and returns the key. It now fails the same way, also with ordinal: true, defaultValue, an ns array, a key prefix and i18n.t. Calls with count, context, returnObjects: true and arrays of selectors, as well as return types, are unchanged. Thanks @​nyarthan (#2452).

v26.5.2

  • fix(types): on TypeScript 7, a t() call with a missing, misspelled or wrongly typed option now reports that option again (Property 'album' is missing, Type 'string' is not assignable to type 'number'), as TypeScript 5 and 6 do. TypeScript 7 elaborated the error against the default-value signature instead and ended in '{ count: 3; albm: "Summer"; }' is not assignable to type 'string': on a failed call TypeScript explains the last of the equally matching signatures, and TypeScript 7 sorts the 3-element [key, defaultValue, options?] last. It is now written as two signatures, [key, defaultValue] and [key, defaultValue, options]. This affects the default key checks with i18next {{name}} messages as well as parseInterpolation: 'icu' and 'mf2'. Which calls compile, their return types and the error positions are unchanged on TypeScript 5.9, 6 and 7.

v26.5.1

  • perf(types): type-checking t() calls against a large namespace is no longer quadratic in the number of keys. TypeScript does not cache keyof of an object type, and the types rebuilt the union of all keys of a namespace once per key while building the key union, and again in every t() call to look up the return type. Both now use a cached key union, and a literal key is looked up directly instead of being intersected with every key. With 5,000 keys in one namespace and one call per key, the check time went from 14.8s to 1.1s (TypeScript 6); with 1,000 keys from 0.75s to 0.27s. Keys, return types and errors are unchanged.
  • perf(types): the selector API (enableSelector: true / 'strict') with context is no longer quadratic in the size of an object. To decide which keys a context keeps, the types scanned all keys of the object once for every key, also when TypeScript checks the selector with context widened to string. With 1,000 keys plus one context variant each, a namespace took 18.7s and failed with "Type instantiation is excessively deep and possibly infinite" (TS2589); 2,500 and more ran out of memory. The context variants of an object are now collected once, in one pass over its keys: 1,000 keys check in 0.69s, 5,000 in 3.1s. Long keys (whole sentences with keySeparator: false) work as before. Selected values and errors are unchanged.

v26.5.0

  • feat(types): parseInterpolation: 'icu' and parseInterpolation: 'mf2' type t() options from the message's ICU MessageFormat arguments (i18next-icu) or MessageFormat 2 variables (i18next-mf2), so ICU and MF2 users no longer need parseInterpolation: false and lose argument checking. Missing, misspelled and wrongly typed arguments fail, and so does leaving out the options for a message with arguments (t('greeting')); that error names the missing arguments. Opt-in, default true is unchanged.
    • ICU: {name} takes string | number, {n, number}, plural and selectordinal take number, {d, date} and {t, time} take Date, select takes its case keys or any string (for other), and arguments nested in cases are required too. # and tags are not arguments, apostrophe quoting is read like intl-messageformat does.
    • MF2: {$name} takes string | number, a variable annotated with :number, :integer, :currency, :percent or :unit (inline or through .input / .local) takes number, :datetime, :date and :time take Date, :string takes string, option and markup variables (minimumFractionDigits=$digits, {#link href=$url}) are required too, .local variables are not arguments, and |quoted literals| and \{ escapes are skipped.
    • interpolationFormatTypeMap overrides a type by ICU format or MF2 function name, e.g. date: Date | number or a custom uppercase: string.
    • Applies to t(), getFixedT(), i18n.t, key prefixes, namespaces, the selector API and react-i18next's Trans values. Messages need literal types, as the resources file from i18next-cli's types command has them.
    • Type-check cost with 1,000 messages and one call each: 1.35s instead of 0.86s with false (TypeScript 6), 0.5s instead of 0.26s with TypeScript 7. Messages that no call uses cost nothing.
  • fix(types): with the default (non-strict) key checks, an options object with a missing or misspelled interpolation variable now reports the missing variable (Property 'name' is missing) instead of '{ nmae: string }' is not assignable to type 'string' from the default-value overload.
Changelog

Sourced from i18next's changelog.

26.5.10

  • fix: when none of the detected languages is in supportedLngs, the best match no longer picks a different language whose code only starts with the same letters. The last fuzzy check took any supported code starting with the language part, so with supportedLngs: ['en', 'fil-PH'] a Finnish user (fi-FI) got Filipino instead of the fallback language, and ha (Hausa) picked haw-US (Hawaiian). Other regions of the same language still match as before (de-CH → de-DE, pt-PT → pt-BR, fil → fil-PH). Compatibility note: a two-letter code no longer matches a supported three-letter code that extends it, like ar → arz-EG, sw → swh-KE or no → nob-NO; list the two-letter code in supportedLngs (or map it with fallbackLng) if you relied on that. Thanks @​Pharex38 (#2460).

26.5.9

  • fix: nested lookups no longer resolve to methods inherited from the prototype, like constructor, toString or map. Only the top level was guarded, so {{constructor}} was treated as missing, but {{user.constructor}} rendered the function source (with a class instance, the full source code of the class), and {{user.toString}}, {{items.map}} or a class method like {{user.greet}} did the same. The same lookup is used for translation keys when ignoreJSONStructure is on (the default): a nested key named like an inherited method that is missing in the current language (t('roles.constructor') with roles.constructor only in the fallback language) returned function Object() { [native code] } instead of falling back, and exists('roles.valueOf') returned true. These keys are now missing, so the fallback language, missingInterpolationHandler, saveMissing and the missing key handler apply as for any other missing key. Getters defined on a class ({{user.fullName}} with get fullName()) still work. Nested lookups also no longer walk into the prototype via __proto__, so {{user.__proto__.constructor}} no longer prints the class source either. Thanks @​Pharex38 (#2459).

26.5.8

  • fix: arrays returned with joinArrays now get the same resolved details as strings. The joined value was extended with lastKey in the place of the resolved lookup, so with postProcessPassResolved a post processor got no usedLng, usedNS or exactUsedKey (t('steps', { joinArrays: ' / ' }) reported undefined/undefined:undefined). This affected the subliminal post processor used by the locize InContext editor, which could not map a joined array to its key. The nesting recursion guard did not get the parent key either, so arrays that nest each other (listA: ['a', '$t(listB)'], listB: ['b', '$t(listA)']) threw Maximum call stack size exceeded. They now stop at the guard, as strings do. An i18nFormat plugin with handleAsObject and parse also no longer throws Cannot read properties of undefined (reading 'usedNS') on joined arrays. Thanks @​nk-batman21 (#2458).

26.5.7

  • fix: with the default cacheInBuiltFormats: true, built-in formats now also work when the t() options contain a BigInt or a circular object. The cache key was built with JSON.stringify over all options, including the interpolation values, which throws on those, so every built-in format in that call returned the raw value: t('num', { val: 12345678901234567890n }) with 'Total: {{val, number}}' returned 'Total: 12345678901234567890' instead of 'Total: 12,345,678,901,234,567,890', and passing an object with a back-reference (like an ORM entity) left all numbers, dates and lists of that call unformatted. When the key cannot be built, the value is now formatted without the cache, as with cacheInBuiltFormats: false. This also applies to formatters added with addCached. Other calls still use the cache as before. Thanks @​nk-batman21 (#2457).

26.5.6

  • fix: cloneInstance({ forkResourceStore: true }) now copies the resources at every level. It copied them only down to the namespace objects, so nested keys and arrays stayed shared with the original instance: addResource() with a nested key (fork.addResource('en', 'translation', 'greeting.hello', 'Hi')) or a deep addResourceBundle() on the fork also changed the original instance and every other fork. Flat keys were already isolated. Forking a large store takes a bit longer: with 300k keys in nested groups, about 11 ms instead of 3 ms per fork. Clones without forkResourceStore still share the store as before. Thanks @​nk-batman21 (#2456, follow-up to #2270).

26.5.5

  • fix: with the default skipOnVariables: true, a {{placeholder}} inside a value inserted with an unescaped {{- var}} now stays literal, as it already did for {{var}}. The escape pass ran after the unescaped values were written and scanned them again, so t('{{- a}}', { a: '{{b}}', b: 'c' }) returned 'c' instead of '{{b}}'. With pre-built HTML that carries user text, like t('You may contact {{name}} at {{- emailHTML}}.', { name, emailHTML }), that text could pull another variable of the same t() call into the output. Results with skipOnVariables: false, and values without placeholders, are unchanged. Compatibility note: a {{- var}} value whose placeholders were meant to be filled from the same t() call now keeps them literally; skipOnVariables: false restores the old behavior. Thanks @​nk-batman21 (#2455, reported in #1595).

26.5.4

  • fix: with the default skipOnVariables: true, a {{placeholder}} inside an interpolated value now stays literal also when the same placeholder appears later in the translation. Each value was written with String.replace, which replaces the first copy of the placeholder text, and that could be the copy inside an earlier value: t('{{name}} has {{count}} items', { name: '{{count}}', count: 5 }) returned '5 has {{count}} items' instead of '{{count}} has 5 items'. The value is now written at the position of the matched placeholder. Results with skipOnVariables: false are unchanged. Thanks @​nk-batman21 (#2454, reported in #1595).
  • fix: with useRawValueToEscape: true, a non-string value in an unescaped {{- var}} placeholder or with escapeValue: false no longer throws val.replace is not a function; it is converted to a string like any other value.

26.5.3

  • fix(types): with the selector API, a plural key now requires count also when the call passes an explicit ns. t(($) => $.item) already failed without count, but t(($) => $.item, { ns: 'items' }) compiled, although at runtime it looks up item instead of item_one / item_other and returns the key. It now fails the same way, also with ordinal: true, defaultValue, an ns array, a key prefix and i18n.t. Calls with count, context, returnObjects: true and arrays of selectors, as well as return types, are unchanged. Thanks @​nyarthan (#2452).

26.5.2

  • fix(types): on TypeScript 7, a t() call with a missing, misspelled or wrongly typed option now reports that option again (Property 'album' is missing, Type 'string' is not assignable to type 'number'), as TypeScript 5 and 6 do. TypeScript 7 elaborated the error against the default-value signature instead and ended in '{ count: 3; albm: "Summer"; }' is not assignable to type 'string': on a failed call TypeScript explains the last of the equally matching signatures, and TypeScript 7 sorts the 3-element [key, defaultValue, options?] last. It is now written as two signatures, [key, defaultValue] and [key, defaultValue, options]. This affects the default key checks with i18next {{name}} messages as well as parseInterpolation: 'icu' and 'mf2'. Which calls compile, their return types and the error positions are unchanged on TypeScript 5.9, 6 and 7.

26.5.1

  • perf(types): type-checking t() calls against a large namespace is no longer quadratic in the number of keys. TypeScript does not cache keyof of an object type, and the types rebuilt the union of all keys of a namespace once per key while building the key union, and again in every t() call to look up the return type. Both now use a cached key union, and a literal key is looked up directly instead of being intersected with every key. With 5,000 keys in one namespace and one call per key, the check time went from 14.8s to 1.1s (TypeScript 6); with 1,000 keys from 0.75s to 0.27s. Keys, return types and errors are unchanged.
  • perf(types): the selector API (enableSelector: true / 'strict') with context is no longer quadratic in the size of an object. To decide which keys a context keeps, the types scanned all keys of the object once for every key, also when TypeScript checks the selector with context widened to string. With 1,000 keys plus one context variant each, a namespace took 18.7s and failed with "Type instantiation is excessively deep and possibly infinite" (TS2589); 2,500 and more ran out of memory. The context variants of an object are now collected once, in one pass over its keys: 1,000 keys check in 0.69s, 5,000 in 3.1s. Long keys (whole sentences with keySeparator: false) work as before. Selected values and errors are unchanged.

26.5.0

  • feat(types): parseInterpolation: 'icu' and parseInterpolation: 'mf2' type t() options from the message's ICU MessageFormat arguments (i18next-icu) or MessageFormat 2 variables (i18next-mf2), so ICU and MF2 users no longer need parseInterpolation: false and lose argument checking. Missing, misspelled and wrongly typed arguments fail, and so does leaving out the options for a message with arguments (t('greeting')); that error names the missing arguments. Opt-in, default true is unchanged.
    • ICU: {name} takes string | number, {n, number}, plural and selectordinal take number, {d, date} and {t, time} take Date, select takes its case keys or any string (for other), and arguments nested in cases are required too. # and tags are not arguments, apostrophe quoting is read like intl-messageformat does.
    • MF2: {$name} takes string | number, a variable annotated with :number, :integer, :currency, :percent or :unit (inline or through .input / .local) takes number, :datetime, :date and :time take Date, :string takes string, option and markup variables (minimumFractionDigits=$digits, {#link href=$url}) are required too, .local variables are not arguments, and |quoted literals| and \{ escapes are skipped.
    • interpolationFormatTypeMap overrides a type by ICU format or MF2 function name, e.g. date: Date | number or a custom uppercase: string.
    • Applies to t(), getFixedT(), i18n.t, key prefixes, namespaces, the selector API and react-i18next's Trans values. Messages need literal types, as the resources file from i18next-cli's types command has them.
    • Type-check cost with 1,000 messages and one call each: 1.35s instead of 0.86s with false (TypeScript 6), 0.5s instead of 0.26s with TypeScript 7. Messages that no call uses cost nothing.

... (truncated)

Commits
  • 00b6a3f 26.5.10
  • 9bdd4f6 build
  • fb168f3 changelog for 26.5.10
  • 2584a56 fix: don't match a supported language that only starts with the same letters ...
  • 6c98e55 build
  • 3465ae4 26.5.9
  • 5888c16 changelog for 26.5.9
  • db036c8 fix: don't walk into the prototype via proto in nested lookups
  • 0815882 fix: don't interpolate inherited methods like constructor from nested values ...
  • 45ae264 26.5.8
  • Additional commits viewable in compare view

Updates react-i18next from 17.0.21 to 17.1.8

Changelog

Sourced from react-i18next's changelog.

17.1.8

  • fix(Trans): an interpolation variable named format is no longer dropped. Trans reads format in an interpolation object as the formatter name ({{ value, format }}), so with {{ format }} as the only key nothing was left: <Trans>Export as {{ format }}</Trans> warned TRANS_INVALID_OBJ and used the default string Export as instead of Export as {{format}}. When format is the object's only key it is now treated as the variable. {{ value, format }} works as before. Without an i18nKey, the key derived from the children changes accordingly, from Export as to Export as {{format}}. i18next-cli serializes Trans children with react-i18next, so extracting with this version produces the same key. Thanks @​Pharex38 (#1944).

17.1.7

  • fix(IcuTrans): each HTML entity in a translation is now decoded exactly once. Named, decimal and hexadecimal entities were decoded in three passes, and each pass decoded the output of the previous one, so an escaped numeric entity was decoded twice: "Write &amp;[#169](https://github.com/i18next/react-i18next/issues/169); to get &[#169](https://github.com/i18next/react-i18next/issues/169);" rendered Write © to get © instead of Write &[#169](https://github.com/i18next/react-i18next/issues/169); to get ©, and &amp;[#60](https://github.com/i18next/react-i18next/issues/60); rendered < instead of &[#60](https://github.com/i18next/react-i18next/issues/60);. This also hit interpolated values with escapeValue: true, where a value containing &[#60](https://github.com/i18next/react-i18next/issues/60); is escaped to &amp;[#60](https://github.com/i18next/react-i18next/issues/60);. Escaped named entities like &amp;lt; already stayed &lt;, as browsers and Trans decode them. Unknown named entities and entities above U+10FFFF still stay as written. Thanks @​Pharex38 (#1943).

17.1.6

  • fix(Trans): a count passed in tOptions is now used. Trans spread tOptions and then set its own count prop, so a count only in tOptions was overwritten with undefined: <Trans i18nKey="items" tOptions={{ count: 5 }} /> rendered the key items instead of 5 items, and with children Trans could pick the wrong plural form. Like context, Trans now falls back to tOptions.count, handled the same way as the count prop. A count prop, a count in the children or values.count still take precedence, and tOptions is not modified. Thanks @​nk-batman21 (#1942).

17.1.5

  • fix(Trans): with an array of keys and no children, Trans now falls back to the last key when none of them has a translation, as t() does. It used the array itself as defaultValue, which i18next handles as an object, so <Trans i18nKey={['notifications.crm_item_created', 'crm_item_created']} components={[<strong />]} /> rendered key 'crm_item_created (en)' returned an object instead of string. instead of crm_item_created. An array of selectors falls back to the key of the last selector. The first key that has a translation still wins, and children, defaults and tOptions.defaultValue are used as before. With saveMissing, these calls now report the missing key, like a single i18nKey does. Thanks @​nk-batman21 (#1941).

17.1.4

  • fix(types): without allowObjectInHTMLChildren, the children of HTML elements now use React's own type (DOMAttributes<T>['children']) instead of the ReactI18NextChildren | Iterable<ReactI18NextChildren> union. Both accept the same children, so nothing compiles differently. For default installs the global HTMLAttributes augmentation now repeats whatever @types/react declares, so changes in React's types flow through instead of meeting a copy, and type errors on element children no longer list an extra Iterable<...>. With allowObjectInHTMLChildren: true nothing changes. First step of #1928.

17.1.3

  • fix(IcuTrans): numeric HTML entities above U+FFFF, like emoji, now decode to the right character. "Hello &#x1F44B; <0>friend</0> &[#127881](https://github.com/i18next/react-i18next/issues/127881);" rendered U+F44B and U+F389, private-use glyphs that usually show as a box, instead of 👋 and 🎉: the decoder used String.fromCharCode, which keeps only the low 16 bits of the code point. This shows up with translations that a TMS or CMS exports HTML-encoded. Entities above U+10FFFF, which are no valid code points, now stay as written instead of becoming U+0000. Entities below U+10000, including surrogate pairs written as two entities, decode as before. Thanks @​nk-batman21 (#1940).

17.1.2

  • fix(Trans): when the only child is a string, a tag whose index the children don't have now renders its own text. <Trans i18nKey="welcome">Welcome</Trans> with "Welcome <1>friend</1>" rendered Welcome e, and defaults="Hi <1>there</1>" with the child Hi rendered Hi i. The fallback for a single object of components ({{ 1: <strong /> }}) looked the tag up on the string and rendered one of its characters. It now applies only when that child is an object, so {{ 1: <strong /> }} renders as before, and the tag falls back to its inner text, as it already did with several children or with a number or an element as the only child. This also stops a single-entry array child holding null ({[null]}, e.g. from a .map that returned null) from throwing Cannot read properties of null. Thanks @​Cayan (#1939).

17.1.1

  • fix(Trans): with components as an object with index keys, the component for key 0 is now rendered. components={{ 0: <a href={path} /> }} with "You're eligible. <0>Get started here.</0>" rendered the text without the link, a self-closing <0/> rendered nothing, and in <0>a <1>b</1></0> both elements were lost, while keys 1 and up and the array form worked. The object was passed on as the indexed children, so <0> resolved to the object itself. It is now looked up by key, like a named components map. This also fixes an array components next to react.transDefaultProps.components, which the merge turns into such an object ({ Bold, 0, 1 }) and so lost its first entry, and a self-closing named tag in a mixed object ({ 0: <a />, Bold: <b /> } with <Bold/>), which rendered as the text <Bold />. Arrays, named maps and index objects starting at 1 render as before. Thanks @​nk-batman21 (#1938).

17.1.0

  • feat(types): with i18next's new parseInterpolation: 'icu' (or 'mf2') type option (i18next v26.5.0), the values of IcuTrans and IcuTransWithoutContext are typed from the message of i18nKey, like the options of t(): a misspelled argument, a value of the wrong type or a value meant for another key is a type error. values was Record<string, any> before, and still is with any other parseInterpolation setting. values stays optional, as on Trans. useTranslation's t and Trans values get the checks from i18next's types without changes here.
  • fix(types): IcuTrans and IcuTransWithoutContext now infer the literal i18nKey (const type parameter, as Trans does), so props that depend on the key are checked against that key instead of all keys of the namespace.
Commits

Updates react-router from 8.4.0 to 8.5.0

Details...

Description has been truncated

@dependabot
build(deps): bump the all-dependencies group with 8 updates
66dbeab 
Bumps the all-dependencies group with 8 updates:

| Package | From | To |
| --- | --- | --- |
| [@llamaindex/liteparse](https://github.com/run-llama/liteparse) | `2.15.1` | `2.17.0` |
| [electron-updater](https://github.com/electron-userland/electron-builder/tree/HEAD/packages/electron-updater) | `6.8.9` | `6.8.11` |
| [i18next](https://github.com/i18next/i18next) | `26.4.7` | `26.5.10` |
| [react-i18next](https://github.com/i18next/react-i18next) | `17.0.21` | `17.1.8` |
| [react-router](https://github.com/remix-run/react-router/tree/HEAD/packages/react-router) | `8.4.0` | `8.5.0` |
| [electron](https://github.com/electron/electron) | `44.9.3` | `45.0.0` |
| [electron-builder](https://github.com/electron-userland/electron-builder/tree/HEAD/packages/electron-builder) | `26.17.0` | `26.18.0` |
| [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) | `8.3.4` | `8.3.5` |


Updates `@llamaindex/liteparse` from 2.15.1 to 2.17.0
- [Release notes](https://github.com/run-llama/liteparse/releases)
- [Changelog](https://github.com/run-llama/liteparse/blob/main/CHANGELOG.md)
- [Commits](run-llama/liteparse@node-v2.15.1...node-v2.17.0)

Updates `electron-updater` from 6.8.9 to 6.8.11
- [Release notes](https://github.com/electron-userland/electron-builder/releases)
- [Changelog](https://github.com/electron-userland/electron-builder/blob/electron-updater@6.8.11/packages/electron-updater/CHANGELOG.md)
- [Commits](https://github.com/electron-userland/electron-builder/commits/electron-updater@6.8.11/packages/electron-updater)

Updates `i18next` from 26.4.7 to 26.5.10
- [Release notes](https://github.com/i18next/i18next/releases)
- [Changelog](https://github.com/i18next/i18next/blob/master/CHANGELOG.md)
- [Commits](i18next/i18next@v26.4.7...v26.5.10)

Updates `react-i18next` from 17.0.21 to 17.1.8
- [Changelog](https://github.com/i18next/react-i18next/blob/master/CHANGELOG.md)
- [Commits](i18next/react-i18next@v17.0.21...v17.1.8)

Updates `react-router` from 8.4.0 to 8.5.0
- [Release notes](https://github.com/remix-run/react-router/releases)
- [Changelog](https://github.com/remix-run/react-router/blob/main/packages/react-router/CHANGELOG.md)
- [Commits](https://github.com/remix-run/react-router/commits/react-router@8.5.0/packages/react-router)

Updates `electron` from 44.9.3 to 45.0.0
- [Release notes](https://github.com/electron/electron/releases)
- [Commits](electron/electron@v44.9.3...v45.0.0)

Updates `electron-builder` from 26.17.0 to 26.18.0
- [Release notes](https://github.com/electron-userland/electron-builder/releases)
- [Changelog](https://github.com/electron-userland/electron-builder/blob/electron-builder@26.18.0/packages/electron-builder/CHANGELOG.md)
- [Commits](https://github.com/electron-userland/electron-builder/commits/electron-builder@26.18.0/packages/electron-builder)

Updates `vite` from 8.3.4 to 8.3.5
- [Release notes](https://github.com/vitejs/vite/releases)
- [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md)
- [Commits](https://github.com/vitejs/vite/commits/v8.3.5/packages/vite)

---
updated-dependencies:
- dependency-name: "@llamaindex/liteparse"
  dependency-version: 2.17.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: all-dependencies
- dependency-name: electron-updater
  dependency-version: 6.8.11
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: i18next
  dependency-version: 26.5.10
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: all-dependencies
- dependency-name: react-i18next
  dependency-version: 17.1.8
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: all-dependencies
- dependency-name: react-router
  dependency-version: 8.5.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: all-dependencies
- dependency-name: electron
  dependency-version: 45.0.0
  dependency-type: direct:development
  update-type: version-update:semver-major
  dependency-group: all-dependencies
- dependency-name: electron-builder
  dependency-version: 26.18.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: all-dependencies
- dependency-name: vite
  dependency-version: 8.3.5
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot requested a review from mbianchidev as a code owner October 27, 2026 13:35
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code labels Oct 27, 2026
@mbianchidev
mbianchidev merged commit ef91f2b into main Oct 27, 2026
6 checks passed
@mbianchidev
mbianchidev deleted the dependabot/npm_and_yarn/all-dependencies-44674f26d6 branch October 27, 2026 13:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@mbianchidev mbianchidev Awaiting requested review from mbianchidev mbianchidev is a code owner

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@mbianchidev