replexica 本地化工程之 lingo.dev/_react 演进全解React 工具链的 API 里程碑、缺陷修复与供应链安全实践【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica导读本文以 replexica 仓库中lingo.dev/_reactLingo.dev React Kit的 CHANGELOG 为脉络结合 packages/react 下的真实源码完整梳理这个 React 本地化运行时包从 0.1.0 到 0.7.11 的功能演进LingoProvider/LingoProviderWrapper的字典加载模型、useLingoLocale与setLingoLocale的语言切换 API、LocaleSwitcher组件、Suspense 加载态以及贯穿 0.7.x 的依赖固定与漏洞修复实践。读完本文你将理解该包在客户端渲染、React Router 与 RSC 三类场景下的接入方式掌握其安全升级决策背后的技术考量并能在自己的项目中复刻同样的依赖治理策略。一、包定位一个被编译器接管的 React 本地化运行时在深入变更记录之前先明确这个包在 replexica 生态中的角色。package.json 将其描述为 Lingo.dev React Kit通过四个子路径导出不同的运行时入口lingo.dev/_react根对应 core提供不依赖 React 客户端上下文的底层组件与字典获取逻辑LingoComponent、getDictionary、常量等lingo.dev/_react/client对应 client面向纯客户端渲染应用如 Vite SPA导出LingoProvider、LingoProviderWrapper、loadDictionary、LocaleSwitcher、useLingoLocale/setLingoLocale等lingo.dev/_react/rsc对应 rsc面向 React Server Componentslingo.dev/_react/react-router对应 react-router面向 React Router / Remix 的 loader 场景。一个关键设计是源码中的loadDictionary是占位函数如 loader.ts 直接返回空对象真正可用的实现由 Lingo.dev Compiler 在构建期注入替换。因此本文讨论的组件 API 形态props、hooks、行为都以源码为准而编译器会替换占位实现这一约定是理解整个包使用方式的前提。二、Provider 架构演进从同步字典到 Suspense 异步加载2.1LingoProvider服务端预取数据的客户端上下文provider.tsx 中的LingoProvider是LingoContext的 Provider 封装接收一个已加载完成的字典对象dictionary并通过LingoContext见 context.ts下发到所有后代组件。其核心约束必须放在组件树顶层适合服务端预取数据后交给客户端的应用例如 React Router 的 loader 中调用loadDictionary(request)后通过useLoaderData取出字典再注入未提供字典时直接throw new Error(LingoProvider: dictionary is not provided.)避免静默渲染错误。这是 CHANGELOG 0.2.2 中 show dictionary error 变更PR #868的落地体现字典缺失不再是不可见的状态而是显式抛错便于开发者快速定位。2.2LingoProviderWrapper纯客户端场景的 Suspense 加载边界0.6.0 版本PR #1534为LingoProviderWrapper增加了 Suspense fallback这是纯客户端应用Vite SPA接入本地化的关键能力。看源码 provider.tsx组件通过getLocaleFromCookies()读取当前语言useMemo只计算一次用createDictionaryResource手工实现了一个资源读取器pending / success / error 三态配合Suspense在字典加载期间挂起子树渲染未传fallback时加载期间无任何 UI源码注释明确说明 Suspends rendering while the dictionary loads (no UI by default, opt-in with fallback prop)传了fallback则渲染加载占位内置的LingoProviderFallback组件provider.tsx输出一个带rolestatus、aria-livepolite的无障碍加载提示 Loading translations...兼顾可访问性0.2.1 的 add console log 变更在此处体现为console.log([Lingo.dev] Loading dictionary file for locale ${locale}...)字典加载失败时也会输出Failed to load dictionary日志0.2.2 show dictionary error。典型接入方式对应源码 JSDoc 示例为import { LingoProviderFallback, LingoProviderWrapper, loadDictionary } from lingo.dev/react/client; import { StrictMode } from react; import { createRoot } from react-dom/client; import App from ./App.tsx; createRoot(document.getElementById(root)!).render( StrictMode LingoProviderWrapper loadDictionary{(locale) loadDictionary(locale)} fallback{LingoProviderFallback /} App / /LingoProviderWrapper /StrictMode, );2.3 RSC 与 React Router 的入口差异rsc子路径在 rsc/index.ts 中导出 loader / provider / component / attribute-component / utils面向服务端组件渲染react-router子路径的 loader.ts 提供更聪明的loadDictionary它接受Request | string若传入 Request 对象则解析Cookie头中的lingo-localecookieloadLocaleFromCookies实现于 loader.ts无 Cookie 时回退到getDictionary的默认逻辑。这与 0.4.2 的修复Fix loadLocaleFromCookies to return default locale instead of null when no cookie is found直接对应——该修复确保无 cookie 时不返回null导致字典为空而是落入默认 locale。三、语言切换 API 里程碑0.4.0 与 0.5.03.1LocaleSwitcher与 className 支持0.4.00.4.0commit95c23cc为语言切换组件增加了className支持。源码 locale-switcher.tsx 显示LocaleSwitcher是一个无样式的select下拉框props 仅两个locales: string[]应同时包含源语言与目标语言与className?: string挂载后从lingo-localecookie 读取当前语言若 cookie 值不在locales列表中则回退到locales[0]切换时调用setLocaleInCookies写入 cookie 并执行window.location.reload()整页刷新——源码注释明确说明这是有意为之语言变更影响整个应用状态需要全量重渲染在 cookie 尚未读取完成时返回null0.2.3 的 client-side loading state 相关演进避免闪烁错误选项。3.2useLingoLocale/setLingoLocale0.5.00.5.0PR #1134引入的这对 API 是程序化语言切换的入口实现于 locale.tsuseLingoLocale()hook首次渲染返回nulluseEffect中从 cookie 读取并setState返回当前 locale 字符串或nullsetLingoLocale(locale)写入lingo-localecookie 后调用window.location.reload()同样触发整页刷新。两者都依赖 cookie 作为单一事实来源getLocaleFromCookies/setLocaleInCookies位于 client/utils.ts运行时依赖js-cookie见 package.json dependencies。这解释了 CHANGELOG 0.7.7 为何对js-cookie的版本选择如此谨慎详见下文第五节。四、渲染层细节LingoComponent、LingoHtmlComponent 与模板替换修复4.1 客户端组件如何取字典component.tsx 中的LingoComponent通过useLingo()从 context 取出字典再转发给 core 层的LingoCoreComponent$dictionary、$fileKey、$entryKey等 props 由编译器注入。LingoHtmlComponent则将当前 locale 写入html lang属性与data-lingodotdev-compiler自定义属性服务于 HTML 级别的语言标注与调试。4.2 0.2.2 的模板替换 shift() 缺陷修复0.2.2 中一个值得单独说明的 patchPR #867 修复了 template substitution destructive shift() bug——当不同语言的翻译含有不同数量的元素如内嵌 JSX 节点时旧的模板替换逻辑通过shift()破坏性地消费元素数组导致渲染错乱。修复后元素替换不再依赖数组的可变顺序消费从而保证翻译的元素数量与源语言不一致时仍能正确渲染。这是本地化工程中典型的健壮性边界问题机器翻译或人工翻译都可能改变内联元素的数量与顺序运行时必须容忍这种不一致。五、供应链安全与依赖治理0.7.x 的核心主题从 0.7.4 到 0.7.11这个包的变更几乎全部围绕安全公告修复与依赖治理其决策链条是本文最具复用价值的部分。5.1 依赖固定版本0.7.0 的防供应链攻击策略0.7.0PR #1634将包内所有依赖从^/~范围改为精确版本锁定理由明确防止供应链攻击所有依赖变更都需要显式审查。观察当前 package.jsonreact: 19.2.3、next: 16.2.11、js-cookie: 3.0.8、lodash: 4.18.1、typescript: 5.9.3等均为精确版本——这是读者可以直接照搬的工程实践对运行时依赖使用 lockfile 精确版本配合 Dependabot 等工具的 PR 审查流程。5.2 依赖覆盖overrides与发布清单治理0.7.80.7.8PR #2125描述了两层修复策略仓库层pnpm audit在根pnpmoverrides中对 axios、vite、ws、form-data、fast-xml-parser、shell-quote、lodash、serialize-javascript、minimatch、picomatch、tmp 等传递依赖固定到已修复版本将pnpm audit从 121 high 5 critical 降至 0发布包层消费者侧将随包发布的运行时依赖lodash4.17.23 → 4.18.1、modelcontextprotocol/sdk1.22.0 → 1.26.0、ws8.18.3 → 8.21.0升级到已修复版本避免消费者安装后仍携带漏洞版本。所有升级均为同大版本内的 patch/minor无 API 变更。5.3 升级决策中的版本挑选智慧0.7.7 与 0.7.90.7.7PR #2108展示了两个教科书级的版本选择案例js-cookie 3.0.7 vs 3.0.8两个版本都修复 CVE-2026-46625但 3.0.7 意外将 Node 引擎要求提升到20破坏 ES5 兼容性3.0.8 保留安全修复的同时移除了引擎约束从而维持包的 Node18支持——在安全修复与运行时兼容性之间选择后者是发布型库作者需要反复权衡的点lodash 4.17.23 vs 4.18.04.18.x 被 npm 标记为 bad release 且被维护者否认因此选择 4.17.23修复原型污染公告 GHSA-xxjr-mmjv-4gpg其余两个公告因该包未使用_.template、_.omit/_.unset仅以受控字面量键调用而给出理由后驳回——安全修复不必无脑升到最高版本而是基于实际代码面code surface做风险评估。0.7.9PR #2140继续这一思路将lingo.dev/_react的nextpeerDependency 从精确易受攻击的15.3.8放宽为15.5.19 16同时通过移除lingo.dev中未使用的ink系列依赖顺带规避 ink v7 的 Node 22 要求将消费者npm audit从 13 降为 8critical 1 → 0high 4 → 1。5.4 构建期安全0.7.10 与 0.7.110.7.10PR #2164在仓库层面新增 dependency overrides覆盖 picomatch、qs、postcss、ajv、launch-editor、js-yaml两条、joi 等0.7.11PR #2180将nextdevDependency 升至 16.2.11关闭 middleware/proxy bypass、Server Actions 与 rewrites 中的 SSRF、Server Action DoS、Image Optimization SVG DoS 等四项 high 与五项 medium 公告且明确仅构建期影响不改变运行时依赖与公开 API。这两条共同传达的原则是构建链依赖devDependencies同样需要安全治理且其升级不影响已发布包的运行时行为可以放心合入。六、其他值得关注的变更编译期行为与工程化0.4.3PR #1119编译器支持回退到源语言——当目标语言缺失某条翻译时回退到源语言条目避免出现空白 UI0.3.0PR #897编译器支持更多翻译提供商并实现 Google AI属于编译链路的能力扩展非 React 运行时 API 变化0.2.4PR #887处理 lingo 目录被删除的场景提升构建期的容错性0.2.0PR #838从 tsup 切换为 unbuild 作为打包器build: pnpm typecheck unbuild见 package.json并配套vitest测试与testing-library/react组件测试test: vitest --run0.6.0PR #1534LingoProviderWrapper的 Suspense fallback已在第二节详述0.7.4 / 0.7.5 / 0.7.1分别将 React 升级到 19.2.3修复 CVE-2025-55184 DoS 与 CVE-2025-55183 源码泄露、Next.js 升级以修复安全漏洞。可见 React 19 与 Next.js 15/16 是该包当前验证的运行环境package.json 的 devDependencies 中react: 19.2.3、next: 16.2.11peerDependencies 为next: 15.5.19 16。七、给读者的实践清单如何把这份演进史变成自己的工程能力接入时按场景选入口纯客户端 SPA 用lingo.dev/_react/clientLingoProviderWrapperfallbackReact Router / Remix 用lingo.dev/_react/react-router的loadDictionary(request)LingoProviderRSC 应用走lingo.dev/_react/rsc。具体示例可分别查看 provider.tsx 与 react-router/loader.ts 的 JSDoc。语言状态以 cookie 为锚useLingoLocale/setLingoLocale/LocaleSwitcher全部读写lingo-localecookie切换语言会整页刷新——这是设计使然不是缺陷。依赖治理三层法根仓库overrides压制传递依赖漏洞见 0.7.8发布包升级随包依赖至修复版本见 0.7.8对修复版本自身引入新问题的依赖js-cookie 3.0.7、lodash 4.18.0手工挑选替代版本见 0.7.7。安全修复不等于盲目升级基于实际代码面是否使用_.template、调用参数是否可控判断公告是否适用并记录驳回理由——这正是 0.7.7 的做法。升级前核对兼容性观察 CHANGELOG 中仅构建期无运行时 API 变化保持 Node 18等措辞判断某个安全升级是否会波及消费者运行环境。结语lingo.dev/_react的 CHANGELOG 虽短却浓缩了一个开源本地化运行时的完整生命周期从 0.2.x 的渲染健壮性修复模板替换 shift() bug、字典错误可见化到 0.4.x–0.6.x 的 API 完善LocaleSwitcherclassName、useLingoLocale/setLingoLocale、Suspense fallback再到 0.7.x 的供应链安全深耕精确版本、overrides、peerDependency 策略与版本挑选决策。结合 packages/react/src 源码阅读这份变更记录读者不仅能掌握在 React / React Router / RSC 三种架构下接入本地化的完整姿势更能带走一套可直接复用的依赖安全治理方法论。【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 replexica 本地化工程之 @lingo.dev/_react 演进全解：React 工具链的 API 里程碑、缺陷修复与供应链安全实践
replexica 本地化工程之 lingo.dev/_react 演进全解React 工具链的 API 里程碑、缺陷修复与供应链安全实践【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica导读本文以 replexica 仓库中lingo.dev/_reactLingo.dev React Kit的 CHANGELOG 为脉络结合 packages/react 下的真实源码完整梳理这个 React 本地化运行时包从 0.1.0 到 0.7.11 的功能演进LingoProvider/LingoProviderWrapper的字典加载模型、useLingoLocale与setLingoLocale的语言切换 API、LocaleSwitcher组件、Suspense 加载态以及贯穿 0.7.x 的依赖固定与漏洞修复实践。读完本文你将理解该包在客户端渲染、React Router 与 RSC 三类场景下的接入方式掌握其安全升级决策背后的技术考量并能在自己的项目中复刻同样的依赖治理策略。一、包定位一个被编译器接管的 React 本地化运行时在深入变更记录之前先明确这个包在 replexica 生态中的角色。package.json 将其描述为 Lingo.dev React Kit通过四个子路径导出不同的运行时入口lingo.dev/_react根对应 core提供不依赖 React 客户端上下文的底层组件与字典获取逻辑LingoComponent、getDictionary、常量等lingo.dev/_react/client对应 client面向纯客户端渲染应用如 Vite SPA导出LingoProvider、LingoProviderWrapper、loadDictionary、LocaleSwitcher、useLingoLocale/setLingoLocale等lingo.dev/_react/rsc对应 rsc面向 React Server Componentslingo.dev/_react/react-router对应 react-router面向 React Router / Remix 的 loader 场景。一个关键设计是源码中的loadDictionary是占位函数如 loader.ts 直接返回空对象真正可用的实现由 Lingo.dev Compiler 在构建期注入替换。因此本文讨论的组件 API 形态props、hooks、行为都以源码为准而编译器会替换占位实现这一约定是理解整个包使用方式的前提。二、Provider 架构演进从同步字典到 Suspense 异步加载2.1LingoProvider服务端预取数据的客户端上下文provider.tsx 中的LingoProvider是LingoContext的 Provider 封装接收一个已加载完成的字典对象dictionary并通过LingoContext见 context.ts下发到所有后代组件。其核心约束必须放在组件树顶层适合服务端预取数据后交给客户端的应用例如 React Router 的 loader 中调用loadDictionary(request)后通过useLoaderData取出字典再注入未提供字典时直接throw new Error(LingoProvider: dictionary is not provided.)避免静默渲染错误。这是 CHANGELOG 0.2.2 中 show dictionary error 变更PR #868的落地体现字典缺失不再是不可见的状态而是显式抛错便于开发者快速定位。2.2LingoProviderWrapper纯客户端场景的 Suspense 加载边界0.6.0 版本PR #1534为LingoProviderWrapper增加了 Suspense fallback这是纯客户端应用Vite SPA接入本地化的关键能力。看源码 provider.tsx组件通过getLocaleFromCookies()读取当前语言useMemo只计算一次用createDictionaryResource手工实现了一个资源读取器pending / success / error 三态配合Suspense在字典加载期间挂起子树渲染未传fallback时加载期间无任何 UI源码注释明确说明 Suspends rendering while the dictionary loads (no UI by default, opt-in with fallback prop)传了fallback则渲染加载占位内置的LingoProviderFallback组件provider.tsx输出一个带rolestatus、aria-livepolite的无障碍加载提示 Loading translations...兼顾可访问性0.2.1 的 add console log 变更在此处体现为console.log([Lingo.dev] Loading dictionary file for locale ${locale}...)字典加载失败时也会输出Failed to load dictionary日志0.2.2 show dictionary error。典型接入方式对应源码 JSDoc 示例为import { LingoProviderFallback, LingoProviderWrapper, loadDictionary } from lingo.dev/react/client; import { StrictMode } from react; import { createRoot } from react-dom/client; import App from ./App.tsx; createRoot(document.getElementById(root)!).render( StrictMode LingoProviderWrapper loadDictionary{(locale) loadDictionary(locale)} fallback{LingoProviderFallback /} App / /LingoProviderWrapper /StrictMode, );2.3 RSC 与 React Router 的入口差异rsc子路径在 rsc/index.ts 中导出 loader / provider / component / attribute-component / utils面向服务端组件渲染react-router子路径的 loader.ts 提供更聪明的loadDictionary它接受Request | string若传入 Request 对象则解析Cookie头中的lingo-localecookieloadLocaleFromCookies实现于 loader.ts无 Cookie 时回退到getDictionary的默认逻辑。这与 0.4.2 的修复Fix loadLocaleFromCookies to return default locale instead of null when no cookie is found直接对应——该修复确保无 cookie 时不返回null导致字典为空而是落入默认 locale。三、语言切换 API 里程碑0.4.0 与 0.5.03.1LocaleSwitcher与 className 支持0.4.00.4.0commit95c23cc为语言切换组件增加了className支持。源码 locale-switcher.tsx 显示LocaleSwitcher是一个无样式的select下拉框props 仅两个locales: string[]应同时包含源语言与目标语言与className?: string挂载后从lingo-localecookie 读取当前语言若 cookie 值不在locales列表中则回退到locales[0]切换时调用setLocaleInCookies写入 cookie 并执行window.location.reload()整页刷新——源码注释明确说明这是有意为之语言变更影响整个应用状态需要全量重渲染在 cookie 尚未读取完成时返回null0.2.3 的 client-side loading state 相关演进避免闪烁错误选项。3.2useLingoLocale/setLingoLocale0.5.00.5.0PR #1134引入的这对 API 是程序化语言切换的入口实现于 locale.tsuseLingoLocale()hook首次渲染返回nulluseEffect中从 cookie 读取并setState返回当前 locale 字符串或nullsetLingoLocale(locale)写入lingo-localecookie 后调用window.location.reload()同样触发整页刷新。两者都依赖 cookie 作为单一事实来源getLocaleFromCookies/setLocaleInCookies位于 client/utils.ts运行时依赖js-cookie见 package.json dependencies。这解释了 CHANGELOG 0.7.7 为何对js-cookie的版本选择如此谨慎详见下文第五节。四、渲染层细节LingoComponent、LingoHtmlComponent 与模板替换修复4.1 客户端组件如何取字典component.tsx 中的LingoComponent通过useLingo()从 context 取出字典再转发给 core 层的LingoCoreComponent$dictionary、$fileKey、$entryKey等 props 由编译器注入。LingoHtmlComponent则将当前 locale 写入html lang属性与data-lingodotdev-compiler自定义属性服务于 HTML 级别的语言标注与调试。4.2 0.2.2 的模板替换 shift() 缺陷修复0.2.2 中一个值得单独说明的 patchPR #867 修复了 template substitution destructive shift() bug——当不同语言的翻译含有不同数量的元素如内嵌 JSX 节点时旧的模板替换逻辑通过shift()破坏性地消费元素数组导致渲染错乱。修复后元素替换不再依赖数组的可变顺序消费从而保证翻译的元素数量与源语言不一致时仍能正确渲染。这是本地化工程中典型的健壮性边界问题机器翻译或人工翻译都可能改变内联元素的数量与顺序运行时必须容忍这种不一致。五、供应链安全与依赖治理0.7.x 的核心主题从 0.7.4 到 0.7.11这个包的变更几乎全部围绕安全公告修复与依赖治理其决策链条是本文最具复用价值的部分。5.1 依赖固定版本0.7.0 的防供应链攻击策略0.7.0PR #1634将包内所有依赖从^/~范围改为精确版本锁定理由明确防止供应链攻击所有依赖变更都需要显式审查。观察当前 package.jsonreact: 19.2.3、next: 16.2.11、js-cookie: 3.0.8、lodash: 4.18.1、typescript: 5.9.3等均为精确版本——这是读者可以直接照搬的工程实践对运行时依赖使用 lockfile 精确版本配合 Dependabot 等工具的 PR 审查流程。5.2 依赖覆盖overrides与发布清单治理0.7.80.7.8PR #2125描述了两层修复策略仓库层pnpm audit在根pnpmoverrides中对 axios、vite、ws、form-data、fast-xml-parser、shell-quote、lodash、serialize-javascript、minimatch、picomatch、tmp 等传递依赖固定到已修复版本将pnpm audit从 121 high 5 critical 降至 0发布包层消费者侧将随包发布的运行时依赖lodash4.17.23 → 4.18.1、modelcontextprotocol/sdk1.22.0 → 1.26.0、ws8.18.3 → 8.21.0升级到已修复版本避免消费者安装后仍携带漏洞版本。所有升级均为同大版本内的 patch/minor无 API 变更。5.3 升级决策中的版本挑选智慧0.7.7 与 0.7.90.7.7PR #2108展示了两个教科书级的版本选择案例js-cookie 3.0.7 vs 3.0.8两个版本都修复 CVE-2026-46625但 3.0.7 意外将 Node 引擎要求提升到20破坏 ES5 兼容性3.0.8 保留安全修复的同时移除了引擎约束从而维持包的 Node18支持——在安全修复与运行时兼容性之间选择后者是发布型库作者需要反复权衡的点lodash 4.17.23 vs 4.18.04.18.x 被 npm 标记为 bad release 且被维护者否认因此选择 4.17.23修复原型污染公告 GHSA-xxjr-mmjv-4gpg其余两个公告因该包未使用_.template、_.omit/_.unset仅以受控字面量键调用而给出理由后驳回——安全修复不必无脑升到最高版本而是基于实际代码面code surface做风险评估。0.7.9PR #2140继续这一思路将lingo.dev/_react的nextpeerDependency 从精确易受攻击的15.3.8放宽为15.5.19 16同时通过移除lingo.dev中未使用的ink系列依赖顺带规避 ink v7 的 Node 22 要求将消费者npm audit从 13 降为 8critical 1 → 0high 4 → 1。5.4 构建期安全0.7.10 与 0.7.110.7.10PR #2164在仓库层面新增 dependency overrides覆盖 picomatch、qs、postcss、ajv、launch-editor、js-yaml两条、joi 等0.7.11PR #2180将nextdevDependency 升至 16.2.11关闭 middleware/proxy bypass、Server Actions 与 rewrites 中的 SSRF、Server Action DoS、Image Optimization SVG DoS 等四项 high 与五项 medium 公告且明确仅构建期影响不改变运行时依赖与公开 API。这两条共同传达的原则是构建链依赖devDependencies同样需要安全治理且其升级不影响已发布包的运行时行为可以放心合入。六、其他值得关注的变更编译期行为与工程化0.4.3PR #1119编译器支持回退到源语言——当目标语言缺失某条翻译时回退到源语言条目避免出现空白 UI0.3.0PR #897编译器支持更多翻译提供商并实现 Google AI属于编译链路的能力扩展非 React 运行时 API 变化0.2.4PR #887处理 lingo 目录被删除的场景提升构建期的容错性0.2.0PR #838从 tsup 切换为 unbuild 作为打包器build: pnpm typecheck unbuild见 package.json并配套vitest测试与testing-library/react组件测试test: vitest --run0.6.0PR #1534LingoProviderWrapper的 Suspense fallback已在第二节详述0.7.4 / 0.7.5 / 0.7.1分别将 React 升级到 19.2.3修复 CVE-2025-55184 DoS 与 CVE-2025-55183 源码泄露、Next.js 升级以修复安全漏洞。可见 React 19 与 Next.js 15/16 是该包当前验证的运行环境package.json 的 devDependencies 中react: 19.2.3、next: 16.2.11peerDependencies 为next: 15.5.19 16。七、给读者的实践清单如何把这份演进史变成自己的工程能力接入时按场景选入口纯客户端 SPA 用lingo.dev/_react/clientLingoProviderWrapperfallbackReact Router / Remix 用lingo.dev/_react/react-router的loadDictionary(request)LingoProviderRSC 应用走lingo.dev/_react/rsc。具体示例可分别查看 provider.tsx 与 react-router/loader.ts 的 JSDoc。语言状态以 cookie 为锚useLingoLocale/setLingoLocale/LocaleSwitcher全部读写lingo-localecookie切换语言会整页刷新——这是设计使然不是缺陷。依赖治理三层法根仓库overrides压制传递依赖漏洞见 0.7.8发布包升级随包依赖至修复版本见 0.7.8对修复版本自身引入新问题的依赖js-cookie 3.0.7、lodash 4.18.0手工挑选替代版本见 0.7.7。安全修复不等于盲目升级基于实际代码面是否使用_.template、调用参数是否可控判断公告是否适用并记录驳回理由——这正是 0.7.7 的做法。升级前核对兼容性观察 CHANGELOG 中仅构建期无运行时 API 变化保持 Node 18等措辞判断某个安全升级是否会波及消费者运行环境。结语lingo.dev/_react的 CHANGELOG 虽短却浓缩了一个开源本地化运行时的完整生命周期从 0.2.x 的渲染健壮性修复模板替换 shift() bug、字典错误可见化到 0.4.x–0.6.x 的 API 完善LocaleSwitcherclassName、useLingoLocale/setLingoLocale、Suspense fallback再到 0.7.x 的供应链安全深耕精确版本、overrides、peerDependency 策略与版本挑选决策。结合 packages/react/src 源码阅读这份变更记录读者不仅能掌握在 React / React Router / RSC 三种架构下接入本地化的完整姿势更能带走一套可直接复用的依赖安全治理方法论。【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考