Repository navigation
Update dependency i18next to v26.4.4 - #12143
Open
renovate[bot] wants to merge 1 commit into
Open
renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
renovate
Bot
force-pushed
the
renovate/i18next-26.x
branch
2 times, most recently
from
October 12, 2026 11:01
846e9da to
8dc9c26
Compare
renovate
Bot
force-pushed
the
renovate/i18next-26.x
branch
3 times, most recently
from
October 13, 2026 06:27
f5d656d to
e48daac
Compare
renovate
Bot
force-pushed
the
renovate/i18next-26.x
branch
from
October 13, 2026 08:48
e48daac to
677b2df
Compare
Contributor
Code Coverage Report: Only Changed Files listed
Minimum allowed coverage is |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
26.4.2→26.4.4Release Notes
i18next/i18next (i18next)
v26.4.4Compare Source
$t(. Its repeated group had overlapping alternatives ([^()"']+inside(?:...)*?, and inside parentheses[^()]also matched quotes), so a string containing$t(without a closing)made the engine try every way to split the text: about 2x the runtime per extra character, and a ~25 character value hungt()for minutes. With the default config this was reachable through any interpolated value (t('greet', { name: '$t(aaaaaaaaaaaaaaaaaaaaaaaa' })): escaping does not touch$,tor(, and theskipOnVariablescheck runs the regexp on the interpolated result, sonest: falsedid not help either. Every alternative now starts with a different character (plain char,",'or(), so there is only one way to match and the cost is linear. Quoted strings and one level of parentheses in nesting options keep working (#2336). The only difference: a lone"or'inside unquoted parentheses within$t(...)is no longer matched. Affects 25.3.3 to 26.4.3. See advisory GHSA-5jr9-983r-c8x4, CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Thanks to Anisetti Chaitanya Eshwar Prasad for the responsible disclosure.nest()now resolves$t(...)in a single pass and no longer nests text that came out of a resolved value. Every nested lookup reset the shared nesting regexp, so the loop started over from the beginning of the string after each match. That had two effects. First, a$t(...)inside a variable that the nested lookup deliberately kept literal (defaultskipOnVariables: true) was resolved anyway by the outer loop: withouter: 'A $t(inner) B'andinner: 'Hi {{name}}',t('outer', { name: '$t(secret)' })rendered thesecrettranslation. It now staysA Hi $t(secret) B, the same as without the outer nesting; withskipOnVariables: falseit is still resolved. Second, the cost was quadratic when an unclosed$t(preceded many nestings, which matters when an app passes untrusted input as the key itself (t(userInput)): 20,000 nestings took ~1.4 s, now ~25 ms. The resolved value is now sliced into the result instead of going throughString.replace, so$&,$`,$'and$$stay literal as before (26.4.2).v26.4.3Compare Source
ResourceStore.hasLanguageSomeTranslations()no longer enumerates every key of a large bundle on each call. It ranObject.keys()on the whole bundle just to learn whether it had at least one key, andinit()/changeLanguage()reach it three times per instance (once while picking the language, twice viasetResolvedLanguage()). With large flat bundles and one i18next instance per SSR request reusing the same resources, that showed up as measurable CPU work before anyt()call. Bundle objects already found non-empty are now remembered in aWeakSetshared across instances, so later checks are O(1): 2,000 inits with a 6,800-key bundle went from ~750 ms to ~20 ms, the same as a one-key bundle. Only the non-empty result is cached. No API removes single keys from a bundle, so a non-empty bundle stays non-empty, and empty bundles are re-checked every time, so keys added later (backend loads,addResource,addResourceBundle, direct or silent changes) count right away. The only edge case: a bundle emptied by hand withdeleteon every key while it is still in the store keeps counting as having translations; useremoveResourceBundle()for that. Thanks @dmchoi77 for the detailed report (#2449).Configuration
📅 Schedule: (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.
This PR was generated by Mend Renovate. View the repository job log.